RE: Resource sets and resource string semantics

["Simon Y. Blackwell" <sblackwell@psoom.com>]

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
>