xacml message

Subject: Re: [xacml] instance of "second proposal for hierarchical resources"
From: bill parducci <bill.parducci@overxeer.com>
To: xacml <xacml@lists.oasis-open.org>
Date: Fri, 16 May 2003 07:28:45 -0700

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
  >