LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityLinux capabilities support for user namespacesLinux capabilities are a sparsely used kernel facility to add granularity to the set of privileges that a process can have. By using capabilities, an administrator can grant a process a limited set of privileges, rather than the usual, essentially binary, choice between granting all privileges via setuid() or granting just those of the user running the program. Combining capabilities with user namespaces will allow administrators to apply those fine-grained privileges to containers, which is just what a patch set proposed by Serge E. Hallyn sets out to do. We have looked at capabilities several times in the past, most recently in the context of adding capability sets to files, though an earlier article provides more details on the rules that govern how capabilities are applied and inherited. With the addition of file capabilities, Linux systems have all the tools needed to eliminate most setuid programs though, in practice, that hasn't happened. There is an effort underway to eliminate most setuid programs for Fedora 15, however. Namespaces are part of the Linux containers implementation, which is a lightweight virtualization technique that allows groups of processes to run in their own little world, separate from the rest of the processes running on the system. These containers must not be able to see or interact with things outside, so various global resources (things like process IDs, network devices, filesystems, and so on) need to be wrapped in a namespace layer that provides the illusion that the container is its own system. User namespaces provide a container with its own set of UIDs, completely separate from those in the parent. Each of the different kinds of namespaces can be created by using flags to the clone() system call. The idea behind Hallyn's patches, the core of which was originally developed by Eric Biederman, is to eventually allow unprivileged users to create namespaces. In order to do that, the capabilities of processes in a namespace must not leak out to parent (or even sibling) namespaces. In the core patch, Hallyn says that the proposed changes accomplish 90% of the goal to allow unprivileged namespace creation, with some UID confusion issues still to be addressed. In the initial user namespace—the "normal" namespace that is created at boot time—capabilities for a task are calculated in the usual way, using the permitted, effective, and inheritable capability sets associated with the task. The proposed changes will restrict any capabilities in a child user namespace to only act within that namespace or on any of its descendants. Each capabilities set is contained in a structure that references the user it corresponds to, and those user structures have a namespace to which they are attached. When checking to determine whether a particular set of capabilities should be used, the code looks at whether the user is part of the target namespace. If so, its capabilities are used, if not, each parent namespace is checked all the way back to the initial user namespace. Since the capabilities can only be associated with one namespace (via a user in that namespace), they are only active in the namespace that contains them or any descendant from that namespace. The user that creates the namespace will have all capabilities in that namespace, not just the set of capabilities they have in the parent. Essentially, the creator has the privileges of the root user in any namespace he or she creates. In order to ensure that the namespace creator's capabilities don't leak out to the rest of the system, a new capability check is added in the patch:
int ns_capable(struct user_namespace *ns, int cap);
The existing capable() function, which determines whether a task has a
particular capability or not, has been changed to call
ns_capable(), but
it passes the initial user namespace for ns. That means that the
existing calls to capable() currently sprinkled around the kernel
do not suddenly change their semantics. In order to allow specific
capabilities to function in a user namespace, calls to capable()
need to be changed to ns_capable() while passing the appropriate
namespace. The cap_capable() function, which is eventually called
from ns_capable(), has been changed to properly handle capabilities
in user namespaces.
In this way, kernel functionality that requires certain capabilities can be incrementally added to user namespaces while still protecting the rest of the kernel from being affected. Hallyn's patches enable three specific capabilities for user namespaces by making the change from capable() to ns_capable(). The first, and simplest, just allows the sethostname() system call to be successfully called if the user in the namespace has CAP_SYSADMIN. The second, which is slightly more complicated, but still a pretty small change, alters check_kill_permission() to allow CAP_KILL enabled tasks to send a signal to another task. The last patch allows CAP_SYS_PTRACE capable tasks to use ptrace() on other tasks in the user namespace. This is an incremental approach that will allow each addition of user namespace capabilities to be reviewed and tested separately before adding them into the mainline. Hallyn notes his current plans for enabling some additional capabilities from user namespaces:
My near-term next goals will be to enable setuid and setgid,
and to provide a way for the filesystem to be usable in child
user namespaces. At the very least I'd like a fresh loopback
or LVM mount and proc mounts to be supported.
Capabilities are something of gnarly corner of the kernel, and one that has caused problems in the past (e.g. the "sendmail capabilities" bug). Combining them with namespaces is a bit of a delicate task. Clearly, if regular users are able to create these namespaces, it is imperative that any tricky interactions caused by capabilities in namespaces do not lead to privilege escalations. From that perspective, Hallyn's approach seems sound.
Brief items Security quotes of the week
If anything, the collaborative model we use should _decrease_ trust,
except, well, unless you compare it to the other model -- corporate
software -- where they don't even start from any position of trust.
There you are trusting the money, here you are trusting people I've
never met.
-- Theo de
Raadt
Karsten Nohl's assessment of dozens of car makes and models found weaknesses in the way immobilisers are integrated with the rest of the car's electronics.
-- NewScientist
The immobiliser unit should be connected securely to the vehicle's electronic engine control unit, using the car's internal data network. But these networks often use weaker encryption than the immobiliser itself, making them easier to crack. What's more, one manufacturer was even found to use the vehicle ID number as the supposedly secret key for this internal network. The VIN, a unique serial number used to identify individual vehicles, is usually printed on the car. "It doesn't get any weaker than that," Nohl says.
That's because IT security in 2020 will be less about protecting you from
traditional bad guys, and more about protecting corporate business models
from you. Deperimeterization assumes everyone is untrusted until proven
otherwise. Consumerization requires networks to assume all user devices are
untrustworthy until proven otherwise. Decentralization and deconcentration
won't work if you're able to hack the devices to run unauthorized software
or access unauthorized data. Deconsumerization won't be viable unless
you're unable to bypass the ads, or whatever the vendor uses to monetize
you. And depersonization requires the autonomous devices to be, well,
autonomous.
-- Bruce
Schneier
Our computers do so much now, they've become a liability. The only people
who know how to take advantage of all their functionality are the people
writing malicious code. Microsoft and every other OS builder have
established decent security, but the weak point is usually the user, who
clicks a page or opens an e-mail that they're not supposed to. Locks are no
good when you leave the front door open.
-- msnbc.com
misses the boat
Also interesting is the discussion of the asymmetric nature of the
threat. A country like the United States, which is heavily dependent on the
Internet and information technology, is much more vulnerable to
cyber-attacks than a less-developed country like North Korea. This means
that a country like North Korea would benefit from a cyberwar exchange:
they'd inflict far more damage than they'd incur. This also means that, in
this hypothetical cyberwar, there would be pressure on the U.S. to move the
war to another theater: air and ground, for example. Definitely worth
thinking about.
-- Bruce
Schneier reviews Cyber War
Jones: System call fuzzing continuedDave Jones has continued his system call fuzzing experiments and has found some more interesting kernel holes. "One of the things the fuzzer does is to pass random file descriptors to syscalls that expect them. At first, it generated a few itself on startup by creating a bunch of files. I changed this to open any files that were readable/writable from sysfs, procfs and /dev. It prints out what it managed to open on startup. I immediately noticed something that stood out like a sore thumb. /sys/kernel/debug/acpi/custom_method was world writable. As this file allows a user to upload new ACPI tables to the kernel, this is a fairly obvious local root. Thankfully debugfs isnt mounted by default on most systems."
Breaking SSL on Embedded Devices (/dev/ttyS0)The /dev/ttyS0 site has a discussion of the implications of the LittleBlackBox project. "Here's where it gets fun: many of these devices use hard-coded SSL keys that are baked into the firmware. That means that if Alice and Bob are both using the same router with the same firmware version, then both of their routers have the same SSL keys. All Eve needs to do in order to decrypt their traffic is to download the firmware from the vendor's Web site and extract the SSL private key from the firmware image." (Thanks to James Andrewartha).
Update on the OpenBSD IPSEC backdoor allegationTheo de Raadt has summarized what is known, so far, about the allegation that OpenBSD's IPSEC stack had a backdoor inserted into it by contractors at the behest of the US FBI. Some code auditing has been done, and found some problems, but no "smoking gun" has been found. However, De Raadt does think that the FBI tried: "(g) I believe that NETSEC was probably contracted to write backdoors as alleged. (h) If those were written, I don't believe they made it into our tree. They might have been deployed as their own product."
New vulnerabilities chromium: multiple vulnerabilities
dhcp: denial of service
eucalyptus: privilege escalation
git: cross-site scripting
kvm: memory leak
mozilla: code execution
tor: remote code execution
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||