Re: [xacml-dev] Re: [xacml-users] XACML 2.0 Conformance TestsQuestions

[Ludwig Seitz <ludwig@sics.se>]

Hi,

I took the liberty to paste together your exchange with Seth
and your answer to my mail, in order to try and clarify my point
of view on both issues in one reply.

> > > To summarize: I think it's a good idea to get all
> > > attributes resolved before request hits a PDP.
> > 
> > The problem is that this is an impossible task. In
> > all but the most
> > closed and limited systems, it's a very hard task
> > (in general) to know
> > all attributes that will be useful for a given
> > request. How do you know
> > all attributes associated with the given user? How
> > do you know what
> > policies will apply to the request, which policies
> > will be referenced
> > as part of evaluation, and therefore which attribute
> > values will be
> > needed?
> 
> I think, I know at least one person who can answer all
> these questions: this person is a policy creator. If a
> policy creator can't answer the qs about how (subject,
> action, resource) vector (SAR) is mapped to attributes
> that are required to do authorization job, then I
> would not trust much to this policy creator or to her
> policies.
> 

Well I don't agree with this statement. As I see it, this
assumes that:

a.) There is only one applicable policy per request
 (and thus the policy creator doesn't need to be aware of others)
OR
b.) There is only one policy creator per resource
 (and thus the policy creator has sole control of all policies
concerning the resource).

Both of which are very unrealistic except in 'the most
closed and limited systems'. Otherwise there is simply no
way for the policy creator to know which attributes are 
relevant (consider for example the creation of new attribute 
hierarchy relations after policy creation or attribute federation).


> > > 
> > > 2. Multiple Subjects in Request.
> > > ---------------------
> > > I think my qs was rather about understanding of
> > > concept  of multiple subjects in request than
> > about
> > > evaluating algorithm. I actually think that
> > evaluating
> > > algorithm in 7.5 doesn't match well intentions
> > > described in non-normative section 2.4. 
> > > 
> > > Let us look at example that you have: 3 subjects
> > and
> > > only one of them matches <SaubjectMatch>. Decision
> > > "Permit" means that ALL subjects are authorized to
> > > have an access to the resource (does it?). Looks
> > like
> > > a potential security breach to me, becuase I can
> > add
> > > 100 more subjects with different categories to
> > this
> > > request and they all will be granted a permission
> > to
> > > the resource too.
> > 
> > The logic behind this functionality (as far as I
> > understand) is this: 
> > If there are several subjects in the Request, they
> > are trying to 
> > perform the access _together_ (in some way). There
> > are now several 
> > options in the Policies:
> > 
> > 1.) If any of the Subjects is allowed access alone,
> > then access is
> > to be granted even if there are more Subjects
> > participating ...
> 
> I think that this is grossly wrong from security point
> of view and should be reviewed by TC. Let us assume
> that I created an initial policy for a single subject
> where authorization solution is based on
> <SubjectMatch> only, e.g. I match a domain name
> against a regular expression and if authz decision is
> “Permit” I add this domain to “trusted domain”
> database. An intruder forged a request by adding yet
> another subject with a “rogue” domain name. As a
> result, the rogue domain becomes trusted. 

I don't think the XACML standard is wrong here,
rather this seems to be a result of a erronous interpretation 
of both:

a.) The trust model of access control

If you can have untrusted PEPs in your system that can
forge requests to PDPs, then there is not much point in
having access control at all, since the PEPs job is to
enforce access control decisions (a malicious PEP could 
simply ignore the PDP and give access without bothering
forging a request in the first place).

b.) The semantics of a request with multiple subjects in 
    XACML

In your example you still interpret this request as if
all subjects where given access separately. This is not
the semantics of an XACML request with multiple subjects.
Since my previous explanations seems to have been unclear,
I hope my example later in this mail will be more understandable.

> I don’t see any practical motivation to have multiple
> subject authorization based on a single subject match
> only. If you have an example when it can be
> beneficial, please let me know. You’ll need to come up
> with a scenario when an access to resource for
> everyone must be granted based on a fact that the
> access has been granted to someone.

I will build one based on grid computing, using an XACML 
shorthand to keep the examples short:

There are three services S1,S2,S3 executing different tasks
on behalf of a user U in the grid (this is expressed in XACML 
by a subject category that I called "intermediary-agent"). 
Both S2 and S3 are used by S1 to execute subtasks. However 
due to an incorrect interface usage, S1 is calling on S3 
excessively. Since the admins of S1 have not been able to fix 
this, the admins of S3 have created a policy denying S1 access 
to S3. Otherwise the user U has access to all three services 
S1, S2, S3.

That gives us the following policies:

Policy PolicyId=S1
  Target
    Subject == U Category == access-subject
    Resource == S1
    Rule Effect=Permit

Policy PolicyId=S2
  Target
    Subject == U Category == access-subject
    Resource == S2
  Rule Effect=Permit

Policy PolicyId=S3 Rule-Combnining=DenyOverrides
  Target
    Resource == S3
  Rule Effect=Permit
    Target 
      Subject == U Category == access-subject
  Rule Effect=Deny
    Target
      Subject == S1 Category == intermediary-agent


A request from S1 to S2 would look like this:

Request
  Subject: U Category: access-subject
  Subject: S1 Category: intermediary-agent
  Resource: S2

and it would be permitted.

A request from S1 to S3 would look like this:

Request
  Subject: U Category: access-subject
  Subject: S1 Category: intermediary-agent
  Resource: S3

and it would be denied.

Thus the user U could still use the service S3, but not with S1 as
intermediary agent.


Cheers,

Ludwig Seitz

-- 
Ludwig Seitz
Ph.D., Researcher
Security, Policy and Trust Laboratory (SPOT)
Swedish Institute of Computer Science (SICS)
homepage: http://www.sics.se/~ludwig

This is a digitally signed message part