Candidate replacement approach for seccomp_filter (no ftrace)

[Leann Ogasawara]

On Fri, 2012-01-27 at 10:27 -0800, Kees Cook wrote:
> On Fri, Jan 27, 2012 at 9:21 AM, Will Drewry <wad at chromium.org> wrote:
> > On Fri, Jan 27, 2012 at 10:50 AM, Andy Whitcroft <apw at canonical.com> wrote:
> >> On Fri, Jan 27, 2012 at 10:35:23AM -0600, Will Drewry wrote:
> >>
> >>> Looking at the oops, it appears to be in ftrace filter creation.  It's
> >>> possible that ftrace changes its internals in the middle of that
> >>> kernel roll and create_preds is walking off into space.  I can take a
> >>> look, if needed - let me know.
> >>
> >> So are the old and new patch sets semantically equivalent to the seccomp
> >> consumer?  At the time we took the previous patch set I seem to remember
> >> it was to enable seccomp use by the chromium-browser.  Is that going to
> >> work with the new patch set?
> >
> > The ABI is largely different.  I didn't land the chromium-browser
> > sandbox based on the ftrace solution as I wanted to finish exploring
> > every last nook and cranny of ftrace integration.  At the time, I was
> > hope that the exact same ABI would be servicable for any future
> > solution.  The assumption would be that it would be ftrace-based.  But
> > after the last few months of experimenting, it's turned out that
> > ftrace didn't have a good path forward for syscall filtering.
> >
> > At present, I don't believe there are any active consumers of
> > seccomp+ftrace except for chromium os's minijail which isn't in
> > widespread use outside of chromium os.
> >
> > That said, it is not difficult to wrap the ABI with a helper that
> > parses the same ftrace-style strings -- but the prctl calls will be
> > quite different.
> >
> > If there is interest in keeping the ftrace patchset in lieu of new
> > work, I will go ahead and integrate it as a sandboxing option for
> > Ubuntu users, but if there's any chance of us using the new patch
> > series across most platforms, then it means one less fork in the road.
> >  I had said that Chromium will use it, and I'll certainly add it for
> > Ubuntu users if that is the best sandboxing solution for them!
> 
> At this point, since there are no consumers of the old API, and it
> will be almost certainly replaced by the BPF API, I think in the face
> of the 5-year support of the LTS release, we should probably just
> remove all of the seccomp_filter patches from Ubuntu.

Given the above statement, I've reverted all of the seccomp_filter
patches from our Precise 12.04 git repo.  I plan to upload shortly which
means this will be removed for the Precise Alpha-2 release.

I would however add that I've started opening the Precise+1, ie Q,
Ubuntu kernel git repo.  I've rebased it to v3.3-rc1 and am just
cleaning up some build failures.  I'd be happy to consider carrying the
updated seccomp_filter patches there, just send a pull request once I've
officially got the ubuntu-q repo pushed (I'll send email to this list when it's
ready).

Thanks,
Leann