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