RE: Negative Policies

[Hal Lockhart <hal.lockhart@entegrity.com>]

I should have begun by saying that when I refer to negative policies, I am
actually referring to a number of different kinds of policies which have
different negative aspects. What they have in common is that they express
what is not the case rather than what is the case. Some of the problems I
have seen apply to all types of negative policies, some only apply to some
types. However because of the number of distinct types of problems I have
become wary of all types of negative policies. 

Some examples of what I consider to be negative policies:

1. under such and such conditions, the READ operation is not allowed.

2. Bill is not allowed to do such and such

3. Vice Presidents are not allowed to do such and such

4. Such and such a policy does not apply to
http://www.example.com/my/files/*

 
> two things:
> 
> 1. negative policies based upon identity live in a bounded 
> universe. it
> is not possible to change the deterministic propeties of that universe
> unless multiple entities have the same identity (a very poor
> implementation even when separated by time). this is why i suggested
> that negative policies be limited to identity and not be based upon
> attributes.

This may be true, but "identity" is an invisible abstraction. What we have
to work with is user attributes. Some attributes, such as username or Social
Security Number may be assumed to be unique for a certain security domain
(or more widely) but that does not eliminate the problem that the attributes
may have been suppressed for reasons of policy or that the proper authority
was not consulted. 

> 
> 2. from a practical standpoint, having 1 identity in 10,000 
> be prevented
> from having access to a resource requires one negative policy or 9,999
> postive policies.

As I said, I am largely convinced, but lets take that argument to the next
level. In any reasonably large scale environment we don't set policies for
individuals, we use aggregators (e.g. groups). A suitable choice of
aggegators can always eliminate the need for negative policies of this type.
The counter to this is that in a federated environment the policy
administrator may have to live with the subject aggregators specified by
others.

> ok, 3 things:
> 
> why is it mandatory for a negative policy to fail open? if by that you
> mean the rules of determination yield an undesired result, this is
> addressed above. if you are suggesting that modification of the inputs
> in an unplanned manner are not deterministic, the resulting action an
> implementation issue.

I always assume a deterministic evaluation algorithm. The sort of thing I
had in mind was like this:

1. under such and such conditions, the READ operation is not allowed.

Now somebody adds a new operation, say AUDIT, which should logically be
treated like READ. Unless somebody adds a new policy it will be allowed.

4. Such and such a policy does not apply to
http://www.example.com/my/files/*

Now somebody adds http://www.example.com/my/important_file.html which is not
covered, but should be.

Hal

> 
> b
> 
> On Wed, 2001-09-19 at 14:52, Hal Lockhart wrote:
> > At the F2F I raised the issue of negative policies. 
> Although I still believe
> > they are dangerous and should be avoided, the group has 
> largely convinced me
> > we will have to provide for them.
> > 
> > I would, however like to address one specific point. I 
> asserted that one of
> > the reasons that negative policies are bad is that sooner 
> or later, the
> > universe that negative is defined in will be changed, thus 
> changing the
> > semantics of the policy even though the policy itself has 
> not been modified.
> > 
> > Carlisle pointed out quite correctly that the same thing happens for
> > positive policies and asked why the situation is not symmetrical.
> > 
> > Later I realized the answer. Positive policies fail closed, negative
> > policies fail open. Failing closed (default deny) is 
> preferable for two
> > related reasons. First is the general security practitioner 
> paranoid view
> > that good security means that things should only be allowed 
> if explicitly
> > specified. (Cheswick and Bellovin refer to the choice 
> between this and its
> > opposite as the security "stance".)
> > 
> > The second is purely practical. If new resources are added 
> (for example) and
> > users can not get to them, the users will complain and the 
> admin will fix
> > the policy. This is a nuisance, but no big deal. 
> > 
> > If on the other hand, new resources are added and anybody 
> can get at them,
> > no one will notice, except possibly the bad guys, who are 
> unlikely to
> > complain. 
> > 
> > Hal
> > 
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
>