Re: [RFC] LSM changes for 2.5.38

From: Valdis.Kletnieksat_private
Date: Wed Oct 02 2002 - 10:55:14 PDT

  • Next message: Christoph Hellwig: "Re: [RFC] LSM changes for 2.5.38"

    On Tue, 01 Oct 2002 17:55:00 BST, Christoph Hellwig said:
    
    > For gods sake, what interface do you want to /bin/mv?  network device don't have
    > associated special files in Linux (or BSD).  I'm talking about SIOCSIFNAME.
    
    Well, I figured that you must have meant something else, since ioctl() is
    hooked, so an attacker couldn't use THAT method if the security module didn't
    want him to.
    
    Of course, that means we probably should pull that ioctl() hook too, since
    obviously there's ways to bypass it.  And at that point, we may as well
    pull the OTHER hooks too.  Hmm..  I'm starting to see a pattern here. ;)
    
    So we shouldn't deploy a check on module parameters to prevent renaming
    an interface, and we shouldn't bother having OTHER checks to stop it
    because they could always load a module and bypass it - if you feel THAT
    strongly that the whole concept of a security framework is that pointless,
    you're free not to use it. ;)
    
    > How does the lsm author know what the option x=y means for my module?  In my
    
    Umm.. the same way that *I* noticed that 'eth=0' has a security implication.
    
    It seems to me that you're arguing both sides here - first you say that
    a full code audit is needed so you know 'WTF is going on', and then you're
    saying that it's impossible to know.
    
    Either that, or you're saying "yes you can do a code audit, but having identified
    module parameters that are *KNOWN* to be a problem, you're not allowed to stop
    them".
    
    > From my reading of the LSM lists a hgook usually got added because author A
    > of the unaudited module B though that it might help him in imlpementing what
    > he and only he thinks his module should do if it worked properly.
    
    OK - so to summarize:  You're saying that somebody conceives of a reasonable
    security model, finds a set of 10 or 15 hooks that implement 95% of what
    he needs, but there's a code path that a hook doesn't catch that lets a user
    subvert the model - and then it's a *BAD THING* that the kernel be modified
    to *actually solve a problem*?
    
    Somehow, this goes against the whole spirit of the Linux kernel - I wonder
    what miniscule percent of the current kernel wasn't done to solve a problem...
    -- 
    				Valdis Kletnieks
    				Computer Systems Senior Engineer
    				Virginia Tech
    
    
    
    

    _______________________________________________ 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 : Wed Oct 02 2002 - 10:56:33 PDT