SELinuxDenyPtrace: Write, compile, run, but don't debug applications?

[Daniel J Walsh]

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.