September XACML: Consistency analysis Luigi Logrippo Université du Québec University of Ottawa

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 A professor can perform any action on the file of the course she teaches Professor Example of XACML Rule

5 XACML architecture (from the standard) Policy Enforcement Point Policy Decision Point Policy Application Point Policy Information 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 patient’s 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