[Oneiric][pull request] SECCOMP syscall filtering

[Will Drewry]

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

I'm not 100% aware of your kernel release cycle, so I can't provide
any helpful commentary there.

Thanks for the consideration!
will