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

Yama: not so fast

Yama: not so fast

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

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/


(Log in to post comments)

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