[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Comments on Access Control Requirements draft
My responses embedded below and prefaced by (EJS).
Ellen
At 02:39 AM 12/12/97 -0500, Richard V Huber wrote:
>I read through the Access Control Requirements draft
>(draft-stokes-ldapext-acl-reqts-00.txt) and have a number of comments.
>Since we didn't get to discuss the draft at the LDAPEXT meeting, I'm
>posting them to the list.
>
>I've copied sections 3-5 of the draft below, with my comments inserted.
>The lines that start in column 1 are my comments.
>
>Rick Huber
>
>--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
>
> G3. ACL administration SHOULD be part of the LDAP
> protocol.
>
>And ACL information SHOULD be stored in the LDAP tree and not in some
>separate database.
(EJS) I'll add requirement to say that access control information is
an LDAP attribute.
>
> G4. Object reuse protection SHOULD be provided and MUST
> NOT inhibit implementation of object reuse. Object reuse
> addresses the use of residual data. Space (memory or
> disk) may be allocated and then freed, and when that
> space is freed, precautions must be taken to ensure that
> the data that space occupied is not accessible to future
> processes using that space (reallocated) since that data
> may be sensitive and any unauthorized reuse may
> compromise the system. So, for example, before space is
> freed, it is zeroed out. Another example in the
> directory/ACL system is the re-use of DNs. Say, DN1 is
> created and then at a later date deleted. The recreation
> of DN1 (and given to a different person) must be
> protected (or in many cases recreation prohibited)
> because there may be stale ACLs that still exist and
> certainly the person given the recreation of DN1 must not
> have access to that data.
>
>Should there also be a U series requirement for a tool to help find stale
>ACL entries?
(EJS) IETF does not generally standardize tools. What I suggest is that
as part of the LDAP server deployment working group that a set of deployment
guidelines or tools be identified.
>
> 3.2 Semantics / Policy
>
> S1. Policy MUST be administrable on a per-object
> granularity.
>
>But U8 says per-attribute access control MUST be supported, which is
>finer granularity than per-object. In light of U8, is S1 needed?
(EJS) Yep, you found a conflict. I'll modify S1 to state "...per-object
or finer granularity."
>
> S5. Access SHOULD NOT be enabled on the basis of
> attributes which the directory administrator or his
> organization cannot control (e.g. groups whose membership
> is administered by another organization).
>
> S6. Access SHOULD NOT be enabled on the basis 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.
>
>S5, and S6 seem like policy recommendations rather than requirements
>for the ACL system. S4 is written as a policy statement but has a
>mechanism requirement behind it. I don't think policy recommendations
>are appropriate for this document; it should focus on requirements for
>the design of the ACL system. In the long term we will probably need a
>separate document (Security Guidelines for LDAP Administrators?) that
>would cover the policy recommendations.
>(EJS) Yep. I'll reword S5 and S6 to read "Access policy SHOULD NOT be
expressed in terms of...".
And yes, in the long term, I see the LDAP server deployment working group
adding a document governing security guidelines (once we get access control,
replication, etc into the LDAP).
> S8. Explicit denial SHOULD NOT be supported (i.e.
> negative rights). If explicit denial is supported,
> explicit "don't care" SHOULD also be supported to allow
> administrators to independently state policies they are
> competent to manage.
>
>I do not agree with this. There are times when explicit denial can
>be quite useful. Given that "override of subtree policy" is required (U7),
>one of the most useful overrides is that X, who is given administration
>rights at some high level of the tree does NOT have rights over some
>independently administered subtree. This seems to need explicit denial
>(or maybe we have different ideas of what explicit denial means). I think
>we could use some examples here to help understand the issue.
>
>Also, I'm not sure what "explicit don't care" means.
(EJS) Here's more information on explicit denial (it was posted previously
in response to an earlier set of comments):
Explicit denial example
-----------------------
Suppose the rights for an object are defined as r, w, and x, and the
defined groups are
printer_users, printer_admins, printer_operators, dept57, and dept58 with
the following
association ('grant' grants access, 'deny' denies access, and '-' is "don't
care"):
r w x
Printer_users - grant deny
Printer_admins grant grant grant
Printer_operators grant grant grant
Dept57 grant deny deny
Dept58 deny grant deny
Case: If a user in is both the printer_users and dept57 groups, then r is
granted, w is
denied, and x is denied.
Case: If r/w/x are all don't care, then there is a default permit or deny
policy that
resolves this.
Case: If r/w/x is grants & don't cares, then resolution is grant.
>
> S13. Rights management MUST have no side effects.
>
>I suspect this is here because someone sees a potential problem, but I
>can't figure out what the potential problem is. I think this needs to
>be clarified.
(EJS) Here's the proposed exapnsion (a response to a previous set of
comments):
Sorry; this text wasn't explicit enough. Here's a more explicit version; this
defines what is meant by "rights management MUST have no side effects":
Granting a subject a right to an object MUST NOT implicitly grant any other
subject the
same right to that object.
Granting a subject one right to an object MUST NOT implicity grant the same
or any other
subject a different right to the same object.
Granting a privilege attribute to one subject MUST NOT implicitly grant the
same privilege
attribute to any other subject.
Granting a privilege attribute to one subject MUST NOT implicitly grant a
different
privilege attribute to the same or any other subject.
Definition: An ACL's "scope" is defined as the set of directory objects
governed by
the policy it defines; this set of objects is a sub-tree of the directory.
Changing the policy asserted by an ACL (by changing one or more of its
entries) MUST NOT
implicitly change the policy governed by an ACL in a different scope.
>
> U5. Administrators SHOULD NOT be required to know the
> sensitivity of every attribute of every entry (dynamic
> schema makes this impossible anyway).
>
>I'm not sure what this means in practical terms. If the administrator does
>not know, who does? I assume here that the administrator is the person
>who controls the ACL of the object.
(EJS) It falls first to the developer of the schema to decide on the
sensitivity since he udnerstand best the attribute/data and not the
administrator.
The administrator should pick up his knowledge from the developer of that
schema.
>
> U14. It MUST be possible to authorize users to traverse
> directory structure even if they are not authorized to
> examine or modify some traversed entries.
>
>MUST it also be possible to PROHIBIT this? Can the tree structure be
>protected from view if that is desired by the administrator?
(EJS) Yep, I'll add/refine requirement.
>
>
> Control attributes - Attributes, associated with a
> security object that, when matched against the privilege
> attributes of a security subject, are used to grant or
> deny access to the security object.
>
> Privilege attributes - Attributes, associated with a
> security subject that, when matched against control
> attributes of a security object, are used to grant or
> deny access to that subject.
>
>The definitions of Control Attributes and Privilege Attributes could
>really use examples.
(EJS) Will do... An access control list or list of rights or time of
day range are examples of control attributes. Group/role membership
is example of privilege attributes.