lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 13 Jan 2012 01:34:46 +0000 From: Jamie Lokier <jamie@...reable.org> To: Will Drewry <wad@...omium.org> Cc: Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org, keescook@...omium.org, john.johansen@...onical.com, serge.hallyn@...onical.com, coreyb@...ux.vnet.ibm.com, pmoore@...hat.com, eparis@...hat.com, djm@...drot.org, torvalds@...ux-foundation.org, segoon@...nwall.com, jmorris@...ei.org, scarybeasts@...il.com, avi@...hat.com, penberg@...helsinki.fi, viro@...iv.linux.org.uk, luto@....edu, mingo@...e.hu, akpm@...ux-foundation.org, khilman@...com, borislav.petkov@....com, amwang@...hat.com, oleg@...hat.com, ak@...ux.intel.com, eric.dumazet@...il.com, gregkh@...e.de, dhowells@...hat.com, daniel.lezcano@...e.fr, linux-fsdevel@...r.kernel.org, linux-security-module@...r.kernel.org, olofj@...omium.org, mhalcrow@...gle.com, dlaor@...hat.com Subject: Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF 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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists