User: Password:
|
|
Subscribe / Log in / New account

Yama: not so fast

Yama: not so fast

Posted Aug 5, 2010 15:34 UTC (Thu) by dpquigl (guest, #52852)
In reply to: Yama: not so fast by Cyberax
Parent article: Yama: not so fast

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.


(Log in to post comments)

Yama: not so fast

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

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]

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]

"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]

"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 (subscriber, #23067) [Link]

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 (subscriber, #51588) [Link]

Please do, it would be interesting to read.

Yama: not so fast

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

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]

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 (subscriber, #23067) [Link]

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 (subscriber, #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


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds