RE: Resource sets and resource string semantics

[Philip Hallam-Baker <pbaker@verisign.com>]

I believe that the problem is an operating system level one rather than a
SAML one and that inclusion or eclusion of wildcards does not affect the
issue.

If someone decides to implement a sybolic link action authorized through
then they are going to have pretty complex security considerations to get
right. To create a symbolic link one needs control priv over the target and
write priv to the name to which the link is to be made.

However that is the implementors problem, not ours.

	Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: PATO,JOE (HP-PaloAlto,ex1) [mailto:joe_pato@hp.com]
> Sent: Monday, May 07, 2001 10:06 AM
> To: 'Philip Hallam-Baker'; 'Eve L. Maler';
> security-services@lists.oasis-open.org
> Cc: EDWARDS,NIGEL (HP-UK,unix1); 'Hal Lockhart'
> 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
> > 
>

Phillip Hallam-Baker (E-mail).vcf