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

Yama: not so fast

Yama: not so fast

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

"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.


(Log in to post comments)

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