[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Comments on the ACL Model draft
This is a joint set of comments from Ryan Moats and Rick Huber. We've
been discussing them internally for a while, so they may repeat some of
the last day's discussion on the list, but there is a fair amount of new
material here.
Rick Huber
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
Page 3
TECHNICAL:
No mechanisms are defined in this document to control
access to access control information or for storage of
access control information at the server; this is vendor
dependent.
But the ACIs are attributes. Don't the normal access controls
described in the rest of the draft apply here?
EDITORIAL: Add reference to ACL Requirements document in last paragraph.
Page 5:
EDITORIAL:
A "subject' is an entity which initiate actions in an
^ ^^^^^^^^
information system.
The quotes on subject don't match. Also, "initiate" should be either
"may initiate" or "initiates".
TECHNICAL: How is a "role" really different from a "group" which
contains all of the subjects in the organizational position that the
role represents? In Ellen's response to Dave Chadwick's questions, she
quotes Bob Blakley's previous posting on this. Bob's posting talks
about having different semantics for combinations (union semantics vs.
intersection semantics), but the model in the draft does not seem to
allow for different merging semantics, so some of the reason to
separate roles and groups is not present.
Page 7:
EDITORIAL: Add Section number at end of last paragraph.
Page 9:
EDITORIAL:
aCIMechanisms lists the values (list of OIDs) that
defines the access control mechanism in effect for the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
scope of that subschema entry. More than one mechanism
may be in effect for the scope of that subschema entry.
Should be "define the access control mechanisms" since it explicitly notes
that there can be more than one.
EDITORIAL:
The intent of the following attribute definitions is to
design a common interchange format. Any given LDAP
server should be able to translate the below defined
attributes into a meaningful operation requests. Each
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
server should be able to understand the attributes; there
should not be any ambiguity into what any part of the
syntax means.
Should be "into meaningful operation requests" (drop the "a").
EDITORIAL: quote mismatch and add section number in second to last
paragraph.
ABNF:
TECHNICAL:
RFC 2234 gives standards for IETF ABNF, and the BNF in the draft does
not match the standards. That drove many of the changes in our
suggested replacement, the reasons for other changes are commented. We
suggest replacing the BNF with the following ABNF and including
references to RFCs 2234, 2252, and 2253:
Open issues:
1. Is the internal structure of a kerberosID really important in this
context? Can't we just leave <kerberosID> as a terminal token for
this ABNF?
2. Are the quoted strings in the ABNF (e.g. "deny", "public") meant to
be case sensitive or case insensitive? RFC2234 assumes that quoted
strings are case insensitive. If they are meant to be case
sensitive, RFC2234 requires that some really awful stuff be done to
the grammar.
<ldapACI> = <acl entry syntax>
; left angle bracket replaces pound sign since pound sign is legal in
; distinguished name per RFC 2253 DN specification and RFC 2252 attribute
; definitions (inherited from <rights>). This was chosen because it cannot
; appear in unescaped form in DNs (see 2253) or in attribute names at all
; (see 2252). Also, <subjectDn> was changed to <subjectID> since it is
; not always a DN (it might be an <ipAddress> or <kerberosID>).
<acl entry syntax> = <familyOID> "<" <scope> "<"
<rights> "<" <dnType> "<" <subjectID>
<policyOwner> = <familyOid> "<" <scope> "<" <dnType> "<" <subjectID>
; <distinguishedName> is defined in RFC 2253
<subjectID> = <distinguishedName> / "public" / "this" /
<kerberosID> / <ipAddress>
<familyOid> = <oid>
<scope> = "entry" / "subtree"
; the printableString definitions in <dnType>, <userID>, and <realm>
; need to be more specific in terms of how to handle escaping of
; characters used literally in this ABNF spec
<dnType> = "access-id" / "role" / "group" / "subtree"
/ "ipAddress" / "kerberosID" / <printableString> ;
<kerberosID> = <userID> "@" <realm>
<userID> = <printableString>
<realm> = <printableString>
; Pound symbols used below in place of semi-colon since semi-colon can
; appear in attribute name specification per RFC2252. This is really a
; nit - we admit that language and other tags are unlikely to show up
; here to cause syntax ambiguity.
<rights> = ( "grant#" <permissions> "#" <attr> )
/ ( "deny#" <permissions> "#" <attr> ) /
( "grant#" <permissions> "#deny#" <permissions> "#" <attr> )
<permissions> = [ <permission> *( "," <permission> ) ]
; printableString seems too general a syntax for collection name. The
; syntax should be restricted to make sure that delimiter characters (";"
; or "#") can't occur in the collection name. We suggest using <qdescrs>
; (defined in RFC 2252) for the attribute name since it better describes
; the allowable syntax for an attribute name. Might as well use it for
; collection name as well.
<attr> = ( "collection:" ( "[all]" / "[entry]"
/ <qdescrs> ) )
/ ( "attribute:" <qdescrs> )
<permission> = "a" / "d" / "r" / "s" / "w" /
"c" / "e" / "b"
Page 10:
EDITORIAL:
Two attributes are defined so access control information
(ACI) can be addressed in a server independent of server
implementation. These attributes are used in typical
LDAP APIs and in LDIF output of ACI. These two attributes
may be queried or set on all directory objects: ldapACI
and policyOwner. Their BNF and definitions are defined
^^^^^^^
below.
Should be "given" or "presented".
Page 12:
TECHNICAL:
e EditDN Edit an entry's DN
b BrowseDN Browse an entry's DN
How is EditDN permission different from Write permission on the naming
attribute? How is BrowseDN permission different from Search permission
on the naming attribute? Can I have EditDN permission on the entry
without explicit Write permission on the naming attribute of the
entry? What would it mean?
And do we really need both Search and Compare permissions?
Page 14:
TECHNICAL:
<attr> describes either an attribute name or an attribute
collection. The keyword attribute indicates that the
following printable string refers to an attribute name.
If the string refers to an attribute not defined in the
given server's schema, the server SHOULD report an error.
The keyword "collection" indicates that the string that
follows describes a group of attributes. The method for
^^^^^^^^^^^^^^
grouping attributes is server specific. Another option
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
for the collection printable string is "[entry]". This is ...
This seems to say that no ACI containing an attribute collection can be
portable between vendors' LDAP products. Since attribute grouping may
well be common (if you have a number of attributes that are always
treated the same way for access control) this seems to be a major
interoperability problem.
Wouldn't it be better to require that the wire protocol list all the
attributes and leave collections as a shortcut that some vendors'
products may use in their administrative interface? Note we do not
object to "[all]" and "[entry]" since they are well defined, we just
have a problem with the server specific collections.
TECHNICAL: What's the interaction between "[entry]" and attributes: if
somebody has add permission for objects but is denied permissions for
certain attributes, what happens?
Page 15:
TECHNICAL:
means that this group (Dept XYZ) is granted permission to
read and search all attributes except attr1 because attr1
is more specific than "[all]".
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What if it were two collections rather than specific attribute vs. [all]?
How do you determine which is "more specific"?
TECHNICAL:
More specific policies must override less specific ones
(e.g. individual user entry in ACI takes precedence over
^^^^
group entry).
The "e.g." makes us very nervous. There needs to be a solid definition
of what "more specific" means to avoid problems of interpretation by
different developers. Also, what would happen if a DN was a member of
two groups, where one had rights while the other did not? An example
on page 20 says to take the union of rights, but this behavior should
be specifically defined in the text, not just in an example. Are union
semantics always used for dnTypes at the same precedence?
TECHNICAL:
Deny takes precedence over Grant. When there are
conflicting ACI values, deny takes precedence over grant.
Deny is the default when there is no access control
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
information.
^^^^^^^^^^^
Does this mean that in the absence of any ACI at all, there is no
access to anything? Does it imply that there MUST be an ldapACI at the
root, since root can't inherit and without an explicit ldapACI there
will be no access at all?
Page 16:
TECHNICAL:
Precedence of Privilege Attribute dnTypes within a scope
(highest to lowest):
- ipAddress
^^^^^^^^^
- access-id, kerberosID (both same precedence)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- group
- role
- subtree
Requirement S6 of the requirements draft states:
S6. Access policy SHOULD NOT be expressed in terms of
attributes which are easily forged (e.g. IP addresses).
There may be valid reasons for enabling access based on
attributes that are easily forged and the
behavior/implications of doing that should be documented.
Isn't use of ipAddress flaunting this?
According to our reading of the definition of "access identity" in
Section 3, a Kerberos ID would BE an access identity. Why make a
distinction here?
TECHNICAL:
"deny" takes precedence over "grant", but groups have precedence over
roles. What happens if a permission is granted to a subject by virtue
of group membership but denied by virtue of role membership? What is
the precedence among precedence groupings?
Page 18:
EDITORIAL:
6.5.2 Modifying the ldapACI Values
Modify-Replace works as defined in the ldap oepration
^^^^^^^^^
modify. If the attribute value does not exist, create the
value. If the attribute does exist, replace the value. If
the ldapACI value is replaced, all ldapACI values are
replaced.
Spelling.
Page 20:
TECHNICAL:
Examples are useful and should be encouraged, but they should not be
the sole source of parts of the specification. Example #2 is the only
place we have found that says that ACI is combined when two dnTypes
have the same precendence. And the fact that the combination is by
union is not stated anywhere, though it can be inferred from the
example.
Page 21:
TECHNICAL:
We are not sure we understand the purpose of Section 7. Is it just a
set of high level examples of sequence of operations?
TECHNICAL:
- Datastore Access Control Policy Update Actions: any
operation implemented by the server which LDAP is
using as its datastore which changes the access
policy enforced with respect to attempts to access
LDAP directory entries and their attributes.
Is this meant to say that the underlying DBMS/filesystem/etc may impose
policy which overrides the policies expressed by LDAP ACIs? Or is it
meant to say that non-LDAP means (SQL for an underlying RDBMS
datastore) may change the data stored in ldapACI attributes? While
either may be true in general, is it not part of the job of the server
developer to make sure it doesn't happen? Shouldn't LDAP access
control be the way that access control policy is expressed for an LDAP
directory?
Page 25:
EDITORIAL:
dnType speficies the type of subject security attribute.
^^^^^^^^^
Defined types are specified in the BNF.
Spelling.
Page 26
TECHNICAL:
subjectDN LDAPString | "public" |
"this" | "*"
What does it mean to getEffectiveRights for "everyone who has access to
the entry" (definition of "*" on Page 25)? Return all the ACIs? All
possible subject DNs can't be known. And if all the ACIs are desired
it would be simpler to just read the ldapACI attribute.
Page 28:
TECHNICAL:
dnType "access-id"|"group"|
"role"|"ipAddress"|
"kerberosID"|
<printableString> |
"*",
^^^
subjectDN LDAPString | "public" |
"this" | "*"
^^^
What would it mean to return "*" as part of the RESPONSE to
getEffectiveRights? Isn't a separate PartialEffectiveRightsList
element needed for each dnType in the response? If "*" is part of the
query, shouldn't the various elements of the response indicate which
specific dnType they refer to rather than repeating the "*"? When
would "*" be returned? And it is even less clear what "*" means for
in the response for subjectDN.
We note that the "*" is not allowed in the
ldapGetEffectiveRightsResponse on Page 31. Was it left in
PartialEffectiveRightsList by accident?
Page 31:
TECHNICAL:
Should the security considerations section include some mention of the
special problems that might arise in a replicated environment? What
happens when new entries or attributes arrive at a replicated server
out of sequence with the arrival of associated ldapACI data?