SELinuxDenyPtrace: Write, compile, run, but don't debug applications?

Matthew Garrett mjg59 at srcf.ucam.org
Wed Apr 11 14:21:13 UTC 2012


On Wed, Apr 11, 2012 at 03:58:55PM +0200, Mark Wielaard wrote:
> On Tue, 2012-04-10 at 14:04 +0100, Matthew Garrett wrote:
> > Option 2: Disable ptrace for everything except direct child processes. 
> > Allows the common case of running a task directly under a tool like gdb 
> > or strace, but forbids attaching one to an already running task. May 
> > break some of the same tools as option 1. Ubuntu defaults to this 
> > behaviour.
> 
> This refers to the proposal to deny PTRACE_ATTACH, but not
> PTRACE_TRACEME? Is that really that significant in the security
> analysis? The threat as I understand it is that someone could read the
> memory of gnome-key-ring and get access to private keys or passwords
> protecting the private keys. But if an attacker can trace an invocation
> of say gnome-keyring-daemon --replace isn't that just as bad?

If the user can inject enough code into an unconfined application to 
invoke another application and trace that, the user can inject enough 
code into an unconfined application to just pop up something that looks 
like a keyring prompt and get the user credentials that way.

> > To a first approximation, simply auditing the distribution for anything 
> > that opens files or reads information from the network and forbidding 
> > them ptrace access (and denying ptrace access from any existing confined 
> > domains except, maybe, staff_t) seems like it would get us most of the 
> > way to option 4 without breaking existing user expectations. What am I 
> > missing that makes this infeasible?
> 
> As far as I understand, this would work, if anything spawned from
> firefox would also be in a no-introspection-context. But not in time for
> F17. So the questions really is whether or not we keep breaking user
> expectations and make developers "unbreak" their machines in F17.

I'm in favour of keeping ptrace available for F17 - I don't think we've 
had enough opportunity to discuss the tradeoffs.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org


More information about the devel mailing list