i am reposting this since, the previous note had the wrong subject (i
tried to post to the list with my personal account :o).
sorry about the duplication, but i don't want to screw up the thread.
b
+++
while the PDP won't have any idea if a file is pointer or source, the
PEP most assuredly will. while thinking about how and if we should
address this i began to wonder if we really want to put search semantics
in the the AttrbitueValue data (*/*/++/+)
<AttributeValue DataType="ufs-path">
file://sydney.east.sun.com/home/aa74233/++
</AttributeValue>
for example, let's look at '+' in UFS...
# ls
-rw-r--r-- 1 root root 71 May 16 06:57 +
-rw-r--r-- 1 root root 71 May 16 06:51 +.html
# cat +
<html>
<head>
<title>+ file</title>
<body>
hello world
</body>
</html>
or, moving to another hierarchical resource that we all know and love:
http://www.overxeer.com/xfr/+
http://www.overxeer.com/xfr/%2B
(the latter points out the *other* problem with 'content based'
semantics: unanticipated substitution.)
i understand that the semantics of a policy are not subject to the same
constraints as that for whatever HR (hierarchical resources) is being
protected, but will this be clear to the policy writer? i have concerns
that this may introduce security issues due to unintended consequences.
perhaps we should consider extension of the schema thus:
<AttributeValue DataType="ufs-path" DataScope="*">
file://sydney.east.sun.com/home/aa74233/
</AttributeValue>
of course, misinterpretations can happen with any improperly written
policy, but my experience is that it is MUCH easier to screw up
something if the *data* has to unambiguous, rather than the
infrastructure (which is typically handled by a UI). another upside is
that by creating an attribute a set of 'DataScopes' can be defined that
will apply to any resource (semantically, anyway).
thoughts?
b
Anne Anderson wrote:
> Bill Parducci asked about how to deal with links. I checked for
> how java.io.FilePermission handles them, and it just checks to be
> sure the "pattern" path is a prefix of the requested path -
> i.e. it is doing a syntactic check only and is never actually
> checking the file system. So links are treated just like regular
> files and directories - java.io.FilePermission never even knows
> whether the requested path exists - it just knows that it matches
> the syntactic pattern for this type of hierarchy.
>
> I think this makes sense. The PDP may not even have access to
> the hierarchical resource for which it is evaluating policy, and
> thus may not be able to check for the file type. The XACML
> Policy won't override any permissions that the file system itself
> may impose when the file is actually accessed. Some day, perhaps
> some Unix File Systems will use XACML rather than ACLs to specify
> their permissions. In that case, the Policy would be definitive,
> but for now the XACML Policy is imposed in addition to
> permissions imposed by the file system itself.
>
> I'll wait a bit for more comments, and then re-write the proposal
> to treat the match as a syntactic match of file and directory
> names rather than a subset match of actual files and directories.
>
> Anne
>