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