ACL evaluation: interaction between "best match" and privilege

[Robert Watson]

In POSIX.1e D17, section 23.1.5 describes the ACL Access Check algorithm,
in which the set of process credentials is compared with the
ACL_TYPE_ACCESS ACL retrieved from disk.  The algorithm presented is
intended to be "best match" -- that is, for a particular class of checks
(ACL_GROUP_OBJ and all ACL_GROUP instances), the search will not perform a
first match, rather, it will chose the first that satisfies all aspects of
the access request.  However, this section does not describe how the ACL
access check interacts with the CAP_DAC_* privilege described in the
capabilities section, which allow individual capabilities to override
specific lack of authorization via DAC checks.  While the result is
un-ambiguous in a a fundamental sense (at the end of the day, either they
have sufficient rights or they don't), the definition of "best match" in
the face of extra privileges is ambiguous.

I.e., suppose the request is for read and write access to the object.  In
BSD (and other operating systems also, I assume), this is represented via
an access mode of VREAD|VWRITE.  Without privilege, walking down the group
entries for a "best match" would select the first entry with both
ACL_PERM_READ and ACL_PERM_WRITE.  In general, I have attempted to design
access checks in TrustedBSD such that if the request can be satisfied
purely on a discretionary basis, that is the preference, and use of
privilege is avoided as a result (from the perspective of auditing).  In
light of privilege, however, there may be a number of matches that, by
themselves could not grant access to the object, but when combined with
privilege, do.  Which one of those should be used as the "best" match?
Should I do (in effect) two passes, in which first DAC alone is checked,
then each is tested with privilege and the first is matched?  If three
rights are requested at once, is a DAC match of two right preferable to
only one, which none the less can succeed due to privilege? :-)

As mentioned, the result is the same in a purely access control sense, but
is relevant from the perspective of monitoring the use of privilege.

  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message