[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WI#9. Hierarchical resource policies: use cases and requirements
This e-mail contains a proposed set of use cases and requirements for policies applying to hierarchical resources. This is not for *requests* that ask for access to multiple nodes in a hierarchy in one request, but rather for *policies* that want to control access to multiple nodes in a hierachy using one statment. IS: Policy "Anne" can "read" any file in subdirectory /a/b IS NOT: Request Can "Anne" "read" all files under /a/b? The solution should be tested against the use cases and requirements, so please augment them if you think they are inadequate. See [Controversial] for the two parts I think may be most problematic. Use cases: a. An application uses XACML to specify its own access control policies for a hierarchical resource. I.e. XACML is the only access control mechanism relevant for decisions about this resource. b. An application runs under an OS identity that gives it full access to a given directory subtree in a UNIX file system. The application uses XACML to specify its own access control policies for that subtree. I.e. XACML is a secondary access control mechanism for decisions about this resource: it is being used by a specific application to control access to its portion of the hierarchy. This will be a typical case for file system accesses. [Controversial] In neither case is the XACML PDP coordinating its policies with an externally specified, non-XACML policy. For example, the XACML PDP neither overrides existing file system ACLs, nor applies existing file system ACLs to XACML resource access requests. If an XACML Request asks for access to a file to which the PEP application does not have file system ACL permission, then access will fail even if the XACML policy returns a result of "permit". It is up to the application and the policy issuer to agree on which portion of the hierarchy and which set of actions are controlled by XACML. In both cases, the policy issuer does not want to spell out separate, complete policies for each node in the hierarchy. Instead, the issuer wishes to apply specific policies to all sub-nodes or ancestors of a given node with a single statement. There may also be policies that apply to specific nodes. The types of statements that need to be supported in XACML policies are as follows: a. Subjects having certain attributes can perform actions on specific nodes in the hierarchy. Example: "Anne" can "read" file /a/b/c. b. Same as a., but for specific subtrees in the hierarchy. Example: "Anne" can "read" any file in the directory subtree /a/b/c. That is, "Anne" can "read" /a/b/c, /a/b/c/d, /a/b/c/e, /a/b/c/d/f, etc. c. Same as a., but for ancestors of a given node in the hierarchy. Example: "Anne" can "read" nodes /a, /a/b, and /a/b/c, but not /a/b/c/d. d. Subjects having certain attributes can perform actions on specific nodes in the hierarchy, and then only if the node itself has certain attributes. Example: "Anne" can "read" file /a/b/c if the "owner" attribute for /a/b/c is "Anne". Example: Subject can "read" file /a/b/c if the "owner" attribute for /a/b/c equals the Request Subject's "subject-id" attribute. e. Same as d., but for specific subtrees in the hierarchy. f. Same as d., but for ancestors of a given node in the hierarchy. g. Subjects having certain attributes can perform actions on any node in the hierarchy so long as the node itself has certain attributes. Example: Subject can "read" any file in hierarchy /a if the "owner" attribute for the requested file equals the Request Subject's "subject-id" attribute. [Controversial] The following types of statements are not directly supported: h. Subjects having certain attributes can perform actions on a given node in the hierarchy only if the same subject can perform the same action on any ancestor of the given node. Example: "Anne" can "read" /a/b/c only if "Anne" can "read" /a, /a/b, and /a/b/c separately. i. Subjects having certain attributes can perform actions on a given node in the hierarchy only if the same subject can perform some other action on any ancestor of the given node. Example: "Anne" can "read" /a/b/c only if "Anne" can "execute" /a and /b. j. Subjects having certain attributes can perform actions on any node in the hierarchy only if the same subject can perform some other action on any ancestor of the requested node. Example: A subject can "read" any node in hierarchy /a only if the same subject can "execute" any ancestor of the requested node. Why not? The only specific use case we have for these types of statements is the UFS "execute" permission, which is actually much more limited than these 3 types of statements. The "execute" semantics in UFS are a way to limit access below a certain node in a hierarchy to certain users or groups. This limit overrides any other permissions granted to other users and groups on lower levels in the hierarchy. XACML has an alternative. Assuming XACML is able to handle statements of forms a. - g. above, then XACML can express the "execute" semantics using a "deny-overrides" policy that includes the following Rule: <Policy PolicyCombiningAlg="deny-overrides"> <Rule Effect="Deny"> <Condition Function="and" <Apply Function="not"> Subject == identities who are permitted to access subdirectory </Apply> <Apply Function="resource-is-descendant-of"> Directory to be protected </Apply> </Condition> </Rule> .... </Policy> [The function "resource-is-a-descendant-of" is just an example of the type of semantics needed to support statements a-g above, but is not necessarily the function XACML will use.] Anne -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]