Stephen Smalley wrote: > On Sat, 2 Jun 2001, Crispin Cowan wrote: > > > So here's yet another idea: split the LSM interface into two parts, permissive > > and restrictive. Designers that want purely restrictive functionality use only > > the restrictive parts, and thus get easier/higher assurance. Those who want > > permissive functionality can turn it on if they need it. > > I'll reverse myself on the question of permissive hooks. As I mentioned > earlier, SELinux does not currently need or use permissive hooks, but we > would like to have them in the long term. However, for the same reasons > against migrating all of the logic that I cited in my reply to Howard, > I think that trying to implement permissive hooks in our first version > of LSM would be a mistake. That's interesting. "kick capabilities out" was popular with WireX engineering at last week's weekly meeting, and with David Wagner. The remaining request for permissive controls is Casey's, but he hasn't said much about it. Going further with the expedient approach to having our cake and eating it too, could we proceed with our current approach of hap hazard hook placement, but be careful to mark each of the hooks that is permissive in nature? If all permissive hooks exported an interface containing the substring "permissive", then designers can use advanced high assurance software tools like "grep" :-) to ensure that a module is on the safe side of the line. It would be my expectation that most LSM modules will pass the "grep permissive" test clean. A few (capabilities, Casey's nascent thing) would not, but it would be up to the authors (uh-oh, that includes us now :-) to audit the modules that use permissive hooks to ensure that usage is safe. Wagner proposed a full layer of indirection to manange the permissive/restrictive. David: can you elaborate on why the distinction needs to be dynamic, rather than just statically designating a given hook as being permissive, and therefore more dangerous than usual? Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com//Products/Immunix/purchase.html _______________________________________________ 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 Jun 04 2001 - 17:57:30 PDT