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.
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?
--
Matthew Garrett | mjg59(a)srcf.ucam.org