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

Yama: not so fast

Yama: not so fast

Posted Aug 5, 2010 16:10 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
In reply to: Yama: not so fast by dpquigl
Parent article: Yama: not so fast

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.


(Log in to post comments)

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.


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