Re: Authoritative Hooks

From: Stephen Smalley (sdsat_private)
Date: Fri Nov 09 2001 - 05:30:47 PST

  • Next message: Stephen Smalley: "Re: Authoritative Hooks"

    On Thu, 8 Nov 2001, Casey Schaufler wrote:
    > An unprivileged process owned by stephen.nai ought to have
    > write access to the file, based on the ACL. It will fail the
    > mode bit check, however. Not to be denied, the capable() call
    > will be made. The capable call will look in the security blob
    > to determine what kind of object (file, SVIPC, socket, ...)
    > being accessed so that it knows what kind of data to look for.
    > It then looks for that data, in this case an ACL, and
    > upon finding it, checks it against the process attributes. This
    > will yield success, and the access will be granted.
    Not exactly.  The capable call doesn't have any object information,
    just the task and the particular capability.  I would expect you to
    implement POSIX ACLs (or any other scheme that requires authoritative
    behavior for file access controls) as follows:
    1) The security module's capable hook function would always return
    success for CAP_DAC_OVERRIDE or CAP_DAC_READ_SEARCH.  This causes
    a bypass of the kernel DAC logic in vfs_permission, ensuring that
    the "restrictive" permission hook function is always called by the
    2) The security module's permission hook function would then perform the
    complete (and authoritative) access control decision, including whatever
    combination of POSIX ACLs and mode bit logic you want.
    I believe that this is functionally equivalent to making the permission
    hook authoritative.  In earlier discussions on this list, it was shown
    that this capable+restrictive scheme doesn't work for all of the kernel
    access controls (e.g. any case where CAP_SYS_ADMIN is used to override a
    DAC decision, because it is also used authoritatively), but it appears to
    work just fine in this case, and this appears to be sufficient for POSIX
    Stephen D. Smalley, NAI Labs
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Fri Nov 09 2001 - 05:33:36 PST