Re: secure computing for 2.6.7

[Andrea Arcangeli <andrea@cpushare.com>]

On Sun, Aug 01, 2004 at 06:29:05PM +0100, chris@scary.beasts.org wrote:
> Using the above approach, we (the app writers) would never agree on the
> syscall lists required for different seccomp modes ;-)

I see the problem ;).

> How hard would it be to have a per-task bitmap of syscalls allowed? This
> way, a task could restrict to the exact subset of syscalls required for
> maximum security.
> The bitmap would
> - Be allocated on demand (for no overhead in the common case)
> - Deny all syscalls not covered by the supplied bitmap, to cater for
> syscall table expansion
> - Be inherited across fork and (probably) shared across clone

your app will have then to learn about the syscall details of every
arch (which is normally a kernel internal thing), the most obvious
example is the difference between the sigreturn and rt_sigreturn, plus
the syscall numbers vary across every arch and the bitmap will have to
differ depending on the architecture (while the seccomp mode number is a
fixed interface for all archs and it hides all internal details like
sigreturn/rt_sigreturn). The one thing I don't like is that if somebody
changes the signal frame to use a new_rt_sigreturn the app will break
and I'll have to upload an update and I'll have again to check for uname
-r to know which kernel has to enable what. I mean when the new
behaviour is introduced it won't be too bad, it'll just get a false
positive sigkill, it could happen as well if somebody forgets to update
seccomp.c after changing the signal frame.

While I only get disavantages from the bitmap, if people really want the
arch dependent bitmap I'm certainly able to put kernel architectural
internal knowledge into some python code that will build the right
bitmap depending on the arch and depending on the uname -r.

So it's up to you. Feel free to discuss and choose what you prefer. I'm
biased and I prefer seccomp, you can still implement the bitmap on top
of seccomp as seccomp mode == 2. I'm not saying you shouldn't get the
bitmap, my previous suggestion of syscalltable that would parse as well
the parameters was a lot more complicated than the bitmap, doing the
bitmap on top of seccomp will be easy (we could add some more storage
into the seccomp file too, so if you write number 2 followed by data,
the kernel will allocate such later data afte the first 32bits, as a
bitmap). And still the seccomp mode will provide you the infrastructure
and the entry point. This is actually simple enough (not comparable to
the syscalltables) that I can implement it myself if you agree on this
direction (next weekend).