Linux kernel minor "seccomp" vulnerability

I just released some technical details on why and how "seccomp" is vulnerable to the Linux kernel syscall filtering problems that I previously blogged about. The full details may be found here:

http://scary.beasts.org/security/CESA-2009-004.html

The actual bug is of little significance because pretty much no-one uses seccomp:

This searches for the PR_SET_SECCOMP string on Google Code Search

In addition, even if people did use this -- the bug is not a full break out, just some leakage of filesystem names via stat() or mischief via unrestricted chmod().

However, I still find this vulnerability interesting. It's a sobering reminder that even a very simple security technology can have surprising bugs. seccomp applies extremely tight restrictions on untrusted code, but within these constraints, the code still has opportunities to misbehave! And this isn't the only example. For reference, check out how a seccomp-constrained process could historically cause trouble in the syscall tracing path with:

CVE-2007-4573: trouble with the upper 32-bits of %rax not clear

CVE-2008-1615: trouble calling syscalls with a bad value in the %cs register

CVE-2004-0001: trouble with EFLAGS, unknown trigger