Candidate replacement approach for seccomp_filter (no ftrace)

[Will Drewry]

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!

thanks,
will