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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
