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