Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF

[Jamie Lokier]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/