Re: [PATCH 5/7] seccomp_filter: Document what seccomp_filter is and how it works.

[Frederic Weisbecker <fweisbec@gmail.com>]

On Thu, Apr 28, 2011 at 01:37:33PM -0500, Will Drewry wrote:
> On Thu, Apr 28, 2011 at 9:56 AM, Eric Paris <eparis@redhat.com> wrote:
> > On Thu, 2011-04-28 at 09:06 +0200, Ingo Molnar wrote:
> >> * Will Drewry <wad@chromium.org> wrote:
> >>
> >> > +A collection of filters may be supplied via prctl, and the current set of
> >> > +filters is exposed in /proc/<pid>/seccomp_filter.
> >> > +
> >> > +For instance,
> >> > +  const char filters[] =
> >> > +    "sys_read: (fd == 1) || (fd == 2)\n"
> >> > +    "sys_write: (fd == 0)\n"
> >> > +    "sys_exit: 1\n"
> >> > +    "sys_exit_group: 1\n"
> >> > +    "on_next_syscall: 1";
> >> > +  prctl(PR_SET_SECCOMP, 2, filters);
> >> > +
> >> > +This will setup system call filters for read, write, and exit where reading can
> >> > +be done only from fds 1 and 2 and writing to fd 0.  The "on_next_syscall" directive tells
> >> > +seccomp to not enforce the ruleset until after the next system call is run.  This allows
> >> > +for launchers to apply system call filters to a binary before executing it.
> >> > +
> >> > +Once enabled, the access may only be reduced.  For example, a set of filters may be:
> >> > +
> >> > +  sys_read: 1
> >> > +  sys_write: 1
> >> > +  sys_mmap: 1
> >> > +  sys_prctl: 1
> >> > +
> >> > +Then it may call the following to drop mmap access:
> >> > +  prctl(PR_SET_SECCOMP, 2, "sys_mmap: 0");
> >>
> >> Ok, color me thoroughly impressed
> >
> > Me too!
> >
> >> I've Cc:-ed Linus and Andrew: are you guys opposed to such flexible, dynamic
> >> filters conceptually? I think we should really think hard about the actual ABI
> >> as this could easily spread to more applications than Chrome/Chromium.
> 
> Would it make sense to start, as Frederic has pointed out, by using
> the existing ABI - system call numbers - and not system call names?
> We could leave name resolution to userspace as it is for all other
> system call consumers now.  It might leave the interface for this
> support looking more like:
>   prctl(PR_SET_SECCOMP, 2, _NR_mmap, "fd == 1");
>   prctl(PR_SET_SECCOMP_FILTER_APPLY, now|on_exec);

PR_SET_SECCOMP_FILTER_APPLY seems only useful if you think there
are other cases than enable_on_exec that would be useful for these
filters.

We can think about a default enable on exec behaviour as Steve pointed
out.

But I have no idea if other cases may be desirable to apply these
filters.