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 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
> 

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