| |||||||||||||
Yama: not so fastYama: not so fastPosted Aug 5, 2010 16:18 UTC (Thu) by spender (subscriber, #23067)In reply to: Yama: not so fast by dpquigl Parent article: Yama: not so fast
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
(Log in to post comments)
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 (subscriber, #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
This is an unfortunate side-effect of developing an infrastructure with
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).
> --
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
|
|||||||||||||