Messages in this thread | | | Date | Mon, 2 Aug 2004 01:06:47 +0200 | From | Andrea Arcangeli <> | Subject | Re: secure computing for 2.6.7 |
| |
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). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |