[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]