The Unix process model gives each process its own address space and
isolates processes from each other; one process cannot access another's
memory unless the two have explicitly agreed to share it. This boundary
should enable one process to keep secrets from another, but there is an
exception: the walls
between process can be breached with the
call. With the goal of improving security, distributors have been making
changes to make that wall harder to penetrate. But, as a discussion
regarding security options in the upcoming Fedora 17 release shows,
there is an ongoing tension between the goals of improving security and
making a distribution that is useful to its users.
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:
Most people do not realize that any program they run can examine
the memory of any other process run by them. Meaning the computer
game you are running on your desktop can watch everything going on
in Firefox or a programs like pwsafe or kinit or other program that
attempts to hide passwords.
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:
The deny_ptrace boolean will deny all processes even the
unconfined_t domain from being able to ptrace other
domains. Because of this it will be optional and turned off by
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:
It seems a little odd that a user is now allowed to write, compile
and run their own programs, but then wouldn't be allowed to debug
them by default.
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
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.
to post comments)