ACL evaluation: interaction between "best match" and privilege

Robert Watson rwatson at FreeBSD.org
Fri Sep 22 17:24:03 GMT 2000


On Fri, 22 Sep 2000, Casey Schaufler wrote:

> Ugh. Reason number 806 to dislike ACLs.
> 
> There is no 100% defensable solution. Where were you when
> we were writing this spec? We could have used your devious
> viewpoints.

I try :-).

> What I advocate, and I do this not because I think it's
> right, but because it's fairly clean, is to fall out of
> the ACL check with a failure and then require ALL capabilities
> necessary to get the access be present. I suggest this in
> the spirit of ACL entry non-combinability. I also think
> that any other scheme leads to madness, or at least excessive
> bookkeeping.

Hmm.  While I think there is a certain intellectual cleanness to this
solution, it doesn't seem consistent with the combination of capabilities
and permission-based DAC.  That is, while the goal of not combining ACL
entries is worthy, notable, and good, as well as consistent with
permissions, from the perspective of the user I think it makes more sense
for privilege and DAC to be combined effectively in a logical ||
operation.  With a single privilege (suser), the logical || has the nice
short-ciruit boolean property that privilege is only used if normal means
fail.  With fine-grained privilege, we have this desire for an optimal
(minimal) use of privilege.

My objection to the current ambiguity was that it doesn't define what
optimal is local to this access control check:  i.e., it doesn't identify
which privileges should be used if there is a choice.  On further
contemplation however, this is not as bad as I thought.  Sure, it doesn't
let me define optimal and therefor choose the optimal result.  On the
other hand, there is, I think, a strong argument that that local
optimization might not be globally optimal.  I.e., suppose we do define
some local optimum.  That doesn't imply that, if multiple access checks
are required (vis rename()), the global result will be optimal.

Consider the following type of situation (may not reflect reality).  Two
access checks might be involved in some operation:

  Check#   Satisfied by ACL   Satisfied with which CAPs   Optimal CAP
  1        Nope               READ_SEARCH / WRITE         WRITE
  2        Nope               READ_SEARCH / EXECUTE       EXECUTE

(This example probably does not reflect any real combination, but
illustrates the point--imagine instead the need for READ_SEARCH and WRITE
relating to a rename across two directories).

Globally, the optimal CAP would probably be READ_SEARCH, as the result of
two locally optimal checks ends up being the use of both WRITE and
EXECUTE.  It's probably (almost certainly) undesirable to implement, let
alone mandate, globally optimal capability use.  At which point, you begin
to wonder: how optimal should we try to be locally?  The answer is
probably "best effort" :-).  Attempt to be optimal: use DAC before falling
back on privilege.  When using privilege, make use of as little privilege
as possible locally (i.e., if DAC permits write, but not read, use
privilege only for read even if you have privilege to write), but don't
try too hard.

  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



More information about the posix1e mailing list