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


Hi,

below is my view on some points (negative auths
and null subjects) that have been discussed (i may have lost some
comments, there were few msgs going around).
for negative authorizations, Hal while i see your concerns i also
believe that some of them are due to the fact that you always assume
negative authorizations to go with open policy (which was true when
negative authorizations were introduced long time ago). this is only
one possible policy (that has pros and cons). you want to rule out
negative authorizations completely because of some drawbacks they have
or that they have in given cases (throwing the baby with the water).

best
-p


HAL:
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.

	If it matters in the access decision, you can distinguish the
  	cases where some values is not known vs the cases where it is
  	known and does not satisfy given conditions (reminds me of the
  	treatment of nulls in databases)

BILL:
> 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.

	true, also if the negation is to specify some exception, the
	attribute on which the negation is based may assumed to be
	known. An example is the case where you give all employees BUT
	to tempoorary_employees (subset of employees) some access. you
	can grant the positive authorization to employee and the
	negative authorization to temporary_employee. If i am  a
	temporary_employee you will know it so if the positive
	authorization applies to me (because of indirect membership)
	so does the negative

HAL:
I always assume a deterministic evaluation algorithm.

	I think we all agree on this, where by deterministic i
	consider something that given same input and same status
	produces same output

HAL:
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.

	You assume that negative authorizations imply an open world
	assumption (=traditional open policy). This is not necessarily
	the case (and it hasd not been in many of the recent work on
	access control models/systems combining negative and positive
	authorizations). Also, as another example, the work I
	presented at the meeting (EU-funded project for protecting
	european data archive) supported restrictions (which were
	essentially like negatione) whose semantics was to specify
	conditions necessary for an access (while positive
	authorizations are traditionally sufficient conditions for an
	access). While restrictions reminds of negative
	authorizations, in no way was the policy of the system ever
	open. Negations provided in the context more protection.

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

	i will look into it and responde.

HAL:
> > Later I realized the answer. Positive policies fail closed, negative
> > policies fail open.

	again, not necessarily. It depends on the semantics that you
	give to negative and positive authorizations. For instance, if
	your mechanism says that access is allowed if 1) you have
	positive authorizations and 2) in addition you do not have
	negation; negative authroizations operate CLOSED in the domain
	stated by your positive authorizations.

HAL:
> > If new resources are added (for example) and
> > ......

	Yes, this is the usual drawback about open policies.



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

	Agree, this is the semantics that you associate with the rules,
	again, while Hal seems to always consider an open policy when
	negative authorizations are applied, it need not to be the
	case.

HAL:
There is a somewhat arbitrary choice of which inputs to apply to each phase.
However, since resources are distributed and control is federated it makes
sense to organize them by the resources they apply to, so that they can be
located physically close to the resources and their administrators. This
suggests that resource and closely related items such as action must always
be specified, so it is possible to determine which policies apply.

Privilege is something I consider to be completely synthetic and may not
necessarily even be present in a policy model at all. For example, the
AssureAccess policy model does not currently contain the notion. We map to
resources and actions. Privilege, as it is typically used, is actually a
target aggregator, in the same way group is a subject aggregator. A
priviledge is a shorthand name for some collection of resources and methods
that are considered to be similar from an access control perspective.

	I am not sure i understand these couple of paragraphs.

HAL:
policy did not consider any information about a subject, there was no need
for a subject in the policy. For example, if the policy says the resource
can be accessed between 24:00 and 6:00, there is no need to specify a
subject.

I now believe that this is illogical. I assume that policies can take as
inputs items such as the date and time, network location, method of
authentication and so on. Therefore, if a policy that does not consider
subject information must contain "all subjects" then logically a policy that

does not consider time must contain "all times", a policy that does not
consider location must contain "all locations" and so on.

	i think i can agree with you on this. although it seems that
	whether you call it null or * it's more a matter of
	terminology. I would be careful with calling it null (null,
	database field teaches us, may have different semantics and
	brings consequent confusion). It is true that you can treat
	that field as ``i do not care'' (which i believe people will
	not call null), meaning whatever value it has my constraint
	applies'' (note that this may not be true in case of null
	value - again, look at the database management field and the
	treatment of null values).

TIM:
If a parameter is not included in the policy statement, then it does not
have to be considered in the policy evaluation.

	i can go with that (see my comment above), it's the use of use
	of the term/value ''null'' that worried me. Hal has
        specified the semantics in this context only now and it has
        the semantics of ANY VALUE.




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


Powered by eList eXpress LLC