Will Drewry wrote: > >> > There's already a security model around who can use ptrace(); speeding > >> > it up needn't break that. > >> > > >> > If we'd had BPF ptrace in the first place, SECCOMP wouldn't have been > >> > needed as userspace could have done it, with exactly the restrictions > >> > it wants. Google's NaCl comes to mind as a potential user. > >> > >> That's not entirely true. ptrace supervisors are subject to races and > >> always fail open. This makes them effective but not as robust as a > >> seccomp solution can provide. > > > > What races do you know about? > > I'm pretty sure that if you have two "isolated" processes, they could > cause irregular behavior using signals. Do you have an example? I'm not aware of one and I've been studying ptrace quite a bit lately. If there's a race (other than temporary kernel bugs with all the ptrace patching lately ;-), I would like to know and maybe patch it. The only signal confusion when ptracing syscalls I'm aware of is with SIGTRAP, and that was fixed in 2.5.46, long, long ago (PTRACE_SETOPTIONS). > > I'm not aware of any ptrace races if it's used properly. I'm also not > > sure what you mean by fail open/close here, unless you mean the target > > process gets to carry on if the tracing process dies. > > Exactly. Security systems that, on failure, allow the action to > proceed can't be relied on. That's fair enough. There are numerous occasions when ptracer death should kill the tracee anyway regardless of security. E.g. "strace command..." and strace dies, you'd normally want the command to be killed as well. So that could be worth a ptrace option anyway. Thanks, -- Jamie -- 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