Messages in this thread | | | From | Andrew Lutomirski <> | Date | Thu, 12 Jan 2012 15:00:46 -0800 | Subject | Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF |
| |
On Thu, Jan 12, 2012 at 2:18 PM, Will Drewry <wad@chromium.org> wrote: > On Thu, Jan 12, 2012 at 11:40 AM, Steven Rostedt <rostedt@goodmis.org> wrote: >> On Thu, 2012-01-12 at 17:30 +0000, Jamie Lokier wrote: >> >>> You can do this now, using ptrace(). It's horrible, but half of the >>> horribleness is needing to understand machine-dependent registers, >>> which this new patch doesn't address. (The other half is a ton of >>> undocumented but important ptrace() behaviours on Linux.) >> >> Yeah I know the horrid use of ptrace, I've implemented programs that use >> it :-p >> >> I guess ptrace can capture the execv and determine if it is OK or not to >> run it. But again, this doesn't stop the possible attacks that could >> happen, with having the execv on a symlink file, having the ptrace check >> say its OK, and then switching the symlink to a setuid file. >> >> When the new execv executed, the parent process would lose all control >> over it. The idea is to prevent this. >> >> I like Alan's suggestion. Have userspace decide to allow execv or not, >> and even let it decide if it should allow setuid execv's or not, but >> still allow non-setuid execvs. If you allow the setuid execv, once that >> happens, the same behavior will occur as with ptrace. A setuid execv >> will lose all its filtering. > > In the ptrace case, doesn't it just downgrade the privileges of the new process > if there is a tracer, rather than detach the tracer? > > Ignoring that, I've been looking at system call filters as being equivalent to > something like the caps bounding set. Once reduced, there's no going > back. I think Linus's proposal perfectly resolves the policy decision around > suid execution behavior in the run-with-privs or not scenarios (just like with > how ptrace does it). However, I'd like to avoid allowing any process to > escape system call filters once installed. (It's doable to add > suid/caps-based-bypass, but it certainly not ideal from my perspective.)
I agree.
In principle, it could be safe for an outside (non-seccomp) process with appropriate credentials to lift seccomp restrictions from a different process. But why?
--Andy -- 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/
| |