XACML: Consistency analysis

1
XACMLConsistency analysis

• Luigi Logrippo
• Université du Québec
• University of Ottawa
• luigi_at_uqo.ca

2
XACML

• A language to specify access control constraints
  to computing resources
• To files, equipment, web services
• OASIS standard

3
Applications

• Access control is becoming very important in the
  presence of strict accessibility and privacy laws
• And the possibility of remote access via web
  services
• Example in a hospital
• Statistician can access files for reading patient
  data, but not names
• Physician can access for read/write most info for
  her patients
• But not billing info
• Patient can read selected information on her
  record
• Accountant can etc. etc.

4
Example of XACML Rule
ltRule RuleId"Rule1" Effect"Permit"gt ltDescripti
ongt A professor can perform any action on the
file of the course she teaches lt/Descriptiongt ltT
argetgt ltSubjectsgt ltSubjectgt ltSubje
ctMatch MatchId"string-equal"gt ltAttributeVa
lue DataType"string"gt Professor
lt/AttributeValuegt ltSubjectAttributeDesignato
r AttributeId"Role" DataType"string"/gt lt/Su
bjectMatchgt
lt/Subjectgt lt/Subjectsgt ltResourcesgtltAnyReso
urce/gtlt/Resourcesgt ltActionsgt ltAnyAction/gt
lt/Actionsgt lt/Targetgt ltconditiongt ltApply
FunctionId"functionstring-is-in"gt ltApply
FunctionId"functionstring-one-and-only"gt lt
ResourceAttributeDesignator AttributeId"courses"
Datatype"string"/gt lt/Applygt ltSubjectAtt
ributeDesignator AttributeId"taught_courses"
Datatype"string"/gt lt/Applygt lt/conditiongt lt/
Rulegt
5
XACML architecture (from the standard)
Policy Enforcement Point
Policy Decision Point
Policy Information Point
Policy Application Point
6
XACML structure

• Policy sets include sets of
• Policies which are sets of
• Rules
• We will consider here only rules
• Without policy sets or policies

7
Goals

• Study different relationships between rules and
  policies
• Determine the impact of these relationships,
  leading to possible inconsistencies
• Inconsistencies can lead to privacy breaches
• Or system malfunctions
• Resolution of inconsistencies, in view of the
  relationships
• Focus on XACML, but trying to generalize

8
Rule structure in XACML

• Condition
• A condition is a Boolean function. If the
  Condition evaluates to true, then the Rule's
  Effect (Permit or Deny) is returned. If the
  Condition evaluates to false, the Condition
  doesn't apply (NotApplicable). Evaluation of a
  Condition can also result in an error
  (Indeterminate).
• Target
• A Target is essentially a set of simplified
  conditions for the Subject, Resource and Action
  that must be met for a PolicySet, Policy or Rule
  to apply to a given request.
• We will discuss mostly targets

9
Targets

• A target associates a request for resource to an
  applicable Policy Set, Policy, or Rule
• It expresses simple conditions that the request
  must meet for the Policy Set, Policy, or Rule to
  be applicable
• Does the request come from a doctor who wants
  to read her patients file? If so, permit
• Each Rule, Policy, Policy set, can return with
  any of
• Permit
• Deny
• Not Applicable
• Indeterminate (essentially, an error to be solved
  at the user level)

10
Possible relationships between targets

• Disjunction
• Non-empty intersection
• Inclusion
• Equality

• Of
• Subjects
• Resources
• Actions

11
Disjunction

• There is disjunction between targets if subjects,
  resources, and actions are all distinct
• Disjunction between the targets of two policy
  sets, policies, or rules means that
• there is no case in which both are applicable
• OK, then

12
Non-empty Intersection

• There is nonempty intersection between two
  targets if
• The set of subjects intersect and
• The set of resources intersect and
• The set of actions intersect
• Example
• (deny) (Executives) (databases A, B, C) (action
  read, write)
• (accept) (Employees) (database B, D) (action
  write)
• Executives, being employees, have conflicting
  write rights on B

13
Inclusion of target T1 in target T2(special case
of nonempty intersection)

• There is inclusion between two targets if
• The set of subjects of T1 is included in the set
  of subjects of T2 and
• The set of resources of T1 is included in the set
  of resources of T2 and
• The set of actions of T1 is included in the set
  of actions of T2
• Example
• (accept) (executives) (databases B) (action
  write)
• (deny) (employees) (database A,B,C) (any action)

14
Equality(special case of nonempty intersection)

• Subjects, target, action are all the same
• Almost certainly, an error

15
Other cases?

• Is it useful to consider other cases? E.g.
• The set of subjects of T1 is included in the set
  of cases of T2
• But the set of actions of T2 is included in the
  set of actions of T1
• Possibly, for diagnostics to user

16
Resolution in XACML

• PDP, Policy Decision Point, takes the decision
  for a specific request
• Contrary to firewalls, all rules are evaluated
• If all rules agree, they provide a decision
• In case of nonempty intersection (which is
  implied by inclusion or equality), more than one
  rule is applicable

17
Combining algorithms

• In XACML, the user can provide to PDP
• Rule Combining Algorithms (to decide
  disagreements of rules within a Policy).
• Policy Combining Algorithms (to decide
  disagreements of policies within a Policy Set)

18
Four standard rule combining algorithms are
predefined

• Permit override if there is a permit, the final
  decision is a permit, even if there are denials
• Deny override the converse
• First applicable (as for firewalls)
• Only-one-applicable if different rules or
  policies lead to different conclusions, then the
  result is indeterminate (error)
• Presupposes the existence of an external instance
  which takes a decision
• Other rule combining algorithms can be defined by
  user

19
User Interfaces for policy creation

• Ideally, policies should be created and modified
  directly by privacy specialists
• Often people with limited computing expertise
• These people should be able to
• Enter policies by clicking on boxes
• Or in English-like language
• Obtain diagnostics in clear
• Exercise different cases
• What will happen if Joe wants to write on file X?
• Need of appropriate GUIs

20
Decisions and user intentions

• Since systems can have many rules, the existence
  of different rules for the same cases indicates
  the possibility of user error
• Some user intention which is not properly
  represented
• This is particularly obvious in the case of
  target/condition equality
• If there are two rules that apply exactly to the
  same cases, there is a mistake
• One of the two should be removed
• In addition, inclusions and non-empty
  intersections are suspicious

21
Difficulty of the problem

• While detecting non-empty intersections,
  inclusions or equalities is conceptually easy in
  targets
• It is slightly more difficult in conditions,
  which can be arbitrary Boolean expressions
• In the end, these both appear to be constraint
  satisfaction problems (exponential?)
• Examples we have seen have few variables, thus
  problem is still tractable
• But in the case of conditions there can be more
  variables to be considered

22
Tools for detecting intersections

• Coq, a theorem-proving tool developed at INRIA
• Alloy, a model-checker developed at MIT
• Z-Eves
• Constraint programming languages, e.g. Prolog
• Implementation in standard programming languages
  such as C is possible, but requires more work

23
Case of policies with priorities (e.g. first
applicable case of firewalls)

• Interesting situations to be identified
• Shadowing the cases of a lower priority policy
  are all included in the cases of a higher
  priority policy
• Lower priority policy is redundant
• Includes case where two rules have equal domains
• Specialization cases of a higher priority policy
  are all included (proper inclusion) in the cases
  of a lower priority policy
• This is the case of exceptions, usually OK
• But user should be informed
• Other cases of nonempty intersection betw. high
  and low prio. policies
• These cases are usually suspicious!

24
User Interface

• User should be informed of all cases where
  different outcomes are possible, independent of
  combining algorithms
• Similar to compilation errors in programming
  languages,
• User should be requested to decide whether each
  case is OK or should be corrected
• What means of correction should be provided to
  user?

25
Choices provided to user

• Remove a policy
• Disable a policy (deactivate, but leave it for
  possible future use)
• Edit Modify a policy
• Change the priorities of policies
• Add new policies, possibly exceptions
• Tolerate the conflict

26
Suggestions to user

• If Shadowing (a dead policy)
• Remove - disable one or more policies?
• Reverse priorities?
• Edit one or more policies?
• If Specialization (an exception)
• Check that exception is wanted
• If user says no then other actions are
  suggested
• Other cases
• Remove or disable one or more policies?
• Replace or edit policies for more appropriate
  ones?
• Once changes have been made, the set of policies
  must be rechecked
• Iterative process

27
XACML and beyond

• XACML goes beyond firewalls, in that it
  addresses the issue of access control at the
  enterprise level
• However research is continuing on appropriate
  access control languages in view of general or
  specific enterprise access control needs

28
Conclusions

• Strict accessibility and privacy laws will
  require increasing attention to this area
• Security can be compromised by inappropriately
  formulated access control rules
• Formal methods will allow formal auditing of
  accessibility and privacy policies, as precise as
  formal accounting of financial records!
• Tools to do this are available, but must be
  adapted