On 04/10/2012 09:04 AM, Matthew Garrett wrote:
On Tue, Apr 10, 2012 at 11:27:12AM +0200, Michael Scherer wrote:
> Le mardi 10 avril 2012 à 02:57 +0100, Matthew Garrett a écrit :
>> Ok, so if anything that's already a likely target of attack is unable
>> to initiate ptrace or start a process that can ptrace, what real extra
>> security do we gain by disabling it by default?
>
> AFAIK, firefox is not running in a confined domain, and that's a valuable
> target of attack. The same could be said of some others applications (
> like acroread, etc ).
Ok, so maybe we should talk about what an ideal world looks like, and then
we can figure out how to get there.
Aim: To prevent compromised applications using ptrace to obtain personal
information from other applications, or to modify the behaviour of and so
compromise other applications.
Option 1: Disable ptrace globally. Breaks developer tools like gdb and
strace, and certain crash reporting applications that either directly
attach to an application to generate a backtrace or attach gdb to a running
application to generate a backtrace.
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.
I think this is still valuable since it can disable ptrace capability for all
users, even though it will be disabled by default.
Option 3: Have gdb and strace run in a specialised domain that
permits
ptrace, while forbidding it in general. Difficult at present because an
attacker can just write out an attack binary and relabel it appropriately,
or alternatively launch gdb directly and use it to perform the injection
into another process.
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.
Option 2 seems mildly preferable to option 1, but not significantly so.
Option 3 seems unrealistic. Option 4 seems like it would benefit everyone
without breaking anything, but is more work than the others.
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?
The problem with option 4 is that it is very difficult to do since the desktop
is so connected. Say we isolate firefox_t as the same as unconfined_t without
ptrace.
firefox_t == unconfined_t -ptrace;
firefox_t can start lots of helper apps, should the helper apps run as
firefox_t or unconfined_t? If unconfined_t start office it runs as
unconfined_t if firefox starts it, it runs as firefox_t, if unconfined_t
office is running the firefox_t can cause it to open a new document, which
could somehow trigger gdb...
What about the dbus session bus, Can firefox_t start a gdb session via the
session but to get around the confinement?
This is why I developed sandbox, since the desktop was so interconnected
trying to isolate permissions from apps such as chrome and firefox, is almost
impossible without breaking critical functionality.