On Thu, Jan 12, 2012 at 2:18 PM, Will Drewry <wad@xxxxxxxxxxxx> wrote: > On Thu, Jan 12, 2012 at 11:40 AM, Steven Rostedt <rostedt@xxxxxxxxxxx> 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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
