Yama: not so fast

By Jonathan Corbet
August 3, 2010

James Morris's 2.6.36 security subsystem preview included, among other things, the Yama security module, which contains a number of security-related changes from Canonical. James later updated his posting, saying:

I'm going to revert the Yama stuff for 2.6.36 -- Christoph has nacked it to me off-list.

An off-list shootdown was always going to raise eyebrows, but Christoph (Hellwig) was quick to make his concerns public. He said:

As mentioned a few times during the past discussion moving broken code into a LSM doesn't magically fix it. In fact YAMA is not any kind of (semi-)coherent security policy like Selinux, smack or similar but just a random set of hacks that you didn't get past the subsystem maintainers.

Christoph, it seems, would rather that these changes went directly into the subsystems affected, rather than being swept into a separate security module. The problem, of course, is that's just how Yama author Kees Cook had started; he was told in no uncertain terms that putting his security-related changes directly into the VFS and ptrace() code was unwelcome. The advice at that time was that his changes should be put into a security module where the rest of the world could ignore them. Even Christoph suggested that approach back in June.

The "not a coherent security model" objection was heard from some other directions as well. According to Valdis Kletnieks:

In other words - if you want to be an LSM, you need to be full-featured enough to cover all the bases, not just a few cherry-picked ones.

Some developers, it seems, would rather not see a set of security-related tweaks gathered together into a module without an overall policy behind it. There have also been the usual claims that everything done by Yama can also be accomplished in SELinux, though Kees seems to disagree.

This rejection leaves Kees in the difficult position of trying to upstream his changes (something his employer has been criticized for not doing) but having no apparent way to actually get them merged. But it may be that all that's really required is a bit of patience. New security modules always seem to bring opposition out of the woodwork, but, with some persistence, they tend to get merged in the end.

to post comments

Yama: not so fast

Posted Aug 5, 2010 5:21 UTC (Thu) by thedevil (guest, #32913) [Link] (3 responses)

Here you can see what I believe turns off more potential kernel contributors than the very occasional sexism or other tribal insensitivity.

What would you do in your day job, if after completing your task using approach A1, your boss told you that wouldn't do, use approach A2 instead; then, after some time passed, you completed approach A2, and the same boss suggested approach A1? I know what I would do: start sending out resumes that evening.

Dignity matters. Even to some hackers.

Yama: not so fast

Posted Aug 5, 2010 8:51 UTC (Thu) by sgros (guest, #36440) [Link]

Yes, inconsistency hurts. But, on the other hand, it is hard to say which approach is better without trying every one, and we all make mistakes. I.e., A1->A2->A1 makes sense because A2 failed, but A1->A2->A1->A2 doesn't make sense at all.

Of course, it easier to do that with someone's else time, but in the same time it is better for everyone else and, in this case, for kernel.

Now, before someone starts flame war, my comment only presents one view and it's certainly not a general view applicable to all situations.

Yama: not so fast

Posted Aug 5, 2010 9:27 UTC (Thu) by epa (subscriber, #39769) [Link]

Right. But what is the alternative? If your boss really did change his mind after you completed A2, then he has two choices: tell you to go back and do it again, or else decide that keeping you happy is more important than his own preferences, and accept it anyway.

Do you really expect a typical LWN hacker to accept what he considers a technically wrong solution because of 'social' reasons, to keep a contributor happy? Perhaps they should; perhaps it would be better for the kernel in the long run; but there's no way it will happen.

Yama: not so fast

Posted Aug 5, 2010 12:59 UTC (Thu) by NAR (subscriber, #1313) [Link]

This is not exactly what happened, if you read the original e-mails: "push it into a special LSM or rather a non-standard rule for it". I don't pretend I have a clue about the technical issues, but I don't see in this mail that it was explicitly told that "if you put it into an LSM, we'll merge it".

On the other hand the line "If you think the objection is about having things in fs/ you're smoking some really bad stuff." is really something that could leave bad taste in developers' mouth. Probably this is why it's meaning was missed/ignored.

Yama: not so fast

Posted Aug 5, 2010 12:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (14 responses)

This is ridiculous.

The LSM folks need to stop inventing excuses and create a stackable LSM.

Yama: not so fast

Posted Aug 5, 2010 15:34 UTC (Thu) by dpquigl (guest, #52852) [Link] (13 responses)

I believe you'll find very few LSM authors that want to be running with another LSM. The only one that I've seen talk about it was the TOMOYO guy. You'll also get most if not all LSM authors to state that loading and unloading security modules at runtime is a bad idea and can't be done safely. That said its not the LSM folks responsibility to create things that they don't want which would probably include features that they don't see as safe. You are more than welcome to code up a stackable LSM solution and try to solve all of the corner cases for it. Once you do and post it to the LSM list we can have a meaningful discussion as to whether it is a viable implementation. Until then don't expect it to happen as it seems most if not all of the LSM authors have their hands full and some don't agree that its even a good idea. If you look at the grsecurity's take on LSM they think it is an absolutely horrible idea which is rife for exploitation by malicious code (I agree with this as well). Someone gave an example of them being able to use a stackable LSM framework but I'm sure brad isn't going to use it even if its there. I'm pretty sure if you look at the grsecurity patches it removes LSM.

As a side note I'm pretty sure stackable LSMs are going to be an administrative nightmare. People have a hard time as it is telling where the errors are when an LSM is involved and you want to add several ones that can potentially fail out at some point in the chain. Plus once you start having to allocate data structures you need to worry about unwinding the stack of allocations on failure. What happens if your free conditions can fail? What happens when you get past two LSMs which allow something to be freed but the 3rd doesn't?

So once again I invite you to take part in creating the framework you're looking for.

Yama: not so fast

Posted Aug 5, 2010 16:10 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

Yes, loadable LSMs are not secure theoretically. And probably most LSM folks think that other's LSM modules should be excluded from the kernel because their own LSM is The Only Good LSM.

And their obsession with safety is laughable, frankly. Because it leads to the use of zero LSMs instead of 2. Sure, NSA might be smart enough to know how SELinux policies work. I certainly am not and so I want to combine several LSMs that I can actually understand. But I'd like to be able to run Yama and AppArmor, for example.

I don't quite understand the problem with your unwinding example. Certainly, if you're doing unwinding you should not be doing additional access checks. Think about PAM, for an example of stackable security modules. It works just fine.

As for doing this job myself - I don't have time to do it. But I'm really starting to think about sponsoring it.

Yama: not so fast

Posted Aug 5, 2010 18:37 UTC (Thu) by dpquigl (guest, #52852) [Link] (3 responses)

I think you'd find that most LSM folks don't believe the competitor should be removed. You can find evidence of Casey saying that there are reasons to use SELinux but he wanted a more light weight module. I've never seen the TOMOYO guys say that SELinux shouldn't be there or even better that AppArmor should never be included (as they are both pathname based). Because there is the desire for distributions to ship multiple LSMs we included the ability to choose at kernel boot time which one you would like to use. Ubuntu uses this functionality to ship an AppArmor and SELinux enabled kernel. To move from one to the other it consists of installing the correct packages and either setting apparmor=1 or selinux=1 on your kernel entry in grub. The Tomoyo guys have said it would be nice to run Tomoyo and SELinux at the same time but I can't really see a good use case for doing that.

The problem with unwinding the allocation and deallocation stacks is mostly with deallocation. It means that you need to ensure that the entire stack can dealloc something before you start going down the stack otherwise you may have two layers removing their security information from an inode for example before it hits a layer that fails. Now you need to repopulate everything at that point above the stack. I'm not saying its not doable but that's just one tricky case out of many you'll run across.

Also another example would be what do we do with labeled protocols now like Labeled-IPSec and Labeled-NFSv4? What do I send across the wire when I support both smack and selinux labels? What if tomoyo wants to send the label on their process as well? Do we make the hook to get all relevant security information return this massive blob of data for a number of LSMs that might not be needed?

There are a lot of things that need to be thought about rather than just saying hey this should exist. I've payed attention to the stackable LSM conversations and no one has actually proposed a solution to this yet. Everyone just seems to say it needs to be done and walks away.

Yama: not so fast

Posted Aug 5, 2010 18:53 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

"I think you'd find that most LSM folks don't believe the competitor should be removed."

Ahh, sweet memories: http://lwn.net/Articles/138042/

"The Tomoyo guys have said it would be nice to run Tomoyo and SELinux at the same time but I can't really see a good use case for doing that."

Look at Yama - it has some nice security features, I'd like to use them on my systems. However, I'd also like to use AppArmor.

Also, some time ago we used a small patch for Linux security subsystem to grant/revoke some privileges for some logged on users. If I rewrite this patch as a LSM, then I'd lose all abilities to use other LSMs!

I still don't understand why you need to do something LSM-related during deallocation of something. You're not performing a security-related action when you deallocate something on unwinding, so no need to use any LSM actions here.

Label interoperability is really a non-issue. If you're using ipsec-labels then most likely you are the NSA or the CIA. Because you need to have the same labels used EVERYWHERE on your network. So no AppArmor on one host, SMACK on another host and SELinux on the server. Or you need to have some sort of label translation layer, which can be integrated with stacked LSMs.

Yama: not so fast

Posted Aug 5, 2010 19:20 UTC (Thu) by dpquigl (guest, #52852) [Link] (1 responses)

"Ahh, sweet memories: http://lwn.net/Articles/138042/"

I didn't realize one person consisted of "Most". You'll see I also referenced that exact email in a response to brad later. I said in that response that the kernel removes dead code all of the time. You had an entire framework for one in kernel user. The kernel doesn't cater to out of tree modules so LSM should be no different. This is no longer the case as we have multiple LSMs in tree now and honestly James's attempt to remove LSM is what accelerated Smack getting into the kernel. I believe Linus took Smack directly without going through the security subsystem maintainer.

"I still don't understand why you need to do something LSM-related during deallocation of something. You're not performing a security-related action when you deallocate something on unwinding, so no need to use any LSM actions here."

Ok I'll try to make this clearer with an example. We have three modules we will call them A B and C. A and B free their security information on a resource. C makes a check on whether or not it can free the resources. It returns that it cant for some reason. You now have a resource that has only 1 of the 3 security modules worth of information associated with it. How does module A and B handle this? Do you just leave the resource unprotected under A and B and just remove it when C is finally able to free its security information?

Yama: not so fast

Posted Aug 5, 2010 19:29 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

I also remember opposition to path-based frameworks quite distinctly.

"Ok I'll try to make this clearer with an example. We have three modules we will call them A B and C. A and B free their security information on a resource. C makes a check on whether or not it can free the resources. It returns that it cant for some reason. You now have a resource that has only 1 of the 3 security modules worth of information associated with it."

Use 'two-phase commit'. First, ask each module if it vetoes the decision to delete the resource. If everything is OK, then call the actual 'free_resource' functions.

Yama: not so fast

Posted Aug 5, 2010 16:18 UTC (Thu) by spender (guest, #23067) [Link] (7 responses)

We don't remove LSM in grsecurity. Users are free to use any LSM they want. It's clear there's some sort of a need for either stackable LSMs or some sort of a way to get *optional* security features merged without having to fight with anti-security kernel developers for months. There's already a number of security features whose options are spread out all over the kernel, things that aren't a complete coherent model but rather serve a particular security purpose: config_debug_rodata, stack protector, builtin_object_size checks in copy_from_user, mmap_min_addr, etc.

As for building the LSM people want, I would urge others to research the history of LSM, the commercial interests of the time, how those interests became public, how Linus nearly removed LSM, why it was later almost removed again to force people into using SELinux, etc. You're likely not aware there was a competing framework that got tossed in favor of LSM due to some nasty behind-the-scenes politics. I'll try to dig up some emails I have on the topic.

-Brad

Yama: not so fast

Posted Aug 5, 2010 18:05 UTC (Thu) by SEJeff (guest, #51588) [Link] (2 responses)

Please do, it would be interesting to read.

Yama: not so fast

Posted Aug 6, 2010 17:07 UTC (Fri) by spender (guest, #23067) [Link] (1 responses)

Ok, I found the two mails in question from Jan 2005. As much as I would like to see this information public, there's simply too much personal/identifying information (much more than I remembered before making my previous post) about the sender to allow me to paste verbatim or even paraphrase specific events.

I don't think my record shows me to be a person to make something up (see: vendor-sec), but if anyone feels that way, feel free to ignore what I mentioned.

At least it wasn't a total waste of time to find the mails; there's a name in them that I now recognize that I didn't back in 2005 that gives me some interesting context.

-Brad

Yama: not so fast

Posted Aug 8, 2010 20:55 UTC (Sun) by nix (subscriber, #2304) [Link]

I don't think my record shows me to be a person to make something up (see: vendor-sec)

I don't think you make things up either, but, uh, vendor-sec is closed so it's hard for most of us to 'see' it :)

Yama: not so fast

Posted Aug 5, 2010 18:50 UTC (Thu) by dpquigl (guest, #52852) [Link] (3 responses)

I stand corrected. I remember reading references to comments you had early in the LSM development process about how it was a horrible idea. The commercial interests I think you are referring to at the time was that early on when SELinux was being put forth for inclusion into the Linux kernel Crispin and the AppArmor crowd were trying to push for inclusion as well. At one of the kernel summits there was some sort of argument between the apparmor and selinux guys where Linus threw his hands up and basically said that he didn't want to have to make a decision about this. That security modules are like file systems and that everyone has different needs. So he ordered the working on LSM. From what I've heard this is exactly what the AppArmor people wanted because their original goal was to sell AppArmor as a proprietary security module.

I find it hard to believe that Linus would have threatened to remove LSM because it gave him a way to punt on making a decision on a single security model for Linux. However the second instance you're talking about was before any other security modules were merged. In James's email below you can see his justification for it [1]. This happens all over the Linux kernel. Dead code is removed. Obviously this reason doesn't fly anymore since we have Smack, Tomoyo, and soon AppArmor in the kernel as well (Plus I'm using LSM for the label interface for Labeled NFSv4). At the time however it was a reasonable request until we had another user accepted. This also got things moving to get smack merged into the kernel and eventually tomyo as well. However I'd like to quote one part of that email which is what we are seeing here.

"Another isssue is that LSM is IMHO being increasingly mis-used as a way to
try and get rather arbitrary security code into the kernel, without due
justification, just because it has a few hooks in the right place, or
because S stands for security, or something.

This is an unfortunate side-effect of developing an infrastructure with
such weak semantics, and the initial grumblings from the core kernel
developers on this issue appear to have been on the money."

[1]http://lwn.net/Articles/138046/

Yama: not so fast

Posted Aug 5, 2010 19:31 UTC (Thu) by spender (guest, #23067) [Link] (1 responses)

I didn't/don't suggest that it was Linus' idea to force people to use SELinux. Rather, I think if you review the posts at the time, the general feeling was "SELinux can do anything, and it does it right: if you're trying to implement any kind of access control, do it within SELinux because nothing else is good enough." and so for many years, until SMACK was merged, SELinux was the only real LSM user. Upon noticing this problem self-created by the kernel developers, the idea was then floated to just remove LSM because only SELinux used it, and if your access control system couldn't be implemented within SELinux it wasn't worth anyone's time, and so wouldn't be added to LSM (the self-perpetuating cycle).

Unsurprisingly, this kind of security lock-in happened to coincide with several interests.

Regarding "arbitrary security" -- I listed some things previously that don't compose a complete security model, and yet they each serve a specific and useful purpose. I think (and I'll explain in more detail on Monday) that the entire framing of discussions around "formal security models" is bogus. Far too much time is being spent on access control, when the kernel itself is like swiss cheese, security-wise. So while everyone complains about pathname-based security and AppArmor while tossing more eggs into the SELinux basket, attackers are simply cutting the bottom out of the basket.

At some point, in general, attention needs to be diverted away from access control; security != access control. Unless your name is Arjan or Ingo and you're copying features of ours, it's impossible to get anything security-related that isn't access control added to the kernel, and in fact it doesn't even seem as if anyone's interested in adding such things (or they've been dissuaded in some way). The thread in the article is a good example of why we'll always stay out of tree. If we had to fight with the kernel developers over features that they later 'reinvented', we'd have never gotten anything done and would have quit years ago.

If your "formal security model" can be remotely disabled by a public off-by-one exploit in SCTP, who's really the one with their head in the sand?

-Brad

Yama: not so fast

Posted Aug 6, 2010 11:48 UTC (Fri) by nix (subscriber, #2304) [Link]

How many foreign (non-SELinux-like) access control systems were ever implemented-in-terms-of SELinux? (presumably by adding some sort of static translator from foreign access control rules into SELinux configuration)?

Have there ever been any? At all? I'm not aware of any...

Yama: not so fast

Posted Aug 6, 2010 18:55 UTC (Fri) by spender (guest, #23067) [Link]

I was just doing some thread searching of my own and ran across this little gem:
http://lkml.org/lkml/2006/4/21/124
> Difficult to evaluate, when the answer whenever a flaw is pointed out is
> "that's not in our threat model." Easy enough to have a protection
> model match the threat model when the threat model is highly limited
> (and never really documented anywhere, particularly in a way that might
> warn its users of its limitations).

> --
> Stephen Smalley
> National Security Agency

I hope the irony of this comment on highly limited threat models (re: LSPP, assumed competent admin, assumed all connecting machines use the same security system, assumed flawless kernel, etc) is not lost only on me ;)

-Brad

Yama: not so fast

Posted Aug 5, 2010 15:46 UTC (Thu) by spender (guest, #23067) [Link] (7 responses)

I've got a better solution: if you want features of grsecurity (which is a coherent security system), just use grsecurity. I'm constantly amazed by the security views of the kernel developers. Maybe if Kees worked for IBM and added TPM support to his code, it could have gotten in like the absolutely worthless snake-oil that is IMA. I'l have more to say about this at the Linux Security Summit on Monday, where I'll be presenting.

-Brad

Yama: not so fast

Posted Aug 5, 2010 20:09 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

To be fair, grsecurity also tries to do 'too much'.

For example, Linux containers with PID and network namespaces are a superior alternative to gresecurity 'anti-chroot-jailbreak' features and simple restriction of netstat to root user.

Though I agree, the kernel needs one coherent set of hook points that can be used to implement different kinds of security (MAC, RBAC).

Yama: not so fast

Posted Aug 5, 2010 21:45 UTC (Thu) by spender (guest, #23067) [Link] (5 responses)

Grsecurity coexists fine with containers. Yes, containers are a better choice than chroot (though not the best choice). The benefit of containers however is only realized if they're actually used. Grsecurity's chroot restrictions are still useful as it passively adds protection to applications that for portability or other reasons are using chroots as a security mechanism. Most grsecurity features are written to work in a similar passive way. The idealist would say "convert everything from using chroot to using containers" but this hasn't happened. In fact, based on a recent study of pie/ssp/fortify_source usage among distros, it's clear that the mechanisms we've had for years aren't being fully utilized in any distro. It's poor security strategy to protect based on how you wish things were in the optimal case on your end, rather than based on what the situation is in reality.

-Brad

Yama: not so fast

Posted Aug 5, 2010 22:09 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

I'm of opinion that too much security == no security.

My systems run a fair amount of legacy code, but I was able to migrate all of it to LXC. It's even feasible to isolate it even further using Xen/KVM now, because hardware is so damn cheap. So adding protections to 'chroot' just isn't worth it, IMO. Actually, it should be possible to reimplement chroot on top of containers.

Some features of grsecurity would better be generalized. For example, IP address tracking should be generalized to other types of metadata (what if I use IP-less protocols?).

Personally, I'd like to see some of features of grsecurity in the mainline kernel. Though I don't really care about a lot of other features...

Yama: not so fast

Posted Aug 6, 2010 11:56 UTC (Fri) by nix (subscriber, #2304) [Link] (3 responses)

Is it time for me to note that glibc bug 7065, providing a patch adding -fstack-protector support to all of glibc (bar small parts of the dynamic loader), was rejected out of hand with no reason given (which made it impossible for me to respond to whatever Ulrich's concerns were: I suspect the real concern was "I didn't think of it", as there have been several occasions now when he has rejected code from others only to reimplement the feature himself and insert it into glibc without crediting the original author), and how bug 7066, which used that support to find a place in *glibc's own test suite* where strtold() was induced into an apparent stack overrun, has now gone one and a half years without any attention?

So even when we provide patches to allow existing mechanisms to be used in pervasive things like glibc *and prove that they are useful*, they are still rejected. *sigh*

(That was the last time I was tempted to contribute to glibc at all. Life is too short to work with maintainers with attitudes like that. The stack-protection patch still works, if anyone wants a version against eglibc head.)

Yama: not so fast

Posted Aug 9, 2010 21:09 UTC (Mon) by ilmari (guest, #14175) [Link] (2 responses)

Have you tried submitting your patches to the eglibc folks instead of directly to glibc?

Yama: not so fast

Posted Aug 10, 2010 5:58 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

eglibc has a stated goal to be binary and source compatible with glibc. So not too much room for many changes.

Yama: not so fast

Posted Aug 11, 2010 23:46 UTC (Wed) by nix (subscriber, #2304) [Link]

Yeah, but -fstack-protector doesn't break either of these. I think it would work. I just need to switch jobs to one that isn't totally in bed with Microsoft (they're *proud* of it) and is willing to sign the disclaimer first :/ (they said they'd sign, and said they'd sign... and didn't sign).

Yama: not so fast

Posted Aug 5, 2010 20:57 UTC (Thu) by MattPerry (guest, #46341) [Link] (3 responses)

Kees should just wait six months until the wind blows the other way. I see this sort of thing happening with increasing frequency with kernel development where a reviewer keeps flip-flopping over what changes they want to accept code.

I think what needs to happen here is the people who advocate it being a LSM and the people who think it should be in individual subsystems should come to an agreement on what to do before Kees wastes any more time rewriting code.

Yama: not so fast

Posted Aug 5, 2010 21:19 UTC (Thu) by kees (subscriber, #27264) [Link] (2 responses)

While I'd like to think that waiting will work, I suspect only constant pressure will get any traction. Lucky for me, I don't have to waste any time writing code since I've already implemented this stuff both in the core and as an LSM. ;)

All my time will be wasted trying to convince people that the changes have value. I'm still stunned that it's not obvious based on all the evidence.

Yama: not so fast

Posted Aug 6, 2010 11:59 UTC (Fri) by nix (subscriber, #2304) [Link]

But you're only plugging holes which can more easily be plugged by fixing several hundreds of thousands of broken userspace apps. The latter is surely faster than writing one not terribly large kernel patch.

Or something.

(No, I can't figure out what their rationale could be, either. I note that nobody has come up with a single case, even an academic one, which your /tmp-race-fixing restrictions would break. But it's apparently unacceptable anyway.)

Yama: not so fast

Posted Aug 13, 2010 15:01 UTC (Fri) by renox (guest, #23785) [Link]

I think that this kind of situation is easier to solve with a 'face to face' meeting(*) than by email: it's far too easy for these 'finger pointing' situations to arrive with remote discussion.

I hope that you'll keep applying pressure and be able to participate to the right 'real life' kernel meetings to resolve things.

*: provided there are not too many people in the meeting and that the 'right' people are here.