Christoph Hellwig wrote: > Well, selinux is still far from a mergeable shape and even needed additional > patches to the LSM tree last time I checked. This think of submitting hooks > for code that obviously isn't even intende to be merged in mainline is what > I really dislike, and it's the root for many problems with LSM. It is true that SELinux is not yet in mergeable shape, but we do intend to address those issues. With regard to additional patches, SELinux has at times diverged slightly from the main LSM patch, but we do feed back changes. At present, the only significant change in the additional patch has to do with early initialization of SELinux so that we can properly set up the security state of kernel objects when they are created rather than needing to retroactively set up the state of objects created before module initialization. That issue has come up in general for security modules on the LSM list, and we would need to submit a general solution for it along with the submission of SELinux for mainline. Hence, you are correct that there is work to be done before SELinux can be merged, but you are wrong to assume that we do not intend to do that work or to submit SELinux. > There has been a history in Linux to only implement what actually needed > now instead of "clever" overdesigns that intend to look into the future, > LSM is a gross voilation of that principle. Just look at the modules in > the LSM source tree: the only full featured security policy in addition > to the traditional Linux model is LSM, all the other stuff is just some > additionl checks here and there. I assume that you mean "SELinux" above. It is true that SELinux is the dominant user of the LSM hooks at present. We would have been happy to submit SELinux as a direct kernel patch rather than adding a further level of indirection via LSM, but that wasn't the guidance we were given. > I'm very serious about submitting a patch to Linus to remove all hooks not > used by any intree module once 2.6.0-test. Any idea on how much time that gives us (to rework SELinux and submit it)? Some of the necessary changes are simply engineering issues, but others require further dialogue, e.g. getting the API into an acceptable form, revisiting the approaches used to label and control access to pseudo filesystems. > Life would be a lot simpler if you got the core flask engine in a mergeable > shapre earlier and we could have merged the hooks for actually using it > incrementally during 2.5, discussing the pros and contras for each hook > given an actual example - but the current way of adding extremly generic > hooks (despite the naming they are in no ways tied to enforcing security > models at all) without showing and discussing the code behind them simply > makes that impossible. We would have preferred this route as well, but again it wasn't the guidance that we were given. We were told to work on something LSM-like, then told to wait to initially submit it until after certain other changes went into 2.5. > So yes, my suggestion is to backout the whole LSM mess for 2.6, merge > a sample policy core (i.e. a cleaned up flask/selinux) in 2.7.<early> and > then add one hook after another and discussing the architecture openly > where it belongs (here on lkml!). Leaving 2.6 with no infrastructure for access control extensions at all? Is this really preferable to keeping LSM in 2.5/2.6, and then migrating to a more directly integrated architecture in 2.7? -- Stephen Smalley, NSA sdsat_private _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Mon Feb 10 2003 - 08:48:47 PST