Re: [patch] let CONFIG_SECCOMP default to n

[andrea@cpushare.com]

Hello,

On Thu, Jul 13, 2006 at 01:43:42AM -0400, Albert Cahalan wrote:
> SECCOMP is a good idea, but currently a tad too limiting.
> There are a few dozen system calls that would be safe and useful,
> particularly those related to signals, memory, and synchronization.

malloc/free can be emulated in userland so that's not a big
problem. All the rest is a problem instead, unmodified software just
won't run.

seccomp mode 1 is the absolute minimum you need to compute ;). Every
single syscall we add it gets less secure. Several exploits happened
in mremap for example, even if at first glance it may sound a safe
syscall. It's safe now, but it may get buggy again later as new
features are being added.

I'd be skeptical adding seccomp mode 2 with more syscalls, otherwise
it's better to make it more flexible and to specify the syscalls to
allow from userland (which I'm not against if you've usages for it).

>From my part to go beyond seccomp, as jail for the interpreters I'll
probably use virtualization like ourgrid and tycoon (seccomp is the
safest and simplest mode but there's simply no way to run an
interpreter under it ;).