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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


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



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


Powered by eList eXpress LLC