[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMkWEXOywaUUy3=G+26G1uYOPw-pq-Wq68xSPmShuAMCGwfcbQ@mail.gmail.com>
Date: Wed, 17 Oct 2018 18:15:47 +0000
From: Michael Tirado <mtirado418@...il.com>
To: Tycho Andersen <tycho@...ho.ws>
Cc: LKML <linux-kernel@...r.kernel.org>,
Kees Cook <keescook@...omium.org>,
Andy Lutomirski <luto@...capital.net>
Subject: Re: [PATCH v6 3/5] seccomp: add a way to get a listener fd from ptrace
Tycho, Sorry for the duplicate, I forgot to CC the list :(
On Wed, Oct 17, 2018 at 3:00 PM Tycho Andersen <tycho@...ho.ws> wrote:
>
>
> That's one of the use cases, but there are a large number of others. I
> discuss a few in patch 1:
> https://www.spinics.net/lists/linux-containers/msg33956.html
>
Thanks this is making more sense to me now.
I haven't been keeping up with the list and just did a bunch
of reading. It seems that stackable LSM's are making some real
progress now, and I wonder if those patches are merged would
using a stacked security module approach be worth exploring if
it provides the same or greater flexibility, and assuming all
syscalls of interest can be hooked somehow?
>FWIW, I'm dropping the ptrace bits (and the fd passing bits)
>from the next version, because they seem fairly controversial.
Yeah ptrace can be difficult to work with, no doubt it is
controversial; <3 Yama. I've used the ptrace method for counting
syscall failures, and ignoring the non-trivial amount of time it
took me to learn the API then write working code, the performance
loss (in a syscall heavyweight program like web browser) is a
noticeable problem, outside of a debugging or analysis context.
Powered by blists - more mailing lists