LPC: Three sessions from the security track [LWN.net]

By Jake Edge
October 7, 2009

The Linux Plumbers Conference (LPC) had a full-day security track with talks on multiple topics of interest—far too many to adequately cover. So, just a few of the talks will be looked at here. Some of the other presentations will likely serve as the basis for other articles on this page in the future.

SELinux in Ubuntu

Caleb Case reported on the status of SELinux in Ubuntu. Since Ubuntu already uses AppArmor, one of the obvious questions was: why would Ubuntu add SELinux? Case said that users were asking for it and that having more options for running SELinux (beyond Fedora/RHEL) was desirable. Ubuntu has had SELinux available to install since Hardy Heron (8.04), but it has many more policy modules enabled in Jaunty (9.04) and Karmic (soon to be released 9.10).

The SELinux policy "needs work", Case said, and SELinux in Ubuntu is "not nearly as slick" as it is in Fedora, but it is a work in progress. Users can now do an apt-get install selinux, which will pull in everything that is needed and uninstall AppArmor. The installation updates initramfs, installs the policy, and schedules a system relabel.

Policy is loaded from initramfs instead of via a patched init as has been done in the past. The upstart maintainers did not want to carry a patch to do policy loading, as they didn't want to have to patch for each and every Linux Security Module (LSM) that came along. As it turns out, loading from initramfs is becoming the popular option. Fedora is doing that via dracut and someone from the AppArmor team spoke up to note that it had switched over to loading policy from initramfs as well.

In the future, Case would like to see setroubleshoot added to Ubuntu and integrated with the desktop. They would like to enable more policy modules by default, so setroubleshoot would come in handy. Case said that the Ubuntu policy has fewer confined daemons than Fedora does, and that the reference policy has not been changed anywhere near as much as it has for Fedora. He invited the audience to "check it out, [and] see if it works, or doesn't" and joked that bugs should be submitted to Red Hat's Dan Walsh.

Smack and applications

Smack developer Casey Schaufler presented a look at application changes needed to support Smack on Linux. He started with a brief overview of Smack, including some newer information on packet labeling that can be used by Smack to enforce various controls on network traffic.

Not many changes were required to core applications to support Smack. Things like ls, id, and attr needed to change to show the Smack labels, while login required changes to set the Smack label on the user's login shell. mount needed to support some Smack-specific options for setting default labels on filesystems, and a new utility, newsmack—an administrative tool that is used for setting smack labels on processes and files—was added.

For network applications, sshd needed to be changed to handle the labeling of the login shell. To support network services running at different labels, an xinetd-like utility called smackpolyport was created. It listens at the '*' label and can spawn services running with other labels to enforce network access restrictions. There is also work in progress on adding a Smack extension to the X Access Control Extension (XACE). There is more work to be done to integrate Smack into window managers as well as things like D-Bus, he said.

Schaufler has a habit of tweaking the SELinux development community as part of his talks, and he continued that tradition at LPC. He was discussing his work on making Smack work with the Oracle 11gR1 database server, and one of the criteria he noted was that it did not work with SELinux. In fact, the first step in the installation guide is to turn off SELinux. Some grumbling from the SELinux developers was heard in response to that, with the indication that it was possible—perhaps even unofficially working—but there is no public information on how to run Oracle with SELinux. Schaufler then went through the, fairly simple, steps he took to make Oracle and Smack work together.

Someone asked Schaufler if Smack had been integrated into any distributions. He said that Wind River listed Smack in one of its brochures, and someone from Wind River piped up to say that it was in versions 2.0 and 3.0 of its Linux product. Schaufler also noted that Philips televisions are, or will be soon, running Smack.

Why policy is special

Joshua Brindle looked at the interaction between package managers and SELinux policies, noting that installing policies is very different than application installation. There are policies available for more than 290 applications currently that are typically packaged by distributions, often after some customization is done. For rpm-based distributions, policies get loaded via post-script sections, which can lead to problems that require user intervention if the policy module fails to load.

In addition, third-parties (like Oracle) have a hard time supporting policies for their packages, he said. There are "numerous hacks" to support policy loading. In general, policies just do not fit well into the current application installation model.

Policy is different because it potentially affects the entire system, unlike an application. Policies should be loaded before the applications they affect, or else there is a window in which the application is present, but the labels and policies have not been changed. If the policy fails to load, the application should not be installed, but under the current system, there is no way for rpm to roll the installation back if the post-script section fails.

Policies may also affect multiple applications and their interactions. In many cases, the policy should not be removed if the application is, because there may be user data that is protected by that policy. In addition, other applications may require the policies to be present so they can access the data. So, Brindle said, a new approach is needed. The goal of that work is to include the policy with the distribution package such that policies are installed first, "without hacks", and are part of the installation transaction, so they can be rolled back in the case of failure.

Brindle outlined additional goals of this work, which is initially targeted at rpm: supporting various corner cases like cross-installs and bootstrap installs. Helping third-parties distribute policies for their applications is also an explicit goal, so there needs to be support for multiple policies and policy types (e.g. targeted), as well as support for different distributions and releases. Overall, he summed up the goals as trying to "make life with SELinux easier".

The initial patch to rpm adds policy loading support before the transaction. A second patch changes the %Policy directive to support policy renaming as well as allowing policies to obsolete one another. In addition, the changes to the %Policy directive allow for different policies based on the policy type of the system. Additional patches will support bootstrapping and chroot() installations. Those patches will also add the policies to the rpm database, which will allow the user to change the system policy type while giving rpm the information it needs to install the proper policy.

There is more work to be done, of course. One area that needs to be addressed is how to inform the administrator of policy changes that are being done by a package. Packages from dubious sources could install policies that have the effect of disabling some or all SELinux protections, so administrators need to be informed. There may be support added for differing levels of trust based on where the package file came from, so that administrators can enforce restrictions on what kind of policies packages can install.

Other talks

The most popular attendee was clearly the AVC cow, which made an appearance in Eamon Walsh's demo of XACE. The cow popped up whenever there was an AVC denial from SELinux, which led to calls for more violations so the cow would pop up again. As Dan Walsh (no relation) noted in his blog linked above, it is proof that at least some folks at the NSA (where Eamon Walsh works) have a sense of humor.

Other talks in the track were Dan Walsh's presentation on "sandbox -X", a look at the kernel crypto subsystem by Herbert Xu, David Safford on using the Integrity Management Architecture (IMA), James Carter on a new SELinux policy infrastructure, and a discussion of how to make SELinux easier to use led by Bryan Jacobson. The slides for each of the talks are available on the LPC Program page. There was a fair amount of audience participation, both in terms of questions and suggestions, throughout the sessions; very much in keeping with the mission of LPC. Overall, it was a very useful track for anyone trying to keep up with security in Linux.

Index entries for this article
Conference	Linux Plumbers Conference/2009

SELinux

Posted Oct 8, 2009 9:45 UTC (Thu) by mjthayer (guest, #39183) [Link] (22 responses)

One of my problems with SELinux is that I have still to find a simple, concise, complete and security-buzzword/acronym-less description of what it actually does (that is, what problem it solves - other than just a vague "making Linux secure" - and how). All explanations I find ramble on over many paragraphs with scatterings of FLASKs and suchlike, but somehow I always end up with the feeling that it is a large mess of corner cases without a clear main case to fit.

SELinux

Posted Oct 8, 2009 16:09 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (5 responses)

Here is what I wrote in a FAQ on this topic:

SE(Security Enhanced) Linux is a security feature in the Linux kernel and enabled by default in Fedora that provides more fine grained access control compared to traditional Unix file permissions and user based confinement.

SELinux can confine access of programs within a computer and hence can be conceptually thought of a internal firewall between programs. A centralized policy determines which software can access what resources based on extended attributes/labels associated with files. For example, network services can be confined to a particular port, say Apache web server can be restricted to be able to connect to only 80 by default.

Hope this helps.

SELinux

Posted Oct 8, 2009 21:13 UTC (Thu) by hppnq (guest, #14462) [Link]

The mandatory Google query "site:lwn.net selinux" turns up a number of well-written articles on SELinux.

(Oh, and Apache binds to port 80, clients connect to it. ;-)

SELinux

Posted Oct 9, 2009 9:01 UTC (Fri) by mjthayer (guest, #39183) [Link] (3 responses)

Thanks for your answer! So if I combine that with what I have already had to find out myself over the past couple of years, does it boil down to the following?
* a mechanism for controlling which operations which may be performed on which files and devices and what networking operations may be performed (plus a few which I am not aware of) based on the current rights assigned to the executing process.
* a mechanism for adding or removing rights based on user ID, explicit requests from the user and execution of binaries with the equivalent of special capabilities (again, plus a few which I'm not aware of).
* An in-kernel-memory policy database to manage all this.

SELinux

Posted Oct 9, 2009 9:39 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

Enforcement of restrictions is based on the policy and labels (MAC) rather than users (DAC). So even programs/process run by the same user can have different rights (access to files, ports etc). This allows for more fine grained access control and this is a key differentiator as it allows a central policy to determine access. Other than that, your understanding seems correct.

SELinux

Posted Oct 9, 2009 9:49 UTC (Fri) by mjthayer (guest, #39183) [Link] (1 responses)

I take it that restrictions is a more accurate term here that the "rights" I used above? That is, we are talking about "allowed by default"? And does user ID play no role whatsover? I thought that "role" was important, and that there was a mapping of which UIDs could assume which roles. I was thinking of the "policy and labels" applied to executables when I talked about "binaries with the [SELinux] equivalent of capabilities", did I miss something important?

Thanks again :)

SELinux

Posted Oct 10, 2009 0:22 UTC (Sat) by janfrode (subscriber, #244) [Link]

No, it's "default deny", so the selinux policy adds permissions to do something.

User ID doesn't matter, except that you'll first need to pass the normal owner/group/permissions before selinux is involved (DAC before MAC).

"Roles" I'm not much familiar with..

SELinux

Posted Oct 8, 2009 21:37 UTC (Thu) by jamesmrh (guest, #31622) [Link] (15 responses)

It can do a lot of things, so to focus on what it does if you have it enabled in e.g. Fedora: it mitigates vulnerabilities arising from software flaws. If there's a bug in an application, then SELinux can confine its behavior to limit damage if its exploited.

SELinux

Posted Oct 9, 2009 8:37 UTC (Fri) by mjthayer (guest, #39183) [Link] (14 responses)

jamesmrh wrote:
> It can do a lot of things
That is in fact the particular problem I have with it that I was highlighting above. I am coming to the conclusion that SELinux is not a tool with a single clear-cut purpose (other than, as I said "security"), but rather tries to be a single solution for a number of vaguely related problems. And I am also wondering whether it is the best solution for some of them, not least because many people seem to have trouble understanding it, which is not good for a security mechanism.

SELinux

Posted Oct 10, 2009 15:46 UTC (Sat) by kleptog (subscriber, #1183) [Link] (13 responses)

Compare and contrast with:

I am coming to the conclusion that the UNIX permission model is not a tool with a single clear-cut purpose (other than, as I said "security"), but rather tries to be a single solution for a number of vaguely related problems. And I am also wondering whether it is the best solution for some of them.

The basic idea of UNIX permissions is simple, but gets hairy once you start including setid bits, setgid on directories and the sticky bit. It's used for everything from protecting home directories to providing controlled priveledge escalation to stopping people from deleting other people's temp files and ensuring new files are readable by certain groups. However, it does have the advantage that most people understand it, which is not true for SELinux.

At its lowest level, subjects (programs,users) and objects (files,sockets,etc) have labels and there's a policy that determines what a subject with label X is allowed to do with an object with label Y. What makes it mandatory access control is that the owner of the object doesn't get to say what happens, the policy is decided elsewhere.

I think what makes it hard is that UNIX permissions have a fairly simple policy, while the policy of SELinux is flexible and therefore not obvious to the casual user. And like the UNIX permission model, can probably be expanded to create effects beyond what people initially thought of.

SELinux

Posted Oct 13, 2009 8:25 UTC (Tue) by mjthayer (guest, #39183) [Link] (12 responses)

The basic idea of UNIX permissions is simple, but gets hairy once you start including setid bits, setgid on directories and the sticky bit. It's used for everything from protecting home directories to providing controlled priveledge escalation to stopping people from deleting other people's temp files and ensuring new files are readable by certain groups. However, it does have the advantage that most people understand it, which is not true for SELinux.

I have to agree with you there (on both points). Apart from basic usage of setuid I have similar feelings about those "extra bits" to SELinux :)

What makes it mandatory access control is that the owner of the object doesn't get to say what happens, the policy is decided elsewhere.

As far as I can see though, in practice it is normally used for restricting things done by the superuser account, which PolicyKit does using "standard" Unix mechanisms - I could imagine a variant on PolicyKit which used a setuid helper instead of a daemon waiting over DBus (not criticising DBus, but it is aimed at doing things from a running desktop, and not at a deeper level in the system, like e.g. (re-)starting DBus itself!), and which starts helper applications as other users than root where appropriate (classical example, passwd: make it owned by user passwd, and have a tool with user permissions get the new password and call a PolicyKit-style helper running as user passwd to actually set it. And there you have your configurable policy (PolicyKit's policy), your roles (the user passwd) and your restrictions (only do what user passwd is allowed to do, namely, change the password file).).

Of course, SELinux does do many other things, like competing with PaX by preventing applications from changing their code while running. See my point above :)

SELinux

Posted Oct 20, 2009 9:22 UTC (Tue) by njs (subscriber, #40338) [Link] (11 responses)

PolicyKit is for allowing controlled privilege escalation -- e.g., letting a user muck with /etc/passwd.

SELinux is for locking down stuff further than it would be otherwise -- e.g., making it so your firefox *can't* delete your home directory, even if someone tricks it into loading a bunch of arbitrary code from the web and executing it. All the complicated stuff is just the messy work of explaining to the computer exactly what you mean by "home directory", "firefox", and "can't delete".

This isn't just a heuristic all-else-being-equal kind of distinction; the way the kernel is written PolicyKit *can't* forbid anything that would otherwise be allowed, and SELinux *can't* allow anything that would otherwise be forbidden.

Sure, sometimes the thing you want to lock down is run by root, because it's some system daemon that (due to limitations in the traditional unix model) has to be run as root -- 'sshd', say, or your example, 'passwd'. Neither of these programs needs to do *everything* root can do, though -- a bug in passwd (or PolicyKit!) should not allow me to load kernel modules or reformat the hard drive... So you want something more fine-grained.

SELinux

Posted Oct 20, 2009 12:17 UTC (Tue) by spender (guest, #23067) [Link] (10 responses)

"making it so your firefox *can't* delete your home directory, even if someone tricks it into loading a bunch of arbitrary code from the web and executing it."

This is wrong, wrong, wrong. How many times do we have to educate SELinux users on this?

In case you forgot, here's 8 videos for you to watch:
http://www.youtube.com/spendergrsec

Or take it straight from the horse's mouth:
http://lwn.net/Articles/334955/

In the real world, attackers aren't interested in deleting your home directory. They sure are interested in launching kernel exploits though.

-Brad

SELinux

Posted Oct 20, 2009 19:48 UTC (Tue) by nix (subscriber, #2304) [Link]

They're not interested in deleting your home directory, but they're
certainly interested in scanning it for what looks like online banking
login details. (Unfortunately, SELinux won't work here, and neither will
anything short of a security system inside the browser itself: because
it's likely that the banking login details must be stored somewhere the
browser can access it, because you'll be getting at the online banking
site through the browser. Doing absolutely everything through the browser
smacks very much of too many eggs in one basket for me.)

SELinux

Posted Oct 20, 2009 20:18 UTC (Tue) by njs (subscriber, #40338) [Link] (7 responses)

I'm not an SELinux user.

I am already familiar with ~~all internet traditions~~ everything you're trying to tell me -- patronizing, much?

But fyi, if I didn't already know what you were trying to say, I'd never get it from your post. I said SELinux is intended to lock down programs, and you just respond "wrong, wrong, wrong" and bemoan your sad fate where idiots like me keep saying things that... well, are true, actually, SELinux *is* designed for locking down programs. It is, of course, very important that it does not and can not guarantee effectiveness (despite all those fancy formal models), and also doesn't address the most important modern desktop threat models, but you didn't actually *say* that.

I think it's absolutely a good thing to open people's eyes to a more nuanced view of security, involving actual discussion of threat models, mitigation versus provably secure, reality-based estimates of exposure, all that good stuff. But your posts seem more interested in showing how terribly ill-used you are than in making the world a better place and frankly, dude, I think grsec's goals are awesome and I still don't care about your personal feelings. Esp. when you're so willing to sacrifice nuance and accuracy (SELinux *has* mitigated attacks, for all its imperfections) on the altar of axe-grinding.

SELinux

Posted Oct 20, 2009 23:58 UTC (Tue) by spender (guest, #23067) [Link] (6 responses)

Do you know the definition of the conjunction "can't"?
Do you know the definition of "arbitrary"?

Let's break it down, since you didn't grasp my post apparently:

You said:
"making it so your firefox *can't* delete your home directory, even if someone tricks it into loading a bunch of arbitrary code from the web and executing it."

You said that what I quoted from you was "true" -- in what world?

If what you said was true, then an attacker *can't* (your emphasis) choose a kernel exploit as his/her arbitrary code to execute within the context of firefox (the recent perf_counter vuln is a perfect example of one that would work flawlessly), allowing the attacker to change UID to 0, disable SELinux, drop a shell, and then delete your home directory. Is that what you're saying? That that's impossible? Asterisks around "can't" suggests emphasis, and in this case, certitude. I would suggest wrapping it in quotes, or not using the word at all.

I'm really not understanding this: you say something explicitly that is absolutely wrong, I quote your exact sentence and point it out, then you not only insult my understanding of the subject, but claim that what you said was true. Please explain this to me, because clearly I'm in need of education.

Either you're not familiar at all with what I'm trying to tell you, or you don't know the answer to my initial two questions.

-Brad

SELinux

Posted Oct 20, 2009 23:59 UTC (Tue) by spender (guest, #23067) [Link]

Contraction rather ;)

SELinux

Posted Oct 21, 2009 4:11 UTC (Wed) by njs (subscriber, #40338) [Link] (4 responses)

Well, okay. Now look at the first half of my sentence, and the surrounding context. I said SELinux is *for* locking down stuff further than it would be otherwise (giving the firefox example as a clarification on what this meant), as part of explaining the difference between it and PolicyKit to someone who was confused on this basic point.

We both know perfectly well that what I described is a design goal for SELinux -- and that's true quite independently of whether this is a useful goal, and whether or not SELinux actually accomplishes it.

Now, absolutely, I was a bit lazy -- I could, maybe should, have gone further and pointed out that SELinux was far from a panacea. Arguably people are so commonly confused about what to expect from "security" code that we have a responsibility not to mislead them further, even by omission. And if you'd called me on that, then I'd have agreed and we'd go on our way, having made the world a slightly better place.

Calling me "wrong, wrong, wrong" and assuming that if I didn't bring up this tangential point then I must be completely ignorant -- that's a little different!

Yes, I really have read your posts here before and understand what you're saying. What I'm trying to say is that 1) I basically *agree* with all the factual/technical content you're trying to get out there; if anything, I'm on your side, but 2) you argue in such grating ways, mixing some excellent points with so much dishonest rhetoric, irrelevant grudges, and derailing of other discussions onto your hobbyhorses, that I'd rather not engage with you myself, and have perfect sympathy for kernel developers who ignore you.

The end result looks almost like a loop where you rant and rave about how no-one listens to you, everyone else goes "uh, maybe he has some points but I'm not sticking around to find out", and then this proves that no-one listens to you and confirms your misunderstood genius cred. If that works for you, great, but leave me out of it. We've all been misunderstood -- heck, Linus slanders some of my work on a pretty regular basis -- but if our goal is to actually accomplish stuff then we just ignore it and do our best make progress anyway with the hand we're dealt. (The irony is that doing this is what *actually* convinces bystanders that we're awesome, in a way that explaining how those idiots don't appreciate our work does not.)

SELinux

Posted Oct 21, 2009 6:04 UTC (Wed) by dlang (guest, #313) [Link] (2 responses)

I am not frequently in agreement with spender, but SELinux has been advertised as being able to block things like deleting home directories (in fact IIRC, when I first heard of it, it was with "here is the root password to a system that's reachable on the Internet, because it's running SELinux you can't hurt it."

SELinux

Posted Oct 22, 2009 0:05 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

What happened to that machine? Is it still root-exposed to the net? :)

SELinux

Posted Oct 22, 2009 1:44 UTC (Thu) by njs (subscriber, #40338) [Link]

It's here (and has been since 2002):
http://www.coker.com.au/selinux/play.html

And was online as recently as February:
http://etbe.coker.com.au/2009/02/17/lenny-play-machine-on...

Though I'm getting "no route to host" right now -- perhaps because it is getting warm again in Australia :-) (see last link)

SELinux

Posted Oct 21, 2009 13:21 UTC (Wed) by spender (guest, #23067) [Link]

What I did was quoted a sentence of what you wrote, which no amount of context could have made true. You were very explicit in what you wrote, and that is what my comment of "wrong, wrong, wrong" was explicitly directed toward. If you had left that part out, I would have had no real objection to your post.

SELinux in general improves security by reducing attack surface.
SELinux (with proper policy) prevents applications from shooting themselves in the foot.
SELinux can increase required exploit complexity.
All of these statements I have no problem with.

It's the:
Here's the root password to my SELinux-protected machine, you can't compromise it.
SELinux can guarantee firefox can't delete your home directory, even in the presence of a skilled attacker.
First two panels of the following: http://grsecurity.net/~spender/mac_security_sesamestreet.jpg (from http://magazine.redhat.com/2007/05/04/whats-new-in-selinu...)

that I take issue with, and will continue to point out when I see it. I wrote a section of our Wiki (http://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System#L...) that puts the information up front (it's the first thing after describing what the RBAC system is) that we plan to update soon with more of a historical lesson of the environment from which access control systems and models originated, how the problem being solved at the time was curbing the problem of careless (specifically, not malicious -- they were considered trusted) administrators.

It was about people control, not program control. Modern day threats like determined/skilled/funded attackers or even modern networking weren't even part of the picture. Any time networking was discussed, it involved private, trusted networks where all machines involved were protected under the same security model. Clearly the Internet is not such a network.

So what you see from people who drink the kool-aid of these old security models and concepts is erroneous extrapolation to a modern environment that these things they hold in such high regard weren't even designed for. It's this kind of misguided illusion that I've been trying to inject doses of reality in for some years now.

As for actually accomplishing stuff, we spend a lot more time doing it than we do talking about it (for instance, I only recently wrote a list of what we developed over the past couple months: http://grsecurity.net/news.php#develup) but that doesn't have anything to do with the original discussion.

-Brad

Types of attack

Posted Oct 22, 2009 8:49 UTC (Thu) by Cato (guest, #7643) [Link]

Ransomware exists on Windows that encrypts a user's data files, then asks for a payment for the key to decrypt this data - see http://en.wikipedia.org/wiki/Ransomware_%28malware%29 - it's been around for 20 years now, and a more recent example from July is here: http://www.sans.org/newsletters/newsbites/newsbites.php?v...

These show that home directories are of interest to malware writers, quite apart from scanning for passwords, financial information, etc. There is no reason why these attacks could not hit Linux, particularly through cross-platform browser/Flash exploits.

Blanket statements on the intentions of attackers aren't very useful - there are many sorts of attackers out there.

LPC: Three sessions from the security track

Posted Oct 8, 2009 13:10 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

OK, that's it: AppArmor is dead to me until it gets a cow as well. Every security system needs a cow! ;P

AppArmor needs a cow too!

Posted Oct 18, 2009 23:44 UTC (Sun) by vonbrand (guest, #4458) [Link]

Dancing pigs are required!

LPC: Three sessions from the security track

Posted Oct 8, 2009 14:59 UTC (Thu) by keybuk (guest, #18473) [Link]

The comment about the Upstart maintainers (ie. me) in the SELinux section is utterly inaccurate.

I've said I'd welcome discussion with the SELinux upstream folks about the best way to load policies, but nobody from the SELinux upstream community has ever opened a discussion.

Oracle, SELinux and RHEL

Posted Oct 9, 2009 0:52 UTC (Fri) by jamesmrh (guest, #31622) [Link]

Well, I actually checked this... :-)

Oracle 11gR2 _is_ certified and supported for RHEL5 with SELinux, and certification will also be undertaken for RHEL6.

So, if you're a RHEL and/or Oracle customer, I can probably point you in the direction of the right people to talk to for more information.