Subject: RE: Questions about ACL speical ids, evaluation, and ACE processi ng

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 23 Sep 2002 07:53:25 -0700

Carl Burnett wrote (among other things):
> Also, what are people assuming about cases of duplicate entries in an
> ACL?

The spec gives you a model to evaluate the ACL.  It applies even if
there are duplicate entries, and there's no statement about duplicate
entries being an error.  It may not be sensible to create two entries
that are precisely the same (since the second will have no effect),
but unless the spec explicitly says that something is an error, I 
think server should do as it was requested.  

> Should an error result if one of the special identifiers appears
> twice? 

Definitely not.  You can meaningfully check a special identifier with
an allow entry for one set of permissions, then have a deny entry for
some other identifier (e.g. a group that a user who matches the special
identitier may also belong to), and then have anotehr allow entry for
the same special identifier with different permissions.

> What if a user or group ACE is in the ACL twice? Should this be an
> error? 

No for the same reason as the case above.
 
> Should the duplicate entries be merged, etc? 

I can't see why they should be.  A more interesting question is "May
the entries be merged" and I guess the answer is "Yes".  It would be
nice if GETATTR(ACL) after SETATTR(ACL) would give you back what you 
stored but for lots of reasons clients are not going to be able to
assume that.

> Does the server
> need to check the ACEs for this type of stuff in a SETATTR?

I would say just implement the ACL model in the spec.  If you can't
(because of the underlying file system) do the best you can.  If the
underlying file system imposes various restrictions then you are 
stuck but the V4 implementation shouldn't be adding any restrictions.

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 23 Sep 2002 19:43:00 -0700

Carl Burnett wrote: 
> >From the 03-01 draft of the RFC, I have questions on the ACL sections.
>
> Special Identifiers -
> 
> Does EVERYONE include both authenticated and unauthenticated users?

I would think so.  If it didn't include unautheticated users, then it
would be a synonym for AUTHENTICATED, and would be pointless.

> Where is it evaluated with respect to ANONYMOUS and AUTHENTICATED,
> before or after?

Not sure what you mean.  The ACE's are evaluated in the order that
they apppear in the ACL, regardless of the specific who that appears.

> What exactly defines an AUTHENTICATED access? Would the case of a server
> mapping a valid RPCSEC-GSS principal to a local cred of nobody be an
> an AUTHENTICATED or ANONYMOUS access?

Not sure.  I would think it depends on the motivation.  If for some reason
the server decided that it wasn't (sufficiently) sure of who was at the
other end, the RPCSEC_GSS principal notwithstanding, then I would say
that ANONYMOUS applies.  If on the other hand, it decides that some class
of users are to be treated as having minimal privilige for other reasons,
then maybe you should consider it AUTHENTICATED.  But from a practical 
point of view, people are going going to wind up cdoing ACL's assuming
ANONYMOUS means nobody.  I can't imagine distinguishing between ANONYMOUS
and AUTHENTICATED nobodies (but maybe there are those who can).  However,
if people wind up coding ACL's assuming nobody and ANONYMOUS are synonomous
then servers will wind up treating everybody mapped to nobody as ANONYMOUS.
So may be that's the best way to proceeed until and unless someone comes
up with a reason to distinguish those two.

> Similarly, what are the exact cases that map to an ANONYMOUS access? Would
> that be cases like a RPCSEC-GSS principal that can't be accepted, or an
> AUTH_SYS request mapped to nobody, or an AUTH_NONE access?
> Should AUTH_SYS even be considered as authenticated?

I think that is up to the implementation.  A server is free to reject 
all AUTH_SYS or to treat AUTH_SYS as ANONYMOUS or to vary the handling
based on other considerations (e.g. AUTH_SYS within the machine room).
The server decides what it considers sufficient to authenticate someone.

Also I expect that many servers might not allow any unautheticated access
so that ANONYMOUNS always refers to the null set.

---

From: Carl Burnett <[email-masked]>
Date: Tue, 24 Sep 2002 07:44:41 -0500

Thanks for the feedback Dave. My remarks are below within [carl ...]

Carl

Carl Burnett
AIX Kernel Architecture - Distributed File Systems
(512) 838-8498, TL 678-8498
(please reply to [email-masked])

"Noveck, Dave" <[email-masked]>
09/23/2002 09:43 PM

        To:     Carl Burnett/Austin/IBM@IBMUS, [email-masked]
        cc: 
        Subject:        RE: Questions about ACL speical ids, evaluation, and ACE processi       ng

[carl: That was my guess. If EVERYONE did not also cover the UNIX
 "others" bits, then it wouldn't be needed. AUTHENTICATED
 and ANONYMOUS together could specify "everyones" access.
]

[carl: This seems weird, but ok. The order dependent part of the ACL
 model looks like a big trap door for creating security exposures.
 One view is that the special identities are "special" as their name
 implies. It seems reasonable that EVERYONE should not be position
 independent, and perhaps be evaluated last since its effectively
 the UNIX others equivalent. This also seems that it should not
 be repeated in an ACL because it maps to UNIX others. If it can
 exist multiple times, then ACL admin tools, and probably the server
 must give special consideration to EVERYONE, in order to form the
 UNIX mode bits correctly. When you go into the NT GUI for security on
 a file, it only allows you to specify a single EVERYONE ACE.
]

if people wind up coding ACL's assuming nobody and ANONYMOUS are 
synonomous
then servers will wind up treating everybody mapped to nobody as 
ANONYMOUS.

[carl: My view is that AUTHENTICATED means the RPC is able
 to accept the credential as defined by the AUTH flavor. In the case of
 RPCSEC-GSS, it means the accept of the credential is successful. That
 means the principle is a valid principle in the server's authentication
 realm, or the principle comes from another realm where there is 
inter-realm
 trust. This qualifies as authenticated regardless of the resulting server
 side credential (even it it gets mapped to nobody). For something like
 AUTH_SYS, perhaps everything is considered authenticated since the server
 is effectively trusting the client to build credentials. Its debatable.
 There is value in having a distiction between AUTHENTICATED
 and ANONYMOUS. Think of AUTHENTICATED as a "trusted" others, and
 ANONYMOUS as pure public access.
]

[carl: I think it is important that the spec define exactly what
 maps into ANONYMOUS and AUTHENTICATED. If you leave it to the
 implementation, then you end up with different authorization models,
 and no NFS ACL standard. If the specification is going to define
 authorization (evaluation) semantics, then those semantics
 and related details must be complete. Otherwise how can an
 implementation claim compliance to the NFS V4 described ACL.
 How can one expect to see consistent access control across
 different server implementations? How can one produce a
 verification test. If the spec wants to leave these details
 to the implementation, then perhaps it should withdraw all language
 about how the ACL is evaluated, and simply present the format
 definition and protocol operations as a means of communicating an
 ACL description between server and client.
]

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 24 Sep 2002 09:06:58 -0700

> carl: This seems weird, but ok. The order dependent part of the ACL
> the UNIX others equivalent. 

I think the problems that EVERYONE poses for people trying to form
mode bits makes it advisable for clients to put it last, when they
can.

As far as it being reasonable to make special identities non-position-
idependent, I think that would complicate the spec.  In any case, it
isn't what the spec says.  The spec presents a model in which the
evaluation is order-dependent.

> This also seems that it should not

Since a lot of servers will support the posix-acl subset, many 
tools will only support one EVERYONE, have no deny ACL's, etc.
Other servers, that have CIFS ACL support will support all of the
options and I think CIFS supports any number of EVERYONE's anywhere. 

> ACL description between server and client.

Your mission, should you decide to accept it, is to precisely define
the semantics of NETWORK, BATCH, DIALUP, etc., (e.g. is IP over IB
within the machine room "on the network"?  Why or why not?  What about
DAPL over IB as an interconnect within an SSI cluster?  What if the
cluster isn't precisely SSI?) so that we reach consensus within the 
working group and the ietf and the result is capable of being checked 
by a verification test.  Good luck.  The fact that we can't do that
does not mean that we should have no ACL evaluation model at all.

As to ANONYMOUS and AUTHENTICATED, consider three cases.  Case one is
that someone is trying to access a file and I don't know who it so I 
give them the minimum possible access (i.e. ANONYMOUS).  Case two is
that someone is trying to access a file and from his behavior I 
conclude that there may have been a compromise of his account and so
even though the user is authenticated, I suspect that the actual
person at the other end is not correct.  Case three is that I don't
believe the account has been compromised but I believe the actual 
person has been bribed.  I don't see any value in the spec carefully
trying to distinguish cases one, two, and three and deciding, for
instance, that in case three it must not treat the user as ANONYMOUS.
If the administrator wants to not kick the user off and let him
retain his lcoal identity (for tracking purposes) but reduce his 
access to that that an unauthenticated user would have (and so treat
him as ANONYMOUS for ACL's, then I say that is up him.  Anybody who
codes an V4 ACL distinguishing AUTHENTICATED from ANONYMOUS would want
to treat this user as the latter.  If you say doing it this way is
a spec violation, I say the spec isn't clear, and I can beat
the rap.  You could draw the spec more tightly so my guilt is clear,
but what's the point?  The most I'd get is probation.