Re: permissive vs. restrictive issue and solutions...

From: Stephen Smalley (sdsat_private)
Date: Fri Jun 01 2001 - 06:32:53 PDT

  • Next message: Titus D. Winters: "Re: permissive vs. restrictive issue and solutions..."

    On Thu, 31 May 2001, Crispin Cowan wrote:
    
    > Another option we discussed in a meeting this afternoon was "kick capabilities
    > out".  All of the security modules we (WireX) understand are "restrictive",
    > and only capabilities is "permissive". If we kick capabilities out of the
    > picture, LSM gets simpler.
    
    I think the problem is that we are thinking of capabilities as a
    standalone module rather than as a replacement for the superuser
    logic that in turn is merely a portion of the overall base Linux
    access control logic.  Being able to decompose the superuser is a very 
    useful ability. In prior prototypes (e.g. DTOS), we've decomposed the
    superuser using Type Enforcement (TE) into multiple domains, and we would
    like to be able to do the same thing in Linux.  In fact, I would think
    that the Linux kernel developers would be favorable to the notion of
    being able to decompose the superuser into multiple roles/domains.  If
    you move all of the Linux access control logic into the hook functions
    (option #2), then capabilities or TE overrides simply become part of the 
    internal module logic.  If you take option #3, then the module
    is free to implement capabilities or TE overrides if it wants.
    
    Also, it should be noted that some capabilities are used to
    control the use of privileged operations, while other capabilities 
    are used to override DAC restrictions.  So capabilities are not
    always "permissive".
    
    > "Kick capabilities out" also comes in two flavors.  One is to leave it in the
    > kernel, rather than make it an LSM module.  The other is to kick it right out
    > of Linux, because the POSIX standard has failed, support for Capabilities in
    > Linux is lame, and we think it sucks anyway :-)  As with some other options,
    > this may be a hard sell.  But I think it deserves serious consideration.
    
    I'm all for leaving the existing capable() calls alone, and merely
    inserting one of our hooks into the capable() function to allow
    the module to implement additional logic on capability checks 
    (in addition to inserting new hooks wherever we need them,
    including some overlap with the capable() calls in cases where
    we need more parameters).  But I think that we do need to move the rest of
    the capability logic out of the base kernel (e.g. the guts of the
    capable() function, the processing in execve, the processing in the
    capability-related system calls) based on Linus' message that sparked this
    effort.  People can then choose whether they want a real capabilities
    module or if they just want the traditional superuser logic or if they
    want to use Role-Based Access Control or Type Enforcement to decompose
    root instead (the latter being my own preference).
    
    It isn't really fair to bash the capabilities implementation based on
    what is in the current kernel, since it lacks support in the file
    system.  I think the Linux-Privs people have an implementation that does
    provide such support.
    
    --
    Stephen D. Smalley, NAI Labs
    ssmalleyat_private
    
    
    
    
    
    
    
    
    _______________________________________________
    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 : Fri Jun 01 2001 - 06:35:11 PDT