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


Agreed

-----Original Message-----
From: Platt, Darren [mailto:dplatt@securant.com]
Sent: Tuesday, May 15, 2001 12:09 PM
To: 'Simon Y. Blackwell'; 'security-services@lists.oasis-open.org'
Subject: RE: Resource sets and resource string semantics


I don't think we can count on the fact that a webserver administrator will
be able to group resources into directories for the purpose of optimizing
our protocol.  While administrators often do this kind of grouping for
convenience, it is not something that is always possible - there are many
other factors that impact the setup of a website's filesystem.  For example,
a particular application may consist of graphics, html files, CGI programs,
servlets/jsps/asps, and media files.  These resources will likely be served
from many different directories - some from different servers.  They will
also be maintained and administered by different people and roles.  To base
an optimization (which is what I believe this discussion of wildcarding to
be) on this type of filesystem configuration will therefore be limited.

I do see the need for these types of optimizations, and believe we should be
clear not to preclude them.  I don't think we should hard code them into our
design however. 

Darren



> -----Original Message-----
> From: Simon Y. Blackwell [mailto:sblackwell@psoom.com]
> Sent: Thursday, May 10, 2001 8:32 AM
> To: 'security-services@lists.oasis-open.org'
> Subject: RE: Resource sets and resource string semantics
> 
> 
> Not to be blatantly diagreeable, but every web server I have ever
> administered grouped files by function. It happened that 
> function generally
> coincided with security settings, but not always. The issue 
> being, which is
> easier to do manage security differences in a group of files 
> or manage and
> develop code that references file locations which don't correspond to
> application function. Although it brings up some other issues, the old
> Apollo OS handled this pretty well with symbolic links and 
> access control on
> the links.
> 
> -----Original Message-----
> From: Philip Hallam-Baker [mailto:pbaker@verisign.com]
> Sent: Monday, May 07, 2001 1:59 PM
> To: 'Hal Lockhart'; Philip Hallam-Baker; 'Edwards, Nigel';
> security-services@lists.oasis-open.org
> Subject: RE: Resource sets and resource string semantics
> 
> 
> I entirely disagree with the statements made by Hal. 
> 
> First every Web server I have ever administered has grouped documents
> together on the basis of access rights. I don't think it is 
> unusual for this
> to take place. I think it is the overwhelming norm.
> 
> The same was true when I built database systems and ran large 
> VMS systems, I
> would group files into directories by function and by access 
> permissions. In
> most cases the two went together.
> 
> Second who said anything about the PDP volunteering information? 
> 
> PEP: Can Alice access http://www.hp.com/finance/fred.xls 
> 	[And what neighboring files can Alice access]
> PDP: Yes, and Alice can access http://www.hp.com/*
> 
> To get a wildcard response the client should affirmatively request it:
> 
> <Respond>
>     <string>Decision 
>     <string>Assertion
>     <string>ResourceWildcard
> 
> I don't think that the use case raised by HP was rare or 
> unusual in the
> slightest. It is the most commonplace type of operational 
> optimization an
> O/S level PEP is likely to perform.
> 
> The counter-example is VMS where the lack of a means of 
> saying 'everything
> in this directory and descendents  has these permissions' led 
> to some pretty
> wierd ACL propagation rules which were a nightmare.
> 
> In fact since many Web protocols specify a default resource, 
> having a means
> of distinguishing the directory permissions from permissions 
> on the default
> resource is likely to be essential.
> 
> 
> I think it is much better that the standard propose a means 
> of optimizing
> the PEP-PDP conversation rather than have multiple ad-hoc optimization
> schemes develop.
> 
> I do not see an interoperability problem here:
> 
> 	1) A Client that does not support Resource Wildcard 
> never specifies
> it in a request
> 	2) A server that does not support Resource wildcard on 
> part or all
> of the database simply ignores the Respond keyword and does 
> not generate a
> wildcard resource in the response.
> 
> 
> 		Phill
> 
> Phillip Hallam-Baker FBCS C.Eng.
> Principal Scientist
> VeriSign Inc.
> pbaker@verisign.com
> 781 245 6996 x227
> 
> 
> > -----Original Message-----
> > From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> > Sent: Monday, May 07, 2001 4:47 PM
> > To: 'Philip Hallam-Baker'; 'Edwards, Nigel'; Hal Lockhart;
> > security-services@lists.oasis-open.org
> > Subject: RE: Resource sets and resource string semantics
> > 
> > 
> > I think before we discuss HOW to do this sort of thing we 
> > should discuss
> > whether it desirable.
> > 
> > > 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 feel very uncomfortable about the PDP volunteering 
> > information it has not
> > been asked for. It seems to add various kinds of risks without clear
> > benefit.
> > 
> > > 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.
> > 
> > Our experience has been that this is not the case. Names are 
> > chosen for
> > reasons other that access patterns. A naming scheme which 
> > works for one
> > category of user does not fit another. 
> > 
> > This would seem to me to optimize a rather rare situation, 
> > while adding
> > various risks.
> > 
> > Hal
> > 
> 
> 
> ------------------------------------------------------------------
> 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