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

[Daniel J Walsh]

On 04/11/2012 10:21 AM, Matthew Garrett wrote:
> 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.
> 


deny_ptrace will be DISABLED for F17.  Already checked in.


I think we can have levels of denial. Once we can separate out gdb foobar from
gdb -p 1234, we can have multiple booleans, to deny different accesses, and
allow the administrator to choose which level can be blocked.

And yes if a process gets enough control to fool the user, then we have lost.
 But we are basically after incremental improvements in the security.