RE: Resource sets and resource string semantics

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

Re HP ... Aha!

Re: "I think it is entirely appropriate to support authorization
assertions that refer to all the files in a directory sub-tree." ABSOLUTELY

Re: "I think it would be onerous to support arbitrary regular 
expression based wildcards however." ONEROUSE YES ... but does this mean
that regular expression based wild cards should not be suported in general.
Consider the case of an XML document in which we wish to apply access
controls to subcomponents of the document and the auth decision needs to be
made based on the contents of the subcomponents themselves when compared to
some attribute of the requestor. Since it would be even more onerous, and
perhaps impossible, to determine, define, and dictate beforehand the
structure of the XML files whose content is being controlled prior to
defining a policy language that can be mapped to the files, then it would
seem must support arbitrary regular expressions, at least for intrafile
access. Onces one supports it for intrafile access, I can't see a reasonable
reason not to support it for extrafile access. Granted, this could result in
very hairy and conflicting policy statements on the part of policy managers;
however, this is a user problem. It seems to regress into the old argument
that the tool (in this case SAML and XACML) is by its nature neutral;
however, if you want to kill yourslef with it you can.

I would like to keep things simple; however, if we do so at the cost of
people subsequently writing hacks to support more power and they put those
hacks into applications, then we have even more difficult security problems
to address.

-----Original Message-----
From: Phillip Hallam-Baker [mailto:pbaker@verisign.com]
Sent: Friday, May 11, 2001 8:40 AM
To: 'Simon Y. Blackwell'; '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.

And what HP were asking for was the ability to support the
equivalent of directory level controls in the case that they
were appropriate.

I think it is entirely appropriate to support authorization
assertions that refer to all the files in a directory sub-tree.

I think it would be onerous to support arbitrary regular 
expression based wildcards however.

http://www.hp.com/secret/*		YES
http://www.hp.com/secret/xyz*.htm	NO!


	Phill

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