LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecuritySELinuxDenyPtrace and security by defaultThe 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 ptrace() system 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
default.
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 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.
Brief items Security quote of the week
DRM is supposed to prevent piracy and illegal file sharing. In order to
provide DRM, you need at least $10,000 up front to cover software, server,
and administration fees, plus ongoing expenses associated with the
software. In other words, much bigger operating expenses than a small
business can afford. By requiring retailers to encrypt e-books with DRM,
big publishers are essentially banning indie retailers from the online
marketplace.
-- Ruth Curry
DRM is like the anti-theft sensors by the doors at the drugstore. The sensors go off all the time, but they still can’t stop a crafty teenager who knows how to remove a magnetic tag — nor can they stop criminals who break in and steal directly from the till. Similarly, DRM prevents a lot of legitimate, noncriminal usage while remaining unable to stop actual, intentional piracy, or its crafty teenage equivalent: someone with internet access and the ability to type “remove DRM” into Google.
Remote root hole in SambaThe Samba team has announced the release of versions 3.6.4, 3.5.14 and 3.4.16 containing a fix for a remote code execution vulnerability. "As this does not require an authenticated connection it is the most serious vulnerability possible in a program, and users and vendors are encouraged to patch their Samba installations immediately." Distributor updates should start showing up in the near future.Update: the Samba 4 alpha releases are vulnerable as well; 4.0alpha19 has been released with a fix.
AT&T Microcell FAIL (FailOverflow)The FailOverflow site has an amusing look inside an AT&T microcell box which, naturally, runs Linux. "The backdoor uses simple UDP packets to transmit requests and receive responses. There are a number of operations supported, but the most useful one is called ‘BackdoorPacketCmdLine’. Yes. It’s actually called ‘Backdoor’. This command lets you execute any linux command. Execution is performed using the backticksh function." This port turns out to be globally accessible. (Thanks to Paul Wise).
Wheeler: Insecure open source software libraries?David A. Wheeler cautions against the practice of using bundled libraries. This is probably is not news to many LWN readers, but it does serve as a reminder. "An advantage of OSS is that many people can review the software, find problems (including vulnerabilities), and fix them… but this advantage is lost if the fixed versions are not used!"
Medical device hack attacks may kill, researchers warn (BBC News)GNOME foundation executive director Karen Sandler makes an appearance in a BBC News article about the security risks of medical implants:
That ideological bent meant she [Sandler] was keen to find out about the computer code running on any device that might be inserted in her body.
Unfortunately, she told the BBC, the implant's maker would not reveal its software. Its reassurances about the code's integrity did not help. "Knowing what I know about software I'm sure it'll have bugs," she said. Ms Sandler was also worried about the fact that increasing numbers of implants broadcast information all the time. That wireless link was a step too far for her. LWN has covered several talks (1, 2) that Sandler has given on this topic as well.
New vulnerabilities chromium: multiple vulnerabilities
drupal7-ctools: cross-site scripting
inspircd: code execution
openstack-keystone: denial of service
puppet: multiple vulnerabilities
python-paste-script: insecure root GID accessible files
samba: remote code execution
sectool: privilege escalation
taglib: multiple vulnerabilities
tiff: code execution
virtualbox: multiple unspecified vulnerabilities
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||