1. Validating Access Control Policies with Alloy
Waël Hassan,
Luigi Logrippo,
Mahdi Mankaï
Université du Québec en Outaouais
University of Ottawa

2. Policies
Policies are a mechanism of growing importance for the control of systems
Among which, telecom systems
Internet telephony, web applications can be customized by the use of policies
E.g. I want my calls to be forwarded to my
Out of working hours
If they come from domain X

3. Policies: further examples
Firewalls express policies regarding which packets should be allowed through
Access Control Languages such as XACML express high-level policies concerning who can be given access to what information and for what purpose

4. Inconsistency of policies
If we allow users to write their own policies, we must worry about potential inconsistencies
Calls from domain X should be blocked
Calls from Carl should come directly to me
In IN telephony, this was called the Feature Interaction problem

5. The practical problem
Access control policies are often complex, difficult to understand, and developed incrementally
They will be administered by lawyers, clerks, and other people who won’t be necessarily computer-literate
They must be made manageable for these people
They may allow security breaches if they are inconsistent
Semantic errors must be identified and reported

6. Flagging inconsistencies
Inconsistencies may be intentional
E.g. rule and exception
Or may be unintended errors
E.g. when user adds policies to an existing file, over a period of time
They should be flagged and brought to the attention of user

7. Project 1: Inconsistencies in XACML
OASIS standard
Access Control Language

8. What does it look like Etc, etc... <Policy PolicyId="SamplePolicy"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides">
<!-- This Policy only applies to requests on the SampleServer -->
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="
<ResourceAttributeDesignator DataType="
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"/>
</ResourceMatch>
</Resources>
<Actions>
<AnyAction/>
</Actions>
</Target>
Etc, etc...

9. Goals Validation of XACML policies Checking if policies are consistent
Facts
In a policy we can have multiple rules that generate different decisions (permit & deny)
Combining Algorithms help to get a unique response but don’t say if there are several possibilities

10. Access Control Policy Policy:
X(administrator) wants to read Y's medical record
X(23 years old) wants to modify his medical record
X(administrator and patient) wants to read his medical record
X(23 years old) wants to read his medical record
Policy:
Rule1: A person may read any medical record for which he or she is the designated patient
Rule2: A person may read any medical record for which he or she is the designated parent or guardian, and for which the patient is under 16 years of age
Rule3: An Administrator shall not be permitted to read or write medical elements of a patient record
Permit or Deny?
Deny
Not Applicable
Permit
Slide 1 (of 5)

11. Combining Algorithms How to obtain a single response with XACML
Deny-overrides
Permit-overrides
First applicable
Only-one-applicable
Deny
Permit
Indeterminate
Deny
Permit
Slide 2 (of 5)

12. Interaction in XACML Deny Permit Deny-overrides PolicySet1 PolicySet2
Permit-overrides
Permit
Policy1.1
Policy2.1
Policy2.2
Rule1.1.1
Rule1.1.2
Rule2.1.1
Rule2.1.2
Rule2.2.1
Rule2.2.2
Permit
Deny
Permit
Deny
Slide 3 (of 5)

13. Issues Is the response is the intented one?
Does access control policies meet all specifications?
XML notation is not readable by simple users
Slide 4 (of 5)

14. Use of Formal Language Alloy
Check
& Validation
Policy.xml
Alloy Spec
Object Model of context
Rules extraction
Simple predicates and assertions
Transformation
Slide 5 (of 5)

15. Alloy Results When the subject is both Administrator and patient
=> Both Permit and Deny responses

16. Results as a tree When the subject is both Administrator and patient
=> Both Permit and Deny responses

17. Process-based access control and inconsistency detection
Project 2
Process-based access control and inconsistency detection

18. Process-Based Access Control
In Role Based Access Control, access control policies are attached to enterprise roles
In Process Based Access Control, access control policies are attached to enterprise processes

19. RBAC vs PBAC
RBAC: when we allow Alex to open file F as a part of her organizational role structure, Alex will have access to file F at all times, and can use it regardless of her job function.
PBAC: If Alex was assigned file F as a part of process loan application, then the permission is only available during the sequence of operations leading to a loan application

20. Process-based inconsistency
In a company, the LoanProcessing process includes the VerifyCredit process.
However information collected for the purpose of credit verification should not be available to employees doing loan processing.
Suppose now that an employee assigned to sub-process Verify-Credit goes on vacation and delegates his rights to his manager, who is member of the process Loan-Processing.
The manager receives access to information that should be denied to her.

21. Approach Creation of an enterprise UML metamodel
Representation in Alloy
Using Alloy to check inconsistencies in the model
Addition of policies to metamodel
Using Alloy to identify inconsistency in policies (such as the one just exemplified)

22. UML Enterprise MetaModel
Process
person
Device
Policy
Attached to
Step ( Activity)
is a set of
Enterprise
Role
Has 1
Assigned to
Owns
Assumes *
1..

23. Expressing contradiction betw. Permission and Denial
abstract sig policy {
attachedTo : lone process, // a process is attached to policies
permitted: role -> process, // permits role access to a process
denied : role -> process //denies a role to a process }{
no permitted & denied }

24. Expressing Separation of Concerns
Processes which receive a permission from an AccountDeleteAP should not be permitted to AccountCreateAP
assert separateConcerns {
no (process.~(accountDeleteAP.permitted)
& process.~(accountCreateAP.permitted)) }

25. Results from Alloy

26. Conclusions Access control rules can be translated into logic notation
A model analyzer can be used to detect policy inconsistencies
Process is a natural concept for expressing some types of access control policies

27. Future Work Is Alloy the best choice?
May ‘break down’ in larger examples
Or may become very slow
Try other model analyzers or theorem provers
Some verification tasks may be done better in Prolog
Instead of translating XML-based policies into logical languages for modeling, invent a logic-based language to express policies directly, then translate it into some XML-based language
Develop further the PBAC model

28. Questions?