|
Message-ID: <2c35ec26f6337fa0ebe1ebfba1041244.squirrel@webmail.greenhost.nl> Date: Thu, 24 May 2012 21:39:09 +0200 From: "Indan Zupancic" <indan@....nu> To: "H. Peter Anvin" <hpa@...or.com> 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 Thu, May 24, 2012 20:45, H. Peter Anvin wrote: > 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. How? All that seccomp can do is deny system calls and kill the task. What you describe sounds more like ptrace. > > 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. Seccomp can't change system calls, only prevent them, so I miss how it can change anything for UML in that way. > > (Note: that being said, UML might very well be better done using seccomp > filters *instead* of ptrace, but that's another matter.) Well, obviously it will use seccomp filters instead of ptrace when possible and do the more complicated stuff via PTRACE_SECCOMP_EVENT when seccomp isn't sufficient. But mainly for performance reasons. > > 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. "process is traceable" should be "process is able to trace". Greetings, Indan
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.