Messages in this thread | | | Date | Wed, 12 Jul 2006 23:22:45 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] let CONFIG_SECCOMP default to n |
| |
* 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |