MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: WI#25 Proposal: Function for comparing file system pathnames
This is a proposal for XACML 2.0 Work Item#25.
25: Function for comparing file system pathnames
Define a function for specifying and comparing file system
pathnames used in resource-id. Possibly new DataType also.
MOTIVATING USE-CASE AND REQUIREMENT
One of the canonical examples for an access control policy is
"Subject S is allowed to read files in file system Directory
D." An a canonical access request is "Can S read file F?"
The current XACML Specification has no standard way to handle
such a policy: there is no standard test for whether a given
file that the user is trying to access is part of a given
directory to which the user may have been given access
permission.
One specific use case is trying to model the
java.io.FilePermission semantics using XACML. With a
FilePermission, a Subject can be granted permission to perform
an action on a file pathname. If the pathname ends in "/*"
(where "/" is actually whatever the appropriate file name
separator character is), then the Subject is granted
permission to perform the action on all the files and
directories contained in that directory. If the pathname ends
in "/-", then the Subject is granted permission to perform the
action (recursively) on all files and subdirectories contained
in that directory. A pathname consisting of the special token
"<<ALL FILES>>" matches any file.
SUMMARY OF OPEN ISSUES
1. Is such a function the correct way to handle policies that
grant or deny access to files?
2. How are file name separators to be specified?
3. How is the scope of the template name to be specified
(i.e. single file, directory and its immediate children,
directory subtree)?
4. Should a special syntax be supported to allow substition of
variable parts of the template file name to be passed as
Request Context attributes?
5. Is the matching algorithm correct? Does this satisfy
standard syntax for UNIX, Windows, and <other common> file
systems? Is the canonicalization sufficient?
PROPOSED SOLUTION
Define a new function with a FunctionId of
"urn:oasis:names:tc:xacml:1.0:function:file-path-match".
This function provides the ability to match file paths in order
to determine if one file or subdirectory matches or is in a
sub-directory of another. It emulates the
"java.io.Permission.implies()" method functionality, but may be
used with arguments that are not specific to the J2SE platform.
Note that the matching is strictly by name syntax: there is no
lookup to see if a given file or subdirectory is actually in
another directory on the platform itself.
The function takes four arguments of DataType
http://www.w3.org/2001/XMLSchema#string and returns a result of
type http://www.w3.org/2001/XMLSchema#boolean. The result of
the function is "True" if the file or path specified in the
third argument matches the fourth argument, using the file name
separator specified in the first argument and the scope
specified in the second argument; otherwise, the
result is "False".
Arguments
---------
The arguments to this function must be as follows. If any
argument fails to satisfy these requirements, then the function
evaluates to "Indeterminate".
1 - an <AttributeValue> containing the file name separator
character used in the file naming syntax (for example "/"
or "\").
2 - an <AttributeValue> describing the scope of the match.
This argument must be one of three values:
"file" - the third argument is to be interpreted as a
single file,
"directory" - the third argument is to be interpreted as a
file directory, where all files and directories
immediately under that directory match,
"subtree" - the third argument is to be interpreted as a
file directory, where all files and directory
recursively under that directory match.
3 - an <AttributeValue> containing the "template" for the
match: the file or directory name that the requested name
must match.
4 - an <AttributeDesignator> <AttributeSpecifier> indicating
the requested file or directory name that is to be compared
to the template in argument 3.
Matching Algorithm
------------------
The algorithm for matching arguments 3 and 4 is as follows:
a) Normalize the values for arguments 3 and 4:
1) Substitutions described below under "String Substitution
Syntax" are performed for Argument 3.
2) multiple sequential instances of <separator> are
collapsed into one.
3) <separator>..<separator> causes the previous name
component to be removed: e.g. "x/y/../z" becomes "x/z".
4) <separator>.</separator> is replaced with <separator>
b) If argument 3 is not a prefix of argument 4, then the result
is "false".
c) If argument 2 is "file":
- If argument 3 does not match argument 4 by string-equal,
then the result is "false". Otherwise the result is
"true".
d) If argument 2 is "directory"
- If prefix argument 3 is removed from argument 4, and the
result contains any instance of <separator>, then the
result is "false". Otherwise, the result is "true".
e) If argument 2 is "subtree", the result is "true".
The following special syntax allows for variables such as "home
directory" or "installation directory" to be used in the
template value, names, and resolved based on the environment in
which the request is evaluated:
String Substitution Syntax
--------------------------
If one or more strings of the form "${X.<urn>} occurs in
argument 3, then they each refer to the value of an Attribute
in the Request Context that is to be substituted into the
template file name prior to comparing arguments 3 and 4. "X"
must be either "Subject", "Resource", "Action", or
"Environment", and <urn> must be an XACML Attribute Identifier.
The indicated Attribute must be of type
"http://www.w3.org/2001/XMLSchema#string"; and must occur in the
Request Context as a Subject, Resource, Action, or Environment
Attribute, respectively. There can be only one instance of the
indicated Attribute in the Request Context. If any of these
conditions is not satisfied, then the result of the Function is
Indeterminate.
Example
-------
In order to specify that the requested file must be an
immediate child of the Subject's home directory on file system
"file://x.y.z", the policy would contain the following
predicate:
<Apply
FunctionId="urn:oasis:names:tc:xacml:1.0:function:file-path-match">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string";
>/</AttributeValue>
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string";
>directory</AttributeValue>
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string";
>file://x.y.z/${Subject.urn:something:names:attributes:homeDirectory}/public</AttributeValue>
<ResourceAttributeDesignator
DataType="http://www.w3.org/2001/XMLSchema#string";
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"/>
</Apply>
DETAILED SOLUTION
[Actual text and schema changes or additions, referencing line
numbers in the XACML 1.1 PDF Specification, required to
express this solution in the 2.0 specification.
This may be in the form of edits to the source XACML 1.1
Specification, attached to the e-mail containing the
Proposal.
Don't bother with this until the SUMMARY indicates there are
no issues that remain to be resolved, and there is consensus
on one PROPOSED SOLUTION above.]
--
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]