Quoting Greg KH <gregat_private>: > On Tue, Oct 01, 2002 at 06:09:47AM -0400, Demetrios Lambrou wrote: > > > > So you are saying that frequent changes to the base kernel (once LSM > becomes > > part of the mainstream kernel) are ok and that Linus would be happy to > have > > new hooks added ,whenever there is a person that has a new LSM idea. > > I do not speak for Linus, so I do not know. My point here is that when people want to place new hooks in different places in the same chunk of code there might be a problem. While now people are (in a way) forced to adapt their modules to the existing framework. So you end up with a generic interface to the kernel, and although you dont fully use it , it will be there and people will be able to use it in the future. > > > But he is not happy with the idea that there would be some hooks > that > > are not used at the time of the merge. Maybe the LSM people should > > give it some more time before cutting out hooks. > > I am not happy with the idea that there would be hooks in the kernel > that are not being used. That's not the Linux way. If the code isn't > being used, it's removed. I do not expect to ask anyone to try to > maintain the presence of a hook that is not being used. > > And personally, I will not ask Linus to accept a patch for a hook that > is not being used. If you have a problem with my decision about this, > and think you can make a convincing argument to the upstream > maintainer > of the specific piece of code where that hook lives, by all means, > please do. > > > Why dont you keep it simple and stick to the original LSM design? > > That sounds simple to me. And what design rules am I breaking with > this > statement? > > > If you really think that some hooks should not be there, publish a > new > > paper called the "New LSM framework" and then change the framework. > > Hm, a bit touchy aren't we? :) > > Seriously, we are still mediating access to kernel objects, just like > the original design. I don't see how getting rid of the module_* > hooks > means we have a "whole brand new LSM framework" to deal with. > > > The original paper is getting a bit out of date now. The framework > is > > drifting slowly from truly generic to 5 or so existing LSMs > specific. > > Patches gladly accepted. As all we have to work with is 5 or so > existing chunks of code that actually _use_ this framework, I don't > know > what else we can use. > > If you have a LSM module that needs one of the hooks that we are > proposing removing, speak up! It is not that I have a module that uses the hooks you are removing. With the security hooks in every critical point in the kernel it would possible to create a module that monitors any subject you are interested in , and being able to create a history of what the subject did before it finally exits. What good is this ?? For educational purposes at the moment (sth like a kernel auditing mechanism)! As I said before the LSM framework although designed to provide an interface to security modules, it could be used for other purposes as well. If and when i have sth that needs removed hooks i will sure let you know :-) By the way which hooks have you finally decided to remove for the time being? Thanks -- Demetrios Lambrou http://crazylinux.net ---------------------- _______________________________________________ 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 Oct 01 2002 - 10:04:22 PDT