Re: Revised list of restrictions and privelege attributes

[[e-mail]]

I am having a bit of trouble understand this whole first paragraph.
Either some ASCII art, or a concrete example showing a user doing
something like FTP speaking to an ftp server on another machine?

>  A proxy inherently grants certain rights

The server that controls the data (i.e., the reference monitor) is
the entity that actually grants the rights -- it interprets the
chain and decide whether or not to satisfy the request.

>  A flags
>field associated with each kind of attribute encodes the appropriate
>behavior if the interpretation of the attributed is not known.

Reading the next section (Attributes and Restrictions), however, makes me
think that I'm reading this wrong and that you do really intend to attach
rights to identities, and not attach rights to objects inside the server.
Is that right?  If so, that's wrong. :-)

Can someone explain why the Posix ACL model is not sufficient?

>Conceptually, the DCE privilege attribute certificate specifies both
>group information and the local UID.  The name of the privilege server
>is derived from the name of the principal signing the proxy.

A DCE pac does not include a local UID.  This information is available
through the DCE security service, but it is *never* used in making DCE
authorization decisions.  It is also important to note that a DCE PAC
never includes any rights.  It contains only a set of DCE UUID's which
identify the user and their group membership(s).  There are various
levels of certification which can be used on this data.  The strictest
is that a Kerberos-like session key is used to encrypt the PAC so that
only the server can decrypt it; as an intermediate level it can be crypto
checksum'd just to make it tamperproof.

>encourage the use of GROUP_MEMBERSHIP and LOCAL_UID instead.

Using LOCAL_UID is probably not a good idea; what does that mean on
an MSDOS machine talking to an MVS and Unix server?
	/r$