OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [Fwd: failure notice]

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">

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 +
<title>+ file</title>
hello world

or, moving to another hierarchical resource that we all know and love:


(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="*">

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).



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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]