Re: PROBLEM: A Capability LSM Module serious bug

From: Chris Wright (chrisw@private)
Date: Mon Dec 08 2003 - 18:27:20 PST

  • Next message: Liang Bin: "Re: PROBLEM: A Capability LSM Module serious bug"

    * Liang Bin (liangbin01@private) wrote:
    > In the case of nfs, you are right! 
    > Function xprt_bindresvport ( linux/net/sunrpc/xprt.c) is an another example, it bypass capable and check cap_effective directly.
    > In order to fix this bug thoroughly, we may need replace all check code about cap_*fields with capable(cap) in kernel source tree.
    
    It uses capable(cap), that's not the problem exactly.  It uses
    cap_raise() to directly manipulate the cap_effective bits (without the
    module knowing).  Then it uses capable(cap) later to test the
    capabliity.  The dummy module completely ignores the cap_* fields, so
    the capable(cap) test became the suser() test.  This means it never saw
    the updated cap_effecitve bitfield.
    
    So this patch switches the logic around to acutally use the cap_* bits on
    the capable() call, and manage them on exec and setuid by looking at
    uids.  This has the side affect that it fixes the issue you saw, as the
    cap_* bits are initialized (to the granularity possbile in the dummy
    functions).
    
    The alternative here is to have a formalized method for asking a module
    to raise a lower privs.
    
    thanks,
    -chris
    -- 
    Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
    



    This archive was generated by hypermail 2b30 : Mon Dec 08 2003 - 18:28:42 PST