[Oneiric][pull request] SECCOMP syscall filtering

Kees Cook kees.cook at canonical.com
Thu Aug 11 19:08:55 UTC 2011


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.

> 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.

-Kees

-- 
Kees Cook
Ubuntu Security Team




More information about the kernel-team mailing list