[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)
Hi Erik, On 19/12/2012 2:08 AM, Erik Rissanen wrote:
Thanks Steven, Ok, so the difference which I had not noticed in your proposal is that you advocate that any admin request should always start from the top,
You need to read more carefully. That was the fifth time I'd said it. > while I say that the reduction graph is formed within the nested policy
set like before, except of course that we use labeling rather than categories to differentiate between admin and access policies. By doing nested reduction graphs, there are two benefits as I see it: - You don't need hybrids. - Someone can neatly package a complete policy set with nested admin policies in full, without having to be concerned about how this might interfere with any other "top level" policies. Could you refresh my memory again as to why you want to start reduction from the top? What are the benefits?
I previously said this on the topic:
... "working out where
to put an administrative policy under the current scheme is a burden policy
writers can do without. Take the simple case where User A delegates all
rights to User D. This is a very simple administrative policy that basically
says "if the delegate is User D, then Permit". The issue is where to put it.
User A needs to place it (by copy or by reference) in every policy set where
User D will potentially be creating access policies. Furthermore, as new
policy sets are created that User D might put policies into, User A will have
to put the administrative policy in there as well. Conversely, if User A
isn't thorough or proactive in placing the administrative policy, then User D
will be limited in the rights he or she can actually exercise. Compounding
the difficulties is the fact that in the general case, because of
multi-valued attributes and augmentation of the delegate category by
a context handler, practially any untrusted policy can be authorized by any
administrative policy. It all depends on the request context. It is only
by making assumptions about certain attributes being single-valued or by
knowing about correlations between the attributes of an access subject that
we can begin to predict which untrusted policies will be authorized by
which administrative policies in the absence of any specific request context.
These are things that users shouldn't have to be concerned with when creating
administrative policies."
In the current scheme an administrative policy can only authorize an untrusted
policy that is a sibling or a sibling of an ancestor. This is a severe limitation
when the scope of an administrative policy is wider than any one of the untrusted
policies that it authorizes.
I also said this:
[ In the current scheme ] "the effect of a nested AdminPolicy depends on
where evaluation of the administrative request begins. Suppose that the nested
AdminPolicy evaluates to Deny. If the evaluation of the administrative request
started inside the AdminPolicySet, then the AdminPolicy has no effect because
it doesn't add an arc to the reduction graph. If the evaluation of the administrative
request started outside the AdminPolicySet, then the Deny result from the AdminPolicy
is combined with the results from its siblings according to the combining algorithm
of the AdminPolicySet. If that combining algorithm is deny-overrides, then the
Deny result overrides any Permit results from the siblings. That sort of
variability will make delegation hard for users to understand."
Evaluating administrative requests from the top means that the result of an
administrative policy is always combined with the results of its siblings
according to the combining algorithm of the policy set in which it is found
- with no exceptions.
And I said this:
[ In the current scheme ] "evaluation of an administrative request always starts
with the pair-wise consideration of siblings of the policy being reduced. It is
a process that is different from the normal processing of a combining algorithm
and, in fact, completely disregards the combining algorithm of the policy set
that contains the access policy and its sibling administrative policies. Starting
the evaluation of the administrative request at the top (just like an access
request) would be simpler to manage and easier for users to get their heads
around."
Regards,
Steven
Best regards, Erik On 2012-12-18 07:17, Steven Legg wrote:Hi Erik, On 18/12/2012 2:32 AM, Erik Rissanen wrote:On 2012-12-14 04:28, Steven Legg wrote:On 13/12/2012 11:36 PM, Erik Rissanen wrote: > So why do you allow for the hybrid? To overlay the administrative and access policy set hierarchies. Some folks have expressed a dislike for a complete separation.I don't see that you need hybrids even if the admin hierarchy is overlaid. Can you give an example?Suppose I want to write a bunch of admin policies that all relate to a resource with a resource-id of "printer", so I factor out the resource-id test and wrap the admin policies in an admin policy set like so: AdminPolicySet { PolicySetId: PS1 Target: resource-id="printer" AdminPolicy { PolicyId: P1 ... } AdminPolicy { PolicyId: P2 ... } } Along comes the delegate, who creates some access policies that relate to the resource with a resource-id of "printer". If the delegate factors out the resource-id test and wraps the access policies in an access policy set it looks like this: PolicySet { PolicySetId: PS2 Target: resource-id="printer" Policy { PolicyId: P3 ... } Policy { PolicyId: P4 ... } } This represents a complete separation of access and administrative policy. In my proposal I don't allow AdminPolicy in a PolicySet, or Policy in an AdminPolicySet, not because it is harmful, but because it is pointless. Recalling that I am proposing evaluating administrative requests from the top, an AdminPolicy in a PolicySet will never get evaluated because the PolicySet is not applicable to an administrative request. Likewise, a Policy in an AdminPolicySet will never get evaluated because the AdminPolicySet is not applicable to an access request. In order to take advantage of the common targets for the two policy sets above and merge them into one I need a policy set that is applicable for both access requests and administrative requests. That thing is the HybridPolicySet: HybridPolicySet { PolicySetId: PS3 Target: resource-id="printer" AdminPolicy { PolicyId: P1 ... } AdminPolicy { PolicyId: P2 ... } Policy { PolicyId: P3 ... } Policy { PolicyId: P4 ... } } Regards, Steven
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]