Security
OLS: SELinux from academia to your desktop
One of the nice things about conferences is the ability to catch up on where a particular project is headed, generally from one of the lead developers. Ottawa Linux Symposium did not disappoint in this area, with several "State of ..." talks. On day two of the four-day conference, James Morris looked at SELinux from its academic roots to its plans for the future.
SELinux got its start from university research in the 80s and 90s that recognized that Discretionary Access Control (DAC) did not protect very well against the kinds of attacks that were becoming prevalent. This spawned the idea of Mandatory Access Control (MAC), in which the system makes all of the policy decisions regarding access, so users cannot change the permissions on files or other objects at their discretion. SELinux is a MAC system.
Originally developed by US National Security Agency (NSA) in the 90s, SELinux was released under the GPL in December 2000. At the Kernel Summit in 2001, SELinux was proposed for inclusion in the 2.5 development-series kernels (remember those?), but was rejected by Linus Torvalds because there was no consensus amongst the various competing security models. This is what led to the creation of the Linux Security Model (LSM) interface.
It was the LSM interface that got Morris involved in SELinux. It took
until the 2.6 release in December 2003 before SELinux was available in the
mainline, which is about three years after its release. This is "not
atypical for a significant change to the kernel,
" Morris said.
The next phase was to get it enabled and working in distributions. Because
he works for Red Hat, Fedora (Core in those days) was an obvious choice.
FC2 was the first release with SELinux, but it was disabled by default
because the policy was too strict. "Every time we switched it on, we
would find bugs in the applications
". Security bugs that is.
So, Fedora came up with the idea of a "targeted" policy that only affected
network-facing services. This was released as part of FC3—which
formed the basis for Red Hat Enterprise Linux (RHEL) 4. It was an attempt
to get
SELinux "switched
on and doing something useful
". It worked well enough that it
inspired confidence in the technology by proving it was viable. SELinux
developers realized that "if we run into problems, we can fix
them
".
Since 2005, SELinux has emerged from a research orientation to a tool that
is usable—with a very active development community. "Even
being part of the project, it's
hard to follow all that goes on
" in the SELinux community. Morris
then outlined some of the more significant developments over the last few
years.
The development of the reference policy by Tresys was a tremendous addition
to SELinux. It was a "step forward in policy thinking
"
because it provides a framework around which to design policy. By getting
rid of the original "spaghetti code" policy, it "made policy much
more understandable to policy developers
".
Loadable policy modules broke up the monolithic policy that was originally
part of SELinux into separate pieces. Each can then be loaded individually
based on "policy booleans". The two of these together allow policy to be
built and administered in sensible chunks, as well as allowing sites to
"customize policy to support local conditions
". Because of
library and toolchain improvements, you no longer have to dig through files
to edit, compile, and load policy either. Many of the reputation problems that
SELinux has stem from the early days when it was well nigh impossible to
track down policy problems and fix them.
It is this frustrating user experience that SELinux is trying to tackle
these days. The targeted policy is being merged with the "strict" policy
and hundreds of modules covering different applications have been added.
Policy failure—where the policy is written incorrectly causing a user to
be unable to do something they should be able to—is "something
you don't want the user to know about
", but unfortunately that is
unworkable. Because the system is under development, bugs will occur;
there is nothing more frustrating for a user than to be denied access but
to be unable to figure out why.
That is where setroubleshoot can help. Inspired by GNOME's bug
buddy, it alerts the user to policy violations and tries help find the
cause of the problem—to the point of suggesting possible fixes. It
is somewhat dangerous, in that users may blindly follow the fixes without
understanding what they are doing, but it helps psychologically.
"Instead of a black box stopping your system from doing what you
wanted, now you have a transparent box.
"
System administrators have a much nicer set of tools to manage policies as
well as filesystem labels. audit2why can analyze SELinux output to
provide reasons, once again with possible fixes, for policy violations. It
is "not the optimum way to develop policy
", but it can help.
In addition, semanage is the "go to tool" for managing SELinux
that is becoming
quite powerful.
Policy development has several GUI tools that have become available. SLIDE is an Eclipse plugin that assists in policy development. It also includes support for testing and deploying policies. Hitachi has developed SEEdit, which is a tool that provides a simplified policy language specifically targeted at embedded devices. It is a higher-level language that removes much of the complexity from SELinux policy while still compiling into compatible policy files.
Performance and scalability have been two areas that have seen much work over the past few years. Many performance and memory reduction patches have come from Japan from the work on embedded SELinux. On the performance critical path, RCU has been used to eliminate some locking, while caching values rather than recalculating them has also provided better performance.
One of the areas that the SELinux hackers are most excited about is threat
mitigation. "We have seen evidence that SELinux has provided
protection for normal desktop users.
" Tresys tracks these kinds
of threats in their SELinux Mitigation News. In the final analysis,
this is what SELinux is meant to do, so it is gratifying to see concrete
results.
SELinux has been adopted widely in Fedora and RHEL, but plans for the future include making it available on other distributions. Ubuntu is shipping SELinux in addition to AppArmor, while Debian and Gentoo are targeted for better SELinux support. SELinux techniques are being pushed beyond the kernel, into virtualization (XSM), the desktop (XACE), storage (Labeled NFS), and applications like databases (SEPostgreSQL). There is also a push into other operating systems, like the OpenSolaris Flexible MAC project.
The challenges facing SELinux in the future are in areas like usability,
which is a "fundamental problem in security
", and
documentation, which is "not very good, in some ways really
bad
". Morris also wants to keep the community of users and
developers growing.
While SELinux has had a difficult path—first in getting into the kernel at all, then to becoming usable, and finally to actually preventing the kinds of attacks it was designed to stop—the developers seem to overcome each hurdle. It is a complex beast, that in some ways defies analysis, but it can help to protect systems. Like it or hate it, it seems likely to be with us for a long time.
Brief items
Schneier on free software and liability
Bruce Schneier has often argued that software problems (security-related and otherwise) will not go away until software vendors are made to take on liability for failures. Now he writes that such a regime would not affect free software. "The key to understanding this is that this sort of contractual liability is part of a contract, and with free software -- or free anything -- there's no contract. Free software wouldn't fall under a liability regime because the writer and the user have no business relationship; they are not seller and buyer. I would hope the courts would realize this without any prompting, but we could always pass a Good Samaritan-like law that would protect people who distribute free software."
Schneier on the DNS vulnerability
Bruce Schneier seems to have lots to say today about things of interest to the free software community. Here is an essay he wrote about the DNS vulnerability—for which the details have leaked—that originally appeared in Wired. We also covered the secrecy issue surrounding the flaw in early July. "Of course, the details leaked. How isn't important; it could have leaked a zillion different ways. Too many people knew about it for it to remain secret. Others who knew the general idea were too smart not to speculate on the details. I'm kind of amazed the details remained secret for this long; undoubtedly it had leaked into the underground community before the public leak two days ago."
New vulnerabilities
asterisk: multiple vulnerabilities
| Package(s): | asterisk | CVE #(s): | CVE-2008-3263 CVE-2008-3264 | ||||||||||||
| Created: | July 24, 2008 | Updated: | May 4, 2009 | ||||||||||||
| Description: | The Asterisk telephony system has two vulnerabilities involving IAX 'POKE' resource exhaustion and Traffic amplification in the IAX2 firmware provisioning system. | ||||||||||||||
| Alerts: |
| ||||||||||||||
coreutils: restriction bypass
| Package(s): | coreutils | CVE #(s): | CVE-2008-1946 | ||||
| Created: | July 30, 2008 | Updated: | July 30, 2008 | ||||
| Description: | The coreutils package fails to use PAM properly, allowing a local user (who knows the relevant password) to change to a locked or expired account with the su command. | ||||||
| Alerts: |
| ||||||
ffmpeg: stack-based buffer overflow
| Package(s): | ffmpeg | CVE #(s): | CVE-2008-3162 | ||||||||||||||||||||
| Created: | July 29, 2008 | Updated: | April 29, 2009 | ||||||||||||||||||||
| Description: | From the CVE entry: Stack-based buffer overflow in the str_read_packet function in libavformat/psxstr.c in FFmpeg before r13993 allows remote attackers to cause a denial of service (application crash) or execute arbitrary code via a crafted STR file that interleaves audio and video sectors. | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
links: unspecified vulnerability
| Package(s): | links | CVE #(s): | CVE-2008-3329 | ||||
| Created: | July 29, 2008 | Updated: | July 30, 2008 | ||||
| Description: | From the CVE entry: Unspecified vulnerability in Links before 2.1, when "only proxies" is enabled, has unknown impact and attack vectors related to providing "URLs to external programs." | ||||||
| Alerts: |
| ||||||
vim: multiple vulnerabilities
| Package(s): | vim | CVE #(s): | |||||
| Created: | July 29, 2008 | Updated: | July 30, 2008 | ||||
| Description: | A collection of vulnerabilities has been fully patched in vim 7.1. See this advisory for more information. | ||||||
| Alerts: |
| ||||||
Page editor: Jake Edge
Next page:
Kernel development>>