OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Negative Policies


On Thu, 20 Sep 2001, Hal Lockhart wrote:

> [snipped for brevity]
> 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.

I think policies such as this should never be formulated without
expilicitly defined defaults. Such as:

if P1(R) then Deny
else if P2(R) then Allow
else if P3(R) then Deny
else Deny

where R is the resource in question.

In the systems I have dealt with and implemented this kind of "negative"
policy is about the only "negative" type policy that is somewhat viable.
That is to say we do not allow "negative" predicates in these decisions
(ones constructed with the "not" operator). However, the results can be
Allow or Deny. I do not consider Deny a "negative" policy per se, but
merely the result of a deterministic policy evaluation. This one happens
to be "access control". Others may be "Audit", "Audit lightly", "Audit
heavily", "Call the president" ... you get the idea.

As for blindly taking care of adding a "new" operation, the policy
shouldn't be so niave of its domain of resources not take care of such
things.

Cheers,
-Polar

> 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>
> >
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC