[Oneiric][pull request] SECCOMP syscall filtering

[Leann Ogasawara]

On Fri, 2011-08-12 at 16:09 -0500, Will Drewry wrote:
> On Thu, Aug 11, 2011 at 2:08 PM, Kees Cook <kees.cook at canonical.com> wrote:
> > Hi Leann,
> >
> > On Thu, Aug 11, 2011 at 11:04:02AM -0700, Leann Ogasawara wrote:
> >> On Mon, 2011-08-08 at 18:29 +0100, Andy Whitcroft wrote:
> >> > On Wed, Aug 03, 2011 at 11:53:27PM -0700, Kees Cook wrote:
> >> > > The following changes since commit 12bf0a5416335a051be56978f8f87a2eaec143b2:
> >> > >
> >> > >   UBUNTU: Ubuntu-3.0.0-7.9 (2011-07-29 08:51:10 -0700)
> >> > >
> >> > > are available in the git repository at:
> >> > >   git://kernel.ubuntu.com/kees/ubuntu-oneiric.git master
> >> > >
> >> > > Kees Cook (1):
> >> > >       UBUNTU: [Config] enable SECCOMP_FILTER for x86 and arm
> >> > >
> >> > > Will Drewry (5):
> >> > >       UBUNTU: SAUCE: CHROMIUM: seccomp_filter: new mode with configurable syscall filters
> >> > >       UBUNTU: SAUCE: CHROMIUM: seccomp_filter: add process state reporting
> >> > >       UBUNTU: SAUCE: CHROMIUM: seccomp_filter: Document what seccomp_filter is and how it works.
> >> > >       UBUNTU: SAUCE: CHROMIUM: x86: add HAVE_SECCOMP_FILTER and seccomp_execve
> >> > >       UBUNTU: SAUCE: CHROMIUM: arm: select HAVE_SECCOMP_FILTER
> >> >
> >> > This branch looks ok in principle.  The effect is only enabled for
> >> > processes for which specific enabling action is taken.  The cost for
> >> > a non-enabled case is unchanged, leveraging the same check used for the
> >> > SECCOMP mode 1.  The patches do make some pretty large controls structures
> >> > for processes for which they are enabled.
> >> >
> >> > Overall my biggest concern is that these are pretty large, and we do not
> >> > yet know if they are going to make it upstream as they are (I believe).
> >>
> >> I have to share Andy's concern here.  Kees, Will, what's the outlook for
> >> these hitting v3.1?  It seems like it might be best to queue these in
> >> the early stages of the P-cycle to allow more time for these to firm up
> >> with upstream.
> >
> > Upstream gave Will a multi-month run-around, so while this functionality
> > may go upstream eventually, it probably won't be soon. I'm hoping to
> > break a chicken-and-egg problem by having this interface available in
> > Ubuntu (matching ChromeOS) so that all the folks that wanted to use it
> > will have a stable Ubuntu release soon to play with it in.
> >
> > Since the feature doesn't change default process behavior, and is really
> > just a container "enhancement", I feel like the risk of carrying it is
> > low and the disruption level of suddenly tearing it out is low, it's only
> > a win to have it.
> 
> Thanks - this is how we're looking at it with CrOS too.  I've tried to
> centralize as much as possible in seccomp_filter.c to minimize some of
> the future management and porting pain.  In theory, this interface
> will lay quite easily on a future (next year at best, I suspect)
> ftrace-based active, per-process event mechanism.
> 
> If there is interest in carrying it, I will certainly ensure that any
> Chromium patches provide support detection such that ubuntu users also
> get a better kernel-supported sandbox for their renderers than is
> possible today.
> 
> >> Also, Kees, have you done any specific testing of these patches?
> >
> > I have not done testing of it yet. I know Will has done a fair bit though.
> 
> Yes, and it seems robust on x86, but I'm running into a few challenges
> on ARM that will require a few small-ish tweaks (as I start to send
> patches to enable CONFIG_FTRACE_SYSCALLS on arm).

Kees, I'm seeing some build failures doing a quick test build on ARM
[1].  Did you want to disable on ARM for now or did you want to try and
fix up these failures?  Either way, care to send an updated pull request
to either fix up the build failures or disable for ARM.

Thanks,
Leann

[1]
kernel/seccomp.c: In function '__secure_computing':
kernel/seccomp.c:55:23: error: 'NR_syscalls' undeclared (first use in this function)
kernel/seccomp.c:55:23: note: each undeclared identifier is reported only once for each function it appears in
make[3]: *** [kernel/seccomp.o] Error 1
make[3]: *** Waiting for unfinished jobs....
...
kernel/seccomp_filter.c:34:25: fatal error: asm/syscall.h: No such file or directory
compilation terminated.
make[3]: *** [kernel/seccomp_filter.o] Error 1