[Oneiric][pull request] SECCOMP syscall filtering

[Will Drewry]

On Wed, Aug 17, 2011 at 3:28 PM, Leann Ogasawara
<leann.ogasawara at canonical.com> wrote:
> On Fri, 2011-08-12 at 16:09 -0500, Will Drewry wrote:
>> 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).
>
> Kees, I'm seeing some build failures doing a quick test build on ARM
> [1].  Did you want to disable on ARM for now or did you want to try and
> fix up these failures?  Either way, care to send an updated pull request
> to either fix up the build failures or disable for ARM.
>
> Thanks,
> Leann
>
> [1]
> kernel/seccomp.c: In function '__secure_computing':
> kernel/seccomp.c:55:23: error: 'NR_syscalls' undeclared (first use in this function)
> kernel/seccomp.c:55:23: note: each undeclared identifier is reported only once for each function it appears in
> make[3]: *** [kernel/seccomp.o] Error 1
> make[3]: *** Waiting for unfinished jobs....
> ...
> kernel/seccomp_filter.c:34:25: fatal error: asm/syscall.h: No such file or directory
> compilation terminated.
> make[3]: *** [kernel/seccomp_filter.o] Error 1

Yup - it's broken on ARM.  My apologies!

While I proposed wiring up NR_syscalls upstream yesterday,  it uses
syscall numbers as indices like ftrace_syscalls does which is not ARM
friendly.  I am testing out a larger change to the patch to remove all
references to NR_syscalls unless CONFIG_FTRACE_SYSCALLS is enabled.  I
hope to have a better version available quite shortly.  I had failed
to notice that I broke all these other platforms during the patchset
churn on LKML.

Sorry for the breakage!
will