Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
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 (subscriber, #52852)
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.
Posted Aug 5, 2010 16:10 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
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.
Posted Aug 5, 2010 18:37 UTC (Thu) by dpquigl (subscriber, #52852)
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.
Posted Aug 5, 2010 18:53 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
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.
Posted Aug 5, 2010 19:20 UTC (Thu) by dpquigl (subscriber, #52852)
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?
Posted Aug 5, 2010 19:29 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
"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.
Posted Aug 5, 2010 16:18 UTC (Thu) by spender (subscriber, #23067)
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.
Posted Aug 5, 2010 18:05 UTC (Thu) by SEJeff (subscriber, #51588)
Posted Aug 6, 2010 17:07 UTC (Fri) by spender (subscriber, #23067)
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.
Posted Aug 8, 2010 20:55 UTC (Sun) by nix (subscriber, #2304)
I don't think my record shows me to be a person to make something up (see: vendor-sec)
Posted Aug 5, 2010 18:50 UTC (Thu) by dpquigl (subscriber, #52852)
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 . 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."
Posted Aug 5, 2010 19:31 UTC (Thu) by spender (subscriber, #23067)
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?
Posted Aug 6, 2010 11:48 UTC (Fri) by nix (subscriber, #2304)
Have there ever been any? At all? I'm not aware of any...
Posted Aug 6, 2010 18:55 UTC (Fri) by spender (subscriber, #23067)
> 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 ;)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds