[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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-----