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.