On Thu, Aug 1, 2013 at 10:51 PM, Casey Schaufler <ca...@schaufler-ca.com> wrote: > On 7/31/2013 7:48 PM, Balbir Singh wrote: >> On Thu, Jul 25, 2013 at 11:52 PM, Casey Schaufler >> <ca...@schaufler-ca.com> wrote: >>> Subject: [PATCH v14 0/6] LSM: Multiple concurrent LSMs >>> >>> Version 14 of this patchset is based on v3.10. >>> It required significant change from version 13 due to changes >>> in the audit code. It came out cleaner, especially in the changes >>> to NetLabel. This version supports all existing LSMs running >>> together at the same time. The combinations tested most completely >>> are: >>> >>> apparmor,tomoyo,smack,yama - Ubuntu >>> apparmor,selinux,smack,yama - Fedora >>> >> Does this change the way one would develop a new LSM module? I presume >> it does not > > The change that LSM developers need to be aware of is the security blob > abstraction. Instead of using cred->security, inode->i_security and the > like the code needs to use lsm_get_cred() and lsm_set_cred() and similar > functions. >
OK >>> I have been unable to figure out how to configure SELinux on >>> Ubuntu and TOMOYO on Fedora. That's the only reason the list >>> does not include all five LSMs at once. Combining LSMs that >>> use networking is tricky, but can be done. There are changes >>> coming from AppArmor that might make it even trickier, but >>> that's a problem for the future. >>> >>> >>> Change the infrastructure for Linux Security Modules (LSM)s from a >>> single vector of hook handlers to a list based method for handling >>> multiple concurrent modules. All combinations of existing LSMs >>> are supported. >>> >>> The "security=" boot option takes a comma separated list of LSMs, >>> registering them in the order presented. The LSM hooks will be >>> executed in the order registered. Hooks that return errors are >>> not short circuited. All hooks are called even if one of the LSM >>> hooks fails. The result returned will be that of the last LSM >>> hook that failed. >>> >> This is an important design trade-off. From my perspective I think you >> might want to revisit this, today it sounds like effective security == >> all hooks process and allow the operation. In this world a lack of >> proper policy/setting can make hooks fail. I've not yet looked at the >> code, but you might want to revisit this. > > The result of an LSM hook will be failure if any of the LSMs > indicates failure. The key here is that all of the LSM hooks > get called even if it's known that the overall result is failure. > This is done because many LSM hooks maintain internal state and > shortcutting can disrupt that. > Thanks for clarifying Balbir -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
