| |||||||||||||
Yama: not so fastYama: not so fastPosted Aug 5, 2010 18:37 UTC (Thu) by dpquigl (subscriber, #52852)In reply to: Yama: not so fast by Cyberax Parent article: Yama: not so fast
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.
(Log in to post comments)
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 (subscriber, #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.
|
|||||||||||||