|From:||Andrea Arcangeli <andrea-AT-cpushare.com>|
|To:||Ingo Molnar <mingo-AT-elte.hu>|
|Subject:||Re: seccomp for 2.6.11-rc1-bk8|
|Date:||Fri, 21 Jan 2005 21:24:20 +0100|
|Cc:||Andrew Morton <akpm-AT-osdl.org>, linux-kernel-AT-vger.kernel.org|
On Fri, Jan 21, 2005 at 01:47:01PM +0100, Ingo Molnar wrote: > > * Ingo Molnar <email@example.com> wrote: > > > > This is the seccomp patch ported to 2.6.11-rc1-bk8, that I need for > > > Cpushare (until trusted computing will hit the hardware market). > > > [...] > > > > why do you need any kernel code for this? This seems to be a limited > > ptrace implementation: restricting untrusted userspace code to only be > > able to exec read/write/sigreturn. > > > > So this patch, unless i'm missing something, duplicates in essence what > > ptrace can do [...] > > there's one thing ptrace wont do: if the ptrace parent dies unexpectedly > and the child was 'running' (there is a small window where the child You got it, I couldn't use ptrace right now. Pavel already suggested it and I told him the problem with the parent being killed by oom. > might not be stopped and where this may happen) then the child can get > runaway. While i think this is theoretical (UML doesnt suffer from this > problem), it is simple to fix - find below a proof-of-concept patch that > introduces PTRACE_ATTACH_JAIL - ptraced children can never escape out of > such a jail. (barely tested - but you get the idea.) IMHO the complexity of ptrace makes it by definition less secure than seccomp. Seccomp is extremely simple and self contained. This is why I still prefer seccomp to fixing ptrace w.r.t. security. Fixing ptrace w.r.t. security-tracing it'd be still nice, but I'd prefer not to relay on ptrace when something as simple and robust as seccomp can be implemented instead. However if the kerneel folks wants me to use a "fixed version of ptrace", I could use it too (performance isn't the issue). In _theory_ you're right it'd be completely equivalent after fixing the problem with the parent dying unexpectedly. But from my part in practice I prefer to relay _only_ on the much simpler seccomp patch (and on trusted computing as soon as the hardware is available). Even trusted computing will be less secure than seccomp from the point of view of the seller (because it's a lot more complicated than seccomp), but unlike with ptrace, the buyer will get both privacy guarantees and guarantees about reliably results too (only against software attacks). Having those two guarantees for the buyer will be fundamental, so it will worth to decrease the seller security a bit to give these guarantees to the buyer (I'll most certainly leave an exchange for seccomp at the same time I start the trusted computing exchange, so if some seller doesn't trust the trusted computing code, they can stick with the very secure seccomp approach), but right now, seccomp seems the most secure solution from the seller standpoint, and the buyer won't notice the difference between ptrace and seccomp. Thanks.
Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds