On 04/24/2013 02:15 PM, Paul Moore wrote: > On Wednesday, April 24, 2013 01:22:20 PM Casey Schaufler wrote: >> On 4/24/2013 11:57 AM, Paul Moore wrote: >>> 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. > > Hmmm. How difficult would it be to enforce the order during LSM > registration? > As discussed previously, I'm not a big fan of assigning the network controls > at compile time when the LSMs can be toggled at boot time. > > The real solution is to just get the netdev folks to accept a security blob > in > the sk_buff so we can fix this (and many other problems) once and for all. I > still haven't given up on this effort but I think it would be silly to hold > up > the stacking effort for the sk_buff security blob. > >> 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. > > The defaults are always going to be wrong for someone. > >> 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. > > Well, maybe not ... I think. If we take a FCFS approach to the network > controls then only one LSM is really ever going to throw an error on the > network hooks, yes? > >> 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. > > I think the "excessively complicated" boat has already sailed :) > > I'm still in favor of assigning the network hooks to the LSM at boot based on > the "security=" configuration. > yeah dealing with selection at boot time is going to be needed at some point, whether its now or later ...
-- 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/
