[trying to get back to this thread -- I've been distracted]
On Tue, May 19, 2020 at 12:39:39AM +0200, Jann Horn wrote:
> On Mon, May 18, 2020 at 11:05 PM Kees Cook wrote:
> > ## deep argument inspection
> >
> > Background: seccomp users would like to write filters that traverse
> > the user point
On Mon, May 18, 2020 at 02:04:57PM -0700, Kees Cook wrote:
> Hi!
>
> This is my attempt at a brain-dump on my plans for nearish-term seccomp
> features. Welcome to my TED talk... ;)
>
> These are the things I've been thinking about:
>
> - fd passing
> - deep argument inspection
> - changing stru
On Mon, May 18, 2020 at 02:04:57PM -0700, Kees Cook wrote:
> Hi!
>
> This is my attempt at a brain-dump on my plans for nearish-term seccomp
> features. Welcome to my TED talk... ;)
>
> These are the things I've been thinking about:
>
> - fd passing
> - deep argument inspection
> - changing stru
On Tue, May 19, 2020 at 3:26 AM Christian Brauner
wrote:
>
> On Mon, May 18, 2020 at 02:04:57PM -0700, Kees Cook wrote:
> > Hi!
> >
> > This is my attempt at a brain-dump on my plans for nearish-term seccomp
> > features. Welcome to my TED talk... ;)
> >
> > These are the things I've been thin
On 2020-05-19, Alexei Starovoitov wrote:
> On Wed, May 20, 2020 at 11:20:45AM +1000, Aleksa Sarai wrote:
> > No it won't become copy_from_user(), nor will there be a TOCTOU race.
> >
> > The idea is that seccomp will proactively copy the struct (and
> > recursively any of the struct pointers insi
On Wed, May 20, 2020 at 11:20:45AM +1000, Aleksa Sarai wrote:
>
> No it won't become copy_from_user(), nor will there be a TOCTOU race.
>
> The idea is that seccomp will proactively copy the struct (and
> recursively any of the struct pointers inside) before the syscall runs
> -- as this is done
On 2020-05-19, Alexei Starovoitov wrote:
> On Mon, May 18, 2020 at 7:53 PM Aleksa Sarai wrote:
> >
> > On 2020-05-19, Jann Horn wrote:
> > > On Mon, May 18, 2020 at 11:05 PM Kees Cook wrote:
> > > > ## deep argument inspection
> > > >
> > > > Background: seccomp users would like to write filter
On Tue, May 19, 2020 at 09:18:47AM -0700, Alexei Starovoitov wrote:
> On Mon, May 18, 2020 at 7:53 PM Aleksa Sarai wrote:
> >
> > On 2020-05-19, Jann Horn wrote:
> > > On Mon, May 18, 2020 at 11:05 PM Kees Cook wrote:
> > > > ## deep argument inspection
> > > >
> > > > The argument caching bit i
On Mon, May 18, 2020 at 7:53 PM Aleksa Sarai wrote:
>
> On 2020-05-19, Jann Horn wrote:
> > On Mon, May 18, 2020 at 11:05 PM Kees Cook wrote:
> > > ## deep argument inspection
> > >
> > > Background: seccomp users would like to write filters that traverse
> > > the user pointers passed into many
On Mon, May 18, 2020 at 02:04:57PM -0700, Kees Cook wrote:
> Hi!
>
> This is my attempt at a brain-dump on my plans for nearish-term seccomp
> features. Welcome to my TED talk... ;)
>
> These are the things I've been thinking about:
>
> - fd passing
> - deep argument inspection
> - changing stru
On 2020-05-19, Aleksa Sarai wrote:
> On 2020-05-19, Christian Brauner wrote:
> > On Tue, May 19, 2020 at 05:09:29PM +1000, Aleksa Sarai wrote:
> > > On 2020-05-18, Kees Cook wrote:
> > > > - the sizes of these EA structs are, by design, growable over time.
> > > > seccomp and its users need to
On 2020-05-19, Christian Brauner wrote:
> On Tue, May 19, 2020 at 05:09:29PM +1000, Aleksa Sarai wrote:
> > On 2020-05-18, Kees Cook wrote:
> > > - the sizes of these EA structs are, by design, growable over time.
> > > seccomp and its users need to be handle this in a forward and backward
> >
On Tue, May 19, 2020 at 05:09:29PM +1000, Aleksa Sarai wrote:
> On 2020-05-18, Kees Cook wrote:
> > ## fd passing
> >
> > Background: seccomp users want to be able to install an fd in a
> > monitored process during a user_notif to emulate "open" calls (or
> > similar), possibly across security bo
On Tue, May 19, 2020 at 12:48:46PM +1000, Aleksa Sarai wrote:
> On 2020-05-19, Jann Horn wrote:
> > On Mon, May 18, 2020 at 11:05 PM Kees Cook wrote:
> > > ## deep argument inspection
> > >
> > > Background: seccomp users would like to write filters that traverse
> > > the user pointers passed in
On Mon, May 18, 2020 at 02:04:57PM -0700, Kees Cook wrote:
> Hi!
>
> This is my attempt at a brain-dump on my plans for nearish-term seccomp
> features. Welcome to my TED talk... ;)
>
> These are the things I've been thinking about:
>
> - fd passing
> - deep argument inspection
> - changing stru
On Tue, May 19, 2020 at 07:24:52AM +, Sargun Dhillon wrote:
> On Tue, May 19, 2020 at 12:39:39AM +0200, Jann Horn wrote:
> > > For user_notif, I think we need something in and around these options:
> > >
> > > - make a new API that explicitly follows EA struct design
> > > (and while read()/w
On Tue, May 19, 2020 at 12:39:39AM +0200, Jann Horn wrote:
> > For user_notif, I think we need something in and around these options:
> >
> > - make a new API that explicitly follows EA struct design
> > (and while read()/write() might be easier[4], I tend to agree with
> > Jann and we need to
On 2020-05-18, Kees Cook wrote:
> ## fd passing
>
> Background: seccomp users want to be able to install an fd in a
> monitored process during a user_notif to emulate "open" calls (or
> similar), possibly across security boundaries, etc.
>
> On the fd passing front, it seems that gaining pidfd_a
On 2020-05-19, Jann Horn wrote:
> On Mon, May 18, 2020 at 11:05 PM Kees Cook wrote:
> > ## deep argument inspection
> >
> > Background: seccomp users would like to write filters that traverse
> > the user pointers passed into many syscalls, but seccomp can't do this
> > dereference for a variety
On Mon, May 18, 2020 at 2:05 PM Kees Cook wrote:
>
> Hi!
>
This is minor, but, if we grow seccomp_data, I would like to add the
other 32 bits of the syscall nr to it. Syscall numbers are unsigned
long, but they get munged into u32 for seccomp_data.
Sure, no one uses those high bits yet, but if
On Mon, May 18, 2020 at 11:05 PM Kees Cook wrote:
> ## deep argument inspection
>
> Background: seccomp users would like to write filters that traverse
> the user pointers passed into many syscalls, but seccomp can't do this
> dereference for a variety of reasons (mostly involving race conditions
Hi!
This is my attempt at a brain-dump on my plans for nearish-term seccomp
features. Welcome to my TED talk... ;)
These are the things I've been thinking about:
- fd passing
- deep argument inspection
- changing structure sizes
- syscall bitmasks
So, diving right in:
## fd passing
Backgroun
22 matches
Mail list logo
