Re: [patch] let CONFIG_SECCOMP default to n

Ingo Molnar
2006-07-12T21:28:29Z

* Andi Kleen <ak@suse.de> wrote:

> I liked the idea. While this can be done with LSM (e.g. apparmor) too
> seccomp is definitely much easier and simpler and more "obviously
> safe" than anything LSM based.

LSM is probably too heavy for this - but utrace (posted by Roland
McGrath a few weeks ago) is alot more focused on modularizing ptrace
features. utrace also solves a whole host of other issues that we have
with ptrace!

for example the first sample utrace module that Roland posted was a
'stop the task if it becomes undebugged, instead of letting the task run
away'. That solves precisely the ptrace property that Andrea complained
about most.

i think Andrea didnt even try to fix/generalize ptrace perhaps because
that would make his 'security feature' too banal? It would also become
unpatentable? Even though this decision hurts the 'reach' of his project
fundamentally: ptrace support is everywhere, and users could very much
and consciously decide to run 'compatible ptrace' or 'more secure
ptrace' [provided by newer kernels].

Andrea's "ptrace is insecure" argument is just plain FUD: there's
nothing inherently insecure about the _client side_ of the ptrace APIs
or the client side of ptrace implementation. So my suggestion is to get
utrace in, to implement an utrace module that implements untrusted code
execution and then lets get rid of seccomp.

Ingo