Candidate replacement approach for seccomp_filter (no ftrace)

Kees Cook keescook at chromium.org
Fri Jan 27 18:27:33 UTC 2012


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.

-Kees

-- 
Kees Cook
ChromeOS Security




More information about the kernel-team mailing list