Re: quotactl hook

From: Stephen Smalley (sdsat_private)
Date: Thu Sep 06 2001 - 06:00:53 PDT

  • Next message: Stephen Smalley: "Re: Common header for security blobs"

    On Wed, 5 Sep 2001, Chris Wright wrote:
    > * Lachlan McIlroy (lachlanat_private) wrote:
    > > There are some DAC checks that are coupled with capable
    > > calls that check for a capability other than
    > > CAP_DAC_OVERRIDE or CAP_DAC_READ_SEARCH.  For example,
    > > sys_setpriority uses CAP_SYS_NICE and sys_msgget uses
    > > CAP_SYS_ADMIN.  If we make these capabilities permanently
    > > effective then we grant all processes access to system
    > > calls, such as sys_sethostname, that are normally
    > > restricted to processes that have these capabilities.
    > ahh, this looks good.  this gets back to the argument against
    > replacing all capable() hooks.  we had considered this originally.
    > but after considering the > 500 capable() hooks all over the kernel
    > we decided that we'd use them and not replace them.  especially
    > those in device drivers.
    > so yes, i agree considering all the places where capable() calls
    > aren't followed by lsm hooks, you just gave away the house.  this
    > is unacceptable.
    > this looks like an, ahem, authoritative reason that we need to
    > support authoritative hooks.
    > i trust i'll be corrected if i'm being blind.
    I don't see the argument for CAP_SYS_NICE - we have a hook after each call
    to capable(CAP_SYS_NICE), so universally granting CAP_SYS_NICE and then
    using the restrictive hook as an authoritative hook should work. 
    The msgget example is a better one - we cannot universally grant 
    CAP_SYS_ADMIN, since we do not always have a restrictive hook after each 
    capable(CAP_SYS_ADMIN) call.  But if you look at the comment in the msgget 
    code, you'll see that they say that they could check for CAP_CHOWN 
    instead, but don't.  Actually, looking at capability.h, it seems like  
    they should be using CAP_IPC_OWNER.  IMHO, the problem here is that they 
    are using the wrong capability in this case, something we could easily 
    I agree that there are a number of different capabilities used to override
    DAC restrictions, but this is documented in capability.h.  So assuming we
    were to fix the above problem with msgget, where else is a
    single capability value used sometimes to override DAC and sometimes to
    authoritatively control an operation (where we lack a restrictive hook)?
    Stephen D. Smalley, NAI Labs
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Thu Sep 06 2001 - 06:02:34 PDT