LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityFilesystem capabilities in Fedora 10Linux capabilities have been around for a long time, but they are finally starting to get to the point where they can actually be used. There are still no mainstream distributions that make use of them, but Fedora 10 has all of the requisite functionality available, as Ulrich Drepper recently pointed out in a blog posting. There are now systems available for administrators to begin to try out capabilities to see what advantages they offer. Note that this article concerns Linux/POSIX capabilities and not the other security approach of the same name. The canonical test program for capabilities seems to be ping; that is what Drepper used, as did Chris Friedhoff in his capabilities documentation. Currently in Fedora 10, ping is a setuid-root program as it needs privileges that normal users do not have. Removing the setuid bit with
chmod u-s /bin/ping
results in normal users getting the following error:
ping: icmp open socket: Operation not permitted
But, ping can be left without the setuid bit, by proper
application of capabilities.
By using the setcap command, a root user can give the required capabilities to the ping program. These get stored as extended attributes (xattrs) in the filesystem and queried by the kernel when filesystem capabilities are enabled. It should be noted that not all filesystems support xattrs, but for those that do, setcap will add the "capability" attribute with a 20-byte value representing the capability information. The capability required by ping is CAP_NET_RAW, so an administrator who wants to have a non-setuid-root ping must do:
setcap cap_net_raw=ep /bin/ping
This sets the CAP_NET_RAW bit in both the "effective" (e) and
"permitted" (p) capability sets. These two sets, along with the
"inheritable" set, govern the capabilities that a process has or can set.
Serge Hallyn's developerWorks
article is a good reference for how those sets interact.
But, how does one find out what capabilities a particular program needs? In some ways similar to the audit2allow method sometimes used to determine SELinux policies, one can look for permission denied errors as Friedhoff describes:
$ strace ping localhost 2>&1 | grep EPERM
socket(PF_INET, SOCK_RAW, IPPROTO_ICMP) = -1 EPERM (Operation not permitted)
In this case, ping tried to open a raw socket which requires
CAP_NET_RAW. Hallyn's article also has code for a
capable_probe kernel module that can be used to see what
capabilities are
requested. As with the SELinux method, one must be careful that the
capabilities requested are actually reasonable for the program's task
before granting them.
Now that capabilities are available, folks have started to wonder when things like ping will have their setuid bit removed in standard distributions. Panu Matilainen asked on fedora-devel: "Are we ready to start considering moving away from SUID bits to capabilities, in Fedora 11 maybe?" The answer in the resulting thread seems to be "no", mostly because there is concern about folks building their own kernel without support for capabilities. It is a bit of a weak argument because Fedora depends on any number of kernel options. Drepper is characteristically blunt: "That's nonsense since there are many other options we rely on and which can be compiled out." Other distributions may handle things differently, though, so we may see Linux-capability-based systems elsewhere. For now, administrators can turn off setuid and instead set capabilities on programs in Fedora 10, "unfortunately you have to do it every time the program is updated again," Drepper notes. Capabilities were originally added to Linux in the 2.1 kernel series, around ten years ago, so it is nice to see them finally getting to the point of usability for regular users and administrators. It will be interesting to see where things go from here.
Brief items 25C3: MD5 collisions crack CA certificate (heise online)Researchers presenting at the 25th Chaos Communication Congress (25C3) have used MD5 collisions to generate bogus, but trusted, SSL certificates as reported by heise online. This would allow nefarious web sites to generate a certificate purporting to be from any other site—greatly increasing the reach of phishing and other scams. "Using a weakness in the MD5 cryptographic hash function, which allows different messages to generate the same MD5 hash – known as an MD5 'collision', the international team of Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molinar, Dag Arne Osvik and Benne De Weger, have used one attack scenario to create a certificate which will be trusted by all browsers because it appears to be signed by one of the root CAs that browsers trust by default. The certificate can also be used to sign other certificates, which could allow attackers to carry out 'practically undetectable phishing attacks'."
New vulnerabilities OpenSSL: certificate verification flaw
p7zip: unknown vulnerability
php-xajax: cross-site scripting
samba: privilege escalation
xen: DOS and symlink vulnerabilities
xterm: arbitrary code execution
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||