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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120113013446.GU7180@jl-vm1.vm.bytemark.co.uk>
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/