Re: [2.6 patch] let CONFIG_SECCOMP default to n

Ingo Molnar
2006-07-12T21:19:35Z

* Andrew James Wade <andrew.j.wade@gmail.com> 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