Date: Thu, 24 May 2012 11:45:21 -0700 From: "H. Peter Anvin" <hpa@...or.com> To: Indan Zupancic <indan@....nu> CC: Roland McGrath <mcgrathr@...gle.com>, Will Drewry <wad@...omium.org>, linux-kernel@...r.kernel.org, netdev@...isplace.org, linux-security-module@...r.kernel.org, kernel-hardening@...ts.openwall.com, mingo@...hat.com, oleg@...hat.com, peterz@...radead.org, rdunlap@...otime.net, tglx@...utronix.de, luto@....edu, serge.hallyn@...onical.com, pmoore@...hat.com, akpm@...ux-foundation.org, corbet@....net, markus@...omium.org, coreyb@...ux.vnet.ibm.com, keescook@...omium.org, viro@...iv.linux.org.uk, jmorris@...ei.org Subject: Re: [RFC PATCH 0/3] move the secure_computing call On 05/24/2012 11:27 AM, Indan Zupancic wrote: > > If so, then the seccomp check needs to be redone after any ptrace > changes, or we should give up and just do the seccomp check first, > instead of possibly looping forever. PTRACE_EVENT_SECCOMP has the > same problem. > > If a seccomp filtered task can do ptrace(), it can easily bypass > the seccomp filter by ptracing any task not under the same filter > but from the same user. And then it can puppeteer the victim into > doing anything it wishes. So pretending seccomp can make a ptracer > secure is futile, I think. Perhaps it's better to keep it simple and > always do the seccomp test first and ignore ptrace changes, however > sad that may seem. Seccomp had the power to stop ptrace(). It didn't, > so it shouldn't try to do it afterwards either. > > It's a bit fuzzy though, only reason why doing seccomp first is more > convenient is because seccomp can generate ptrace events. I don't > think it will make a difference in practice because ptrace(2) won't > be allowed by seccomp filters anyway, so it's a bit of a theoretical > problem. > No, that's not the reason to do seccomp first. The reason to do seccomp first is that a seccomp filter can be part of the process execution and can completely transform the system call picture. Consider UML, for example. It uses ptrace to capture system calls and execute them on the behalf of the process. It needs to know what system calls *actually* are done by the virtual process. (Note: that being said, UML might very well be better done using seccomp filters *instead* of ptrace, but that's another matter.) I agree with you, if the process is traceable it is rather questionable to claim any kind of security; more likely consider that a debugging mode and tell people to lock out ptrace for real sandboxing. -hpa
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.