SELinuxDenyPtrace and security by default

ptrace() exists primarily to facilitate debugging; it is used by debuggers like gdb to stop and start a process, set breakpoints, and to examine and change memory contents. Other useful commands, like strace, also need ptrace() to function properly. The rules for ptrace() were designed in the era of relatively isolated, multi-user systems; their primary intent is to protect users from each other. So an unprivileged user is unable to use ptrace() on a process owned by a different user. But any user can employ ptrace() freely on his or her own processes.

As Dan Walsh has noted, the effects of this policy can be surprising for contemporary users:

In other words, anybody who can run code as a given user (through an exploit, say, or via a browser plugin) can use ptrace() to examine (and change) the behavior and memory of any other process owned by that user. The potential for the compromise of personal information is clear. How to solve that problem is, perhaps, a bit less so.

Dan's answer is a Fedora feature called SELinuxDenyPtrace. As one might expect from the name, this feature uses SELinux policy to disable access to the ptrace() command for all users. When Fedora's engineering steering committee (FESCO) approved this feature for the Fedora 17 release, most of its members were apparently under the impression that the feature would be turned off by default; indeed, the feature page still says:

Given that, a number of early testers of the upcoming Fedora 17 beta release have been surprised to discover that the feature is, instead, turned on by default. As a result, commands like gdb and strace fail to work. The KDE "DrKonqi" crash reporter is also broken by this setting. Needless to say, software development on such a system is a less enjoyable task. The resulting behavior is also simply surprising; as Mark Wielaard put it when he raised the issue:

Dan responded that "if you understand what ptrace or gdb are, you probably can figure out how to turn this feature off." Others, however, have argued that a Fedora install should be useful to developers by default and that forcing developers to figure out how to toggle an SELinux setting is a step in the wrong direction. As of this writing, it appears that this argument has prevailed and that ptrace() will be enabled by default in the Fedora 17 final release.

Should that happen, though, the question is likely to return in the Fedora 18 cycle. And Fedora is not alone in this quest; Ubuntu, too, has disabled the use of ptrace() by default, though the mechanism used in this case (the Yama security module) is different. Various other attempts to restrict the capabilities of running processes exist; these include Android's "every program gets its own user ID" model, reducing the set of available system calls with seccomp, and more. There appears to be little disagreement with the idea that we are surrounded by security threats and that our systems need to become more secure as a result. Protecting a single user's processes from each other is one way (out of many) to address those threats.

On the other hand, there is disagreement over the extent to which becoming more secure should inconvenience or disrupt the work of users. A powered-down machine is quite resilient against online attacks, but users tend to complain about how long it takes to get their work done on such a system. Security developers naturally tend to see the costs of their work as small, easily borne, and more than justified by the benefits; users, for whom the costs are much more immediate, tend to disagree. The result is a lot of tension surrounding security-related decisions.

To an extent, this tension can be a good thing; it can, in the long term, motivate the development of more useful and less intrusive security technologies. But it can frustrate users, who may feel that functionality is being taken from them for no good reason; it can also frustrate security developers who find their efforts to protect those users thwarted. Unfortunately, there is often no easy answer; security is a trade-off with both costs and benefits. So, while the default setting for deny_ptrace in Fedora 17 may have been pushed in the "convenience for users" direction, we can expect the wider discussion to be with us for some time.