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