Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Ingo Molnar]

* Andrew James Wade <andrew.j.wade@xxxxxxxxx> wrote:

> And that's where fail-safe and simple design comes in. In this 
> application an oops is better than a jail-break by orders of 
> magnitude. But then that's why you wrote seccomp instead of using 
> ptrace in the first place.

actually, the client side of ptrace isnt all that more complex. I guess 
one of the main problems with using ptrace was that it has no catchy 
name that Andrea could claim for his project and that it couldnt be 
patented ;-)

Andrea could have isolated the 'client side' functionality of ptrace 
(which is often confused with the 'server side' of ptrace - where the 
overwhelming majority of ptrace security holes were located) and he 
could have made it simple to review, to get a comparable 'feeling' of 
security. [User Mode Linux uses the client-side ptrace model to execute 
untrusted code.]

Andrea could also have extended ptrace to solve whatever marginal 
problems he has with ptrace. [in fact such extension of ptrace was 
posted recently, see Roland McGrath's utrace framework!]

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.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/