Re: Last question on rm -f unused_hooks*

From: Greg KH (gregat_private)
Date: Tue Oct 01 2002 - 11:18:41 PDT

  • Next message: Chris Wright: "Re: graft_tree/attach_mnt rfc"

    On Tue, Oct 01, 2002 at 01:11:53PM -0400, Demetrios Lambrou wrote:
    > 
    > 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.
    
    I agree, that would be a problem.  But that's not what we are talking
    about here :)
    
    > While now people are (in a way) forced to adapt their modules to the
    > existing framework.
    
    And if their module does not match the existing framework, they are
    encouraged to propose changes to the framework.  How else do you think
    the development process here works?
    
    > 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.
    
    Ah, see my point about stuff not being in the kernel that isn't currently
    used.  And remember, Linux isn't a "frozen" interface, things constantly
    change.
    
    > It is not that I have a module that uses the hooks you are removing.
    
    Great, we don't have any problems then, right?  :)
    
    > 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)! 
    
    Heh, don't bring up auditing :)
    
    Sounds like you really want to look at kprobes/dprobes, or possibly LTT.
    
    > 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.
    
    But that's not what it is ment for.  Again, go look at LTT.
    
    > 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?
    
    The module_* hooks are now gone, I'll look at the others later on, and
    post patches here for comment if I see anything that looks ripe for
    removal.
    
    thanks,
    
    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 Oct 01 2002 - 11:22:22 PDT