Re: [2.6 patch] let CONFIG_SECCOMP default to n

[andrea@cpushare.com]

I think this thread is not worth reading but since you tell me that I
am affected by NIH syndrome...

On Wed, Jul 12, 2006 at 11:13:58PM +0200, Ingo Molnar wrote:
> But he chose not to do so - and that has nothing to do with being unable 
> to improve ptrace - it evidently is improvable. So i see SECCOMP being 
> the result of the NIH syndrome.

	http://www.cpushare.com/hypermail/cpushare-discuss/06/01/0086.html

	"so if you walk this thought-experiment a bit, you'll quickly arrive to a 
	virtual machine that is actually pretty useful already, and is fully 
	provable. You should not dismiss this as "I dont trust it because it's 
	at ring 0", unless you can show some fatal flaw in my thinking."

In short a few months ago you told me that instead of using SECCOMP I
should filter and run the resulting filtered (but originally
untrusted) bytecode in ring0 inside the kernel without any memory
protection, because your filter was a lot more than the "int 0x80
checks plus jump offsets checks" (that Alan just mentioned), you
suggested a sort of kernel virtual machine that you just invented that
would verify where the bytecode could touch the ram. So the first bug
in this hugely complicated (and IMHO nearly impossible to implement
filter due the lack of memory protection) gives the attacker ring0
privilege because it all runs inside the kernel...

If it's you, inventing it the huge complicated insecure and probably
impossible to realize virtual machine in the kernel, it's ok. While if
it's me, I should be using ptrace instead of the simpler and much more
secure seccomp. If the above is not NIH syndrome I don't know what
that is.

About your first claim, as far as I'm concerned, if I use seccomp or
ptrace it doesn't change anything at all for me. It only changes for
the *users* because if I use ptrace they'll be less secure.

If not obvious yet the reasons of seccomp are multiple.

1) gdb (all buyers of the CPU resources will need a way to debug their
   own bytecode by running the sell client on their own machine, if
   something goes wrong). If seccomp will be used by others to do
   secure decompression, the fact gdb will keep working will be
   welcome for the same reason.
2) strace (I used it quite a lot of times to debug problems in seccomp
   bytecode myself already, it has been a fundamental debugging tool
   as usual)
3) not being susceptible to the newest ptrace addition of the day (you
   just mentioned a ptrace rework with the utrace framework).
4) I didn't want to require an userland knowledge of kernel details
   like syscall numbers and signal details for all archs (the signal
   part could even go out of sync with the kernel).
5) being simple, so less likely to be buggy. ptrace security is
   extremely complex, just the case where the ptracer tasks gets
   killed and the ptraced tasks must be synchronously sigkilled too is
   a controlled race in itself (that again could break after the
   frequent ptrace reworks you just mentioned and since it's a race
   condition it may go unnoticed for a while).
6) Ptrace is generally not being used for critical security features,
   it's primarly a debugging kludge, and others (including my ex. prof) are
   using it for virtualization similar in UML. But they're not running
   untrusted bytecode inside UML or in their virtualization software.
   No major outbreak would happen if ptrace suddenly breaks after one
   of the frequent reworks that you just mentioned.