On 4/24/2013 11:57 AM, Paul Moore wrote: > On Tuesday, April 23, 2013 09:04:06 AM Casey Schaufler wrote: >> Subject: [PATCH v13 0/9] LSM: Multiple concurrent LSMs >> >> 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. >> >> 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. > ... > >> The NetLabel, XFRM and secmark facilities are restricted to use >> by one LSM at a time. This is due to limitations of the underlying >> networking mechanisms. The good news is that viable configurations >> can be created. The bad news is that the complexity of configuring >> a system is necessarily increased. > I know we had a good discussion about this a while back and I just wanted to > hear from you about this current patchset; how does the labeled networking LSM > assignment work? Is it first-come-first-served based on the 'security=' > setting? It's explicitly set in security/Kconfig. The problem with first-come-first-serve is that the LSMs don't actually register in the order specified, either at build time or boot time. Further, until the init phase is complete, you don't know which LSMs are actually going to register. That, and I promised Tetsuo I wouldn't go out of my way to prevent late module loading in the future. I could do order checking on module registration and take the networking component away from an LSM that registered earlier, but with a larger order number I suppose. The default configuration gives xfrm and secmark to SELinux and NetLabel to Smack. If Smack is not included NetLabel goes to SELinux. When LSMs using any of these facilities are added in the future we'll have to negotiate the defaults. An interesting aside that may be relevant is that the error condition behavior makes it advisable to have the LSM you care about most go last. If the networking components were strictly FCFS you might have to chose an ordering you might not want for other reasons. It would be possible to have a boot time specification for the networking components if you think it's important. I do worry about making it excessively complicated. I'd be much more concerned if more LSMs used the networking components. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
