[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Resource sets and resource string semantics
Phill, Long ago in the Apollo Domain operating system, we addressed this issue by having the permissions associated with a symbolic link protect access to reading the contents of the link (the linktext). Access to the target object remained protected by the permissions associated with that object (and therefore the ability to resolve a symbolic link to a particular result required rights to both the link and the target). In practice, when emulating BSD behavior, the symbolic link was world readable so that the initial test for access was a no-op. - joe -----Original Message----- From: Philip Hallam-Baker [mailto:pbaker@verisign.com] Sent: Friday, May 04, 2001 5:32 PM To: 'Eve L. Maler'; security-services@lists.oasis-open.org Cc: 'Edwards, Nigel'; 'Hal Lockhart' Subject: RE: Resource sets and resource string semantics I agree that there are issues with the likes of symbolic links. [Which is why I don't like 'em]. In particular setting permissions at the directory level means that there is a form of attack where Alice can gain ownership of any file by creating a symbolic link to it from a directory which she has been granted the desired privs. However that is a policy issue and moreover it exists in any case since if alice has the permission to modify the file foo she can delete foo and replace it with a symlink to /usr/spool/passwrd and then access the password file thru the foo handle. What this comes down to is a great big section in the Security Considerations discussion which loosely translated reads 'symbolic links are evil'. BTW consideration of that type of issue lead me to the conclusion that the permissions bound to object approach might be relevant. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Eve L. Maler [mailto:eve.maler@east.sun.com] > Sent: Friday, May 04, 2001 3:41 PM > To: security-services@lists.oasis-open.org > Cc: 'Edwards, Nigel'; 'Hal Lockhart' > Subject: RE: Resource sets and resource string semantics > > > At 12:23 PM 5/4/01 -0700, Philip Hallam-Baker wrote: > > >All resources on the HP web site ??? > > > >How about http://www.hp.com/* > > > >or if we want to avoid any possibility of collision (although * is a > >reserved URI character): > > > >http://www.hp.com/ * > > > >Or we could use an XPATH statement - maybe Eve can fill us in??? > > XPath operates on an XML document. So unless you have some kind of > XML-encoded configuration file that specifies all the > resources available > on the HPT website, I don't think it will work. > > A domain name is a bit of a special case, in that you can > know the domain > name through which a resource was accessed, and so perhaps we > can encode > the semantic "everything retrievable from domain hp.com". > But encoding > "everything retrievable from domain hp.com in the path /foo/bar" is > trickier than it seems. At a superficial level it could work > with the > http: scheme and with some other schemes that have obvious syntactic > partioning, but deep equivalency will be impossible to measure in the > general case (soft links, redirects, case independence, > implicitly accessed > resources such as index.html...) and there are other schemes, such as > mailto:, where this breaks down. (Though mailto: is kind of > atomic, and so > perhaps not a worry.) > > >The way I would see the conversation going is: > > > >PEP: Can Alice access http://www.hp.com/finance/fred.xls > >PDP: Yes, and Alice can access http://www.hp.com/* > > > >PEP: Can Alice access http://www.hp.com/finance/mary.xls > >PEP-Cache: Yes > > > >I don't like the idea of unconstrained wildcard matching > etc. However simple > >hierarchical partitioning is probably enough for what we > need. After all the > >admin will probably organize directories so that the wildcards match > >cleanly. > > > >Note that another possibility is that the PEP is not a file > system. If the > >access control policy or permissions/whathaveyou are embedded in the > >resource the PEP may be asking a question of the form 'Does > Alice have the > >Role X' or 'Does Alice have any resources in the set ..../*' > > Eve > -- > Eve Maler +1 781 442 3190 > Sun Microsystems XML Technology Development eve.maler @ east.sun.com > > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: > security-services-request@lists.oasis-open.org >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC