> LSM isn't flawed. It just doesn't satisfy everyone's needs. But it > is doing quite well at fulfilling the mandate given by Linus. In its > current form (modulo the list of remaining work I mentioned), it can > likely satisfy the needs of many different access control projects, e.g. > SELinux, RSBAC, LIDS, DTE, SubDomain, Janus, etc. LSM needs to > have a well-defined scope if it wants to succeed. To be fair, the translation of the restrictive hooks to before the DAC checks would continue to satisfy the needs of all of the list above except SubDomain, and in its place would be SGI. (That is, the proposition isn't that all the above projects succeed vs. SGI succeeding, but the translation will affect only 2 of the projects.) On the other hand, the change away from restrictive hooks would allow all of the projects to succeed. I'm amazed that the proposal for the authoritive hooks wasn't more widely endorsed. It would allow all projects to go forward. Instead, we read about a number of scenarios, that, while bringing up valid concerns, were performance concerns rather than roadblocks to implementation. As has been pointed out many times, not everyone will be able to get all of what they want. But IMHO, that's better than excluding an entire project. Maybe what's needed is a principle that states that the inclusion of a project always comes before potential performance problems in any one (or plurality?) of projects. As has been said before, the reason this issue keeps on coming up is that a number of people aren't comfortable with how the "resolution" was reached. This is especially true in light of a re-implementation that seems to include all the projects. --steve kramer _______________________________________________ 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 : Fri Aug 03 2001 - 08:30:37 PDT