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

Mark Wielaard mjw at
Wed Apr 11 13:58:55 UTC 2012

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?

> Option 4: Identify the set of most vulnerable applications, run them in 
> confined domains and either forbid them access to ptrace or permit them 
> only to ptrace children.

This might expand to most/all gui applications (since it would
necessarily include any "viewers" that applications spawn for showing
downloaded remote data), but this seems a better option to me.

> 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.



More information about the devel mailing list