On Thu, 23 Aug 2001, Greg KH wrote: > That is a real concern at this point. Keeping the original patch small > and "obvious" is very important. > > I like Crispin's "roadmap". After we get the original hooks in the > kernel, then we can move on to possibly changing them to a format like > this patch if people want them (and it looks like people do.) > > Sound ok? Actually, it was Crispin who (to my surprise) seemed like he was going to jump on the authoritative hooks bandwagon at the BOF in order to meet SGI's needs. As far as SELinux itself goes, it doesn't matter for our current functionality - restrictive hooks are good enough. I agree that if the authoritative hooks patch is likely to be a stumbling block to the kernel developers, then we should defer it. Simply getting the restrictive hooks into the Linux kernel would still enable a significant improvement in the state of Linux security. But while I'm willing to concede that parts of the authoritative hooks patch might be a stumbling block, I'm not sure that all of it would pose a problem. For example, transitioning from the restrictive inode permission hook to the authoritative one is quite trivial. I was hoping that WireX and you might give more specific feedback on what parts of the authoritative hooks patch might be acceptable now. -- Stephen D. Smalley, NAI Labs ssmalleyat_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 : Thu Aug 23 2001 - 09:29:59 PDT