On Tue, Jul 02, 2002 at 02:54:46PM -0700, Seth Arnold wrote: > On Tue, Jul 02, 2002 at 05:18:40PM -0400, Valdis.Kletnieksat_private wrote: > > This raises a second concern - who's job is it to watch the kernel and > > make sure that new hooks are added in functionality when needed? In the end, it's your responsibility as the author/maintainer of the security module. If your security module is in the kernel, it's usually nice that the person making the change would also change your module. Or at the least break your module, keeping it from compiling so that you will know to take a look at it to fix it. > General kernel etiquette (sp?) is that whoever makes an important change > in one location is in charge of making corresponding changes in other > code that depended upon the old behavior. > > However, when, say, Al Viro makes a VFS change, he can hardly be > expected to make corresponding changes to the 20+ filesystems. No, he does just that. When I change a USB API, I change all 30+ drivers that use it. As you state, it's good etiquette, and is one of the benefits of having your code in the kernel tree. > I think LSM's complexity is nowhere near this bad, so hopefully, those > who make changes will be able to propogate appropriate changes through > LSM when needed. And yes, it will require vigilence on the part of > module authors. (Who better understands the security implications of > code changes? :) I think LSM's complexity is much greater than "simple" VFS or USB changes, as every security model interacts with the hooks in different ways. greg k-h _______________________________________________ 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 : Tue Jul 02 2002 - 15:50:34 PDT