Today the LSM interface is pretty well defined in terms of the hooks used to enforce the policy. It's easy to look there and identify how to go about implementing an access control scheme once you've decided what you want to do and how you're going to obtain the information required to make your choices.*
What's not always clear is how an LSM ought to interact with other security sub-systems, networking and audit being my examples of the day, and the mechanisms these sub-systems use to interact with the LSM. Before I go any further, I acknowledge the fact that in the days of a single mainline LSM it just wasn't a big deal. As far as I'm concerned all past sins^H^H^H^Hoptimizations are forgiven. I also want to acknowledge that things like secid's aren't going away any time soon, so nobody need get defensive about existing practices. I would like to propose a scheme for those things that are tightly associated with the LSM but that are not LSM components themselves such that it's easier for both the LSM developer and the "other" developer. I believe that both sets of people will benifit from a little clarity. Before I put too much effort into this, the kind issues I think that need to be addressed are on the order of what are the data elements that an LSM can export, and what are they good for? Today I would suggest that there are exactly two, the secid and the secctx, and that the former is for passing about and the latter is for printing. Another question is the SELinux specific code in audit, and whether it's best to make that LSM neutral (my preference) or require each LSM to implement audit on it's own. I honestly don't see anything that needs doing that ought to get anyone bent out of shape (myself included) but I think that we can clarify some of these things and make (most) everyone's life a little easier. So here's your chance to tell me what you think needs to be said about the LSM and the things that do or might want to use it before I try to codify may view of existing practice and what ought or oughtn't be embraced, abandoned, or changed. Thank you. ** ---- * This isn't always easy, mind you, as the AppArmor effort will attest, but that's tangential to where I'm going with this. ** Bit of a ramble that. Hope I was clear enough. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
