RE: LDAP ACLs

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

And fo my two bobs worth - 
that is why the ACLs in X.500 permit access definitions which tie users
to objects and one can arrange a User/Object(entry) mix in their
definition.
As we all move to the object oriented paradigm for document, icons,
directory entries, files and functions, should we not have the acl that
applies to objects/users as the common denominator.

Now below the abstract definition of ACLs, is the implementation which
can be rules based, apply asn.1 directly , use the trusted OS, etc,

I still do not see the issue in that one ACI specification which is
abstracted by ASN.1 (hence the A) as per X.500 cannot be applied to
cover all objects  and map to the various real objects and their lower
ACDFs.

If one has used many ACL processes in one's O/S  and its not quite
object oriented - I think it is wrong to propoagate those into a
"standard"..
We can put files, images, voice, HTML.... in our X.500 and protect them
with X.500 ACLs - we can even protect other servers that connect to us.

One format please and the ACI definition X.500 works - is object
oriented and if implemented correctly works well.

regards alan
> -----Original Message-----
> From:	Paul Leach [SMTP:paulle@microsoft.com]
> Sent:	Thursday, April 30, 1998 5:36 AM
> To:	prasanta@netscape.com
> Cc:	ietf-ldapext@netscape.com
> Subject:	Re: LDAP ACLs
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> I can see I need to explain more of the context.
> 
> We have a file system (FS). We have a mail system. We have a
> configuration registry. We have a web server. Each of these provides,
> at some level of abstraction, a hierarchical data store. They contain
> named objects that have attributes which in turn have values.
> 
> We have a directory service (DS). It too is a hierarchical data store.
> which contains named objects that have attributes which in turn have
> values.
> 
> We use LDAP to access the DS. Why shouldn't we use LDAP to access the
> FS and the mail store and the registry, too? And everyone always wants
> HTTP access to everything, right? Well, that would cause a big
> problem, as I will explain.
> 
> In NT, _all_ objects can be ACL protected. These ACLs are used by the
> System Reference Monitor (SRM) in the Trusted Computing Base (TCB) to
> check all accesses. The organization of the system into SRM and TCB is
> consistent with the Trusted Computing System Evaluation Criteria
> (TCSEC, also know as the "Orange Book") and its companion, the Trusted
> Network Interpretation (TNI, aka "Red Book") by which systems applying
> for (e.g.) C2 level security ratings are evaluated.  One of the
> criteria is that it MUST NOT be possible to bypass the access checks.
> In NT, the way we do this is to use one ACL format for all objects and
> one SRM for all objects. Anything else clearly would mean depending on
> two mechanisms instead of one -- highly undesirable from a security
> point of view.
> 
> Now, lets say that we allowed LDAP access to FS. Suppose that the LDAP
> standard ACL format is not capable of _exactly_ representing the same
> access policy as NT ACLs. Then it must be the case that accessing an
> object via LDAP or the FS protocol, or local APIs, will cause
> different accesses to be allowed of denied. That would be a violation
> of one of the security policies -- either the one specified by the NT
> ACL or the one expressed by the LDAP ACL. I.e., that would be a
> security breach.
> 
> Now, we have plenty of experience which says that no two ACL formats
> are _ever_ perfectly mappable. As the simplest example, take
> traditional Unix "user/group/world" permission, and an ACL that allows
> multiple users and groups to be on an ACL -- there is no mapping.
> 
> My conclusion is that any system that supports access to objects via
> multiple protocols and/or local API can not securely support multiple
> incompatible ACL formats for those protocols/APIs. Since we are such a
> system, we couldn't support an incompatible ACL format. Since it seems
> unlikely that anyone other than us would like to standardize on ours
> (:-), that lead to my proposal.
> 
> - ---------------------
> Paul J. Leach <paulle@microsoft.com>
> PGP Key ID: 0x978829DD
> Fingerprint: 9EFA A405 39B4 F91F DE6F 8939 6FE9 F5D8
> Key Servers: http://pgpkeys.mit.edu:11371 ldap://certserver.pgp.com
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 5.5.5
> 
> iQCVAwUBNUeBOsqlCdSXiCndAQGgtAP+NXYjhQ6OEBDPn1xjbzXrCO0F767WHeXG
> BeSU2FlyTaO1YLNeBb+eu4OBzSkLqIH+5Qw/+G/83ssYOLVbOmOwkv6n5c6e7XTp
> INl0ZQx/6MpwFku+SE792nHVpUOnS+hYpoes4aIgSRct9bZ8rTzsXUhTYfSABqvK
> wqK00pdN+xs=
> =BQGH
> -----END PGP SIGNATURE-----
>