[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] instance of "second proposal for hierarchical resources"
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]