Access Control Models

SIO

André Zúquete
Access types
• Physical access
ꟷ Physical contact between a subject and the object of interest
• Facility, room, network, computer, storage device, authentication token, etc.
ꟷ Out of scope of this course …

• Informatic or electronic access

ꟷ Information-oriented contact between a subject and the object of interest
• Contact through request-response dialogs
ꟷ Contact is mediated by
• Computers and networks
• Operating systems, applications, middleware, devices, etc.

João Paulo Barraca, André Zúquete SIO 2

Access control policies

Access Control Monitor

Subject or Object
Reference Monitor

• Definition log

ꟷ Policies and mechanisms that mediate the access of a subject to an object

• Normal requirements
ꟷ Authentication
• With some Level of Assurance (LoA)
ꟷ Authorization policies AAA
ꟷ Accountability → logging
João Paulo Barraca, André Zúquete SIO 3
Access control: Subjects and Objects
• Both are digital entities
• Subjects are something exhibiting activity:
ꟷ Processes
ꟷ Computers • Objects are targets of actions (resources):
ꟷ Network elements ꟷ Stored data
ꟷ CPU time
ꟷ Memory
ꟷ Processes
ꟷ Computers
ꟷ Networks
• An entity can be both subject & object
João Paulo Barraca, André Zúquete SIO 4
Least privilege principle
“Every program and every user of the system should operate using the least set of privileges necessary to
complete the job”
J. H. Saltzer, M. D. Schroeder, Proc. of The protection of information in computer systems, IEEE, 63(9) 1975

• Privilege:
ꟷ Authorization to perform a given task
ꟷ Similar to access control clearance

• Subjects should have, at any time, the exact privileges required to their assigned tasks
ꟷ Less privileges than the required create unsurpassable barriers
ꟷ More privileges than the required create vulnerabilities
• Damage resulting from accidents or errors
• Potential interactions among privileged programs
• Misuse of a privileges
• Unwanted information flows
• "need-to-know" military restrictions

João Paulo Barraca, André Zúquete SIO 5

Access control models
• Access control matrix
ꟷ Matrix with all access rights for subjects relatively to objects
ꟷ Conceptual organization

João Paulo Barraca, André Zúquete SIO 6

 O1 O2 … Om-1 Om
Access control models
S1 Access
rights
S2

• ACL-based mechanisms …
ꟷ ACL: Access Control List Sn-1
ꟷ Matrix column Sn

• List of access rights for specific subjects

ꟷ Access rights can be positive or negative
ꟷ Default subjects may often be used

• Usually, ACLs are stored along with objects

ꟷ e.g., for file system objects

João Paulo Barraca, André Zúquete SIO 7

 O1 O2 … Om-1 Om
Access control models
S1 Access
rights
S2
• Capability-based mechanisms …
ꟷ Capability: unforgeable authorization token Sn-1
ꟷ Matrix row
Sn
ꟷ Contains object references and access rights

• Access granting
ꟷ Transmission of capabilities between subjects
ꟷ Mediated / non-mediated

• Usually, capabilities are kept by subjects

ꟷ e.g., OAuth 2.0 access tokens
João Paulo Barraca, André Zúquete SIO 8
Access control models: MAC and DAC

• Mandatory access control (MAC)

ꟷ Fixed access control policy implemented by the access control monitor
ꟷ Access control rights cannot be tailored by subjects or object owners

• Discretionary access control (DAC)

ꟷ Some subjects can update rights granted or denied to other subjects for a given object
ꟷ Usually this is granted to object owners and system administrators

João Paulo Barraca, André Zúquete SIO 9

Access control models: Role-Based Access Control (RBAC)
D.F. Ferraiolo and D.R. Kuhn, "Role Based Access Control“,
15th National Computer Security Conference, Baltimore, Oct. 1992
• Not DAC or MAC
ꟷ Roles are dynamically assigned to subjects
ꟷ For access control what matters is the role played by the subject
• And not the subject’s identity
• Identity is mostly relevant for role access and logging

• Access control binds roles to (meaningful) operations

ꟷ Operations are complex, meaningful system transactions
• Not the ordinary, low-level read/write/execute actions on individual objects
ꟷ Operations can involve many individual, lower-level objects
João Paulo Barraca, André Zúquete SIO 10
Access control models: RBAC role assignment

• All subject activity on the system is conducted through

transactions
ꟷ And transactions are allowed to specific roles
ꟷ Thus, all active subjects are required to have some active role

• A subject can execute a transaction iff it has selected or

been assigned a role which can use the transaction

João Paulo Barraca, André Zúquete SIO 11

Access control models: RBAC role authorization

• A subject's active role must be authorized for the subject

ꟷ In that case, the subject may assume the role

• Transaction authorization:
ꟷ A subject can execute a transaction iff
• the transaction is authorized through the subject's role memberships
ꟷ and
• there are no other constraints that may be applied across subjects, roles, and
permissions

João Paulo Barraca, André Zúquete SIO 12

RBAC rules

[3] 3 - Transaction
1 - Role authorization
assignment

2 - Role
authorization

[1] [2]
Transaction execution request
(on behalf of a given role)

[1] From http://www.clker.com/clipart-24011.html

[2] From http://www.123rf.com/photo_12115593_three-dimensional-colored-toothed-wheels.html
[3] From http://www1.yorksolutions.net/Portals/115255/images/MyRoleIs.jpg

João Paulo Barraca, André Zúquete SIO 13

RBAC variants RBAC 3

• RBAC 0
ꟷ No role hierarchies RBAC 1 RBAC 2
ꟷ No role constraints

• RBAC 1 RBAC 0
ꟷ RBAC 0 w/ role hierarchies (privilege inheritance)

• RBAC 2
ꟷ RBAC 0 w/ role constraints (separation of duties)

• RBAC 3
ꟷ RBAC 1 + RBAC 2

João Paulo Barraca, André Zúquete SIO 14

NIST RBAC model
• Flat RBAC User-role review
ꟷ Simple RBAC model w/ user-role review Which users can have a role?
?
Role ՜ users
• Hierarchical RBAC Which roles can a user have?
?
ꟷ Flat RBAC w/ role hierarchies (DAG or tree) User ՜ roles
ꟷ General and restricted hierarchies

• Constraint RBAC Permission-role review

ꟷ RBAC w/ role constraints for separation of duty Which permissions has a role?
?
Role ՜ permissions
• Symmetric RBAC Which roles have a permission?
?
ꟷ RBAC w/ permission-role review Permission ՜ roles

João Paulo Barraca, André Zúquete SIO 15

Access control models: Context-Based Access Control (CBAC)
• Access rights have an historical context
ꟷ The access rights cannot be determined without reasoning about past access
operations

• Example: Stateful packet filter firewall

D.F.C. Brewer and M.J. Nash,

• Example: Chines Wall policy "The Chinese Wall Security Policy “,
ꟷ Conflict groups IEEE Symposium on Security and Privacy, 1989
ꟷ Access control policies need to address past accesses to objects from members of
conflict groups
João Paulo Barraca, André Zúquete SIO 16
Access control models: Attribute-Based Access Control (ABAC)
• Access control decisions are made based on attributes associated
with relevant entities
• OASIS XACML architecture
ꟷ Policy Administration Point (PAP)
• Where policies are managed
ꟷ Policy Decision Point (PDP)
• Where authorization decisions are evaluated and issued
ꟷ Policy Enforcement Point (PEP)
• Where resource access requests are intercepted and confronted with PDP’s decisions
ꟷ Policy Information Point (PIP)
• Where the PDP gets external information

João Paulo Barraca, André Zúquete SIO 17

XACML big picture

João Paulo Barraca, André Zúquete SIO 18

XACML: Access control with PEP and PDP
• A subject sends a request
ꟷ Which is intercepted by the Policy Enforcement Point (PEP)

• The PEP sends an authorization request to the Policy Decision Point (PDP)
ꟷ With some subject’s attributes

• The PDP evaluates the authorization request against its policies and reaches
a decision
ꟷ Which is returned to the PEP

ꟷ Policies are retrieved from a Policy Retrieval Point (PRP)

ꟷ Useful attributes are fetched from Policy Information Points (PIP)
ꟷ Policies are managed by the Policy Administration Point (PAP)

João Paulo Barraca, André Zúquete SIO 19

Access control models: Break-the-glass

• In some scenarios it may be required to overcome the established

access limitations
ꟷ e.g., in a life-threatening situation

• In those cases, the subject may be presented with a break-the-

glass decision upon a deny
ꟷ Can overcome the deny at their own responsibility
ꟷ Logging is fundamental to prevent abuses

João Paulo Barraca, André Zúquete SIO 20

Separation of Duties
R.A. Botha, J.H.P. Eloff, “Separation of duties for access control
enforcement in workflow environments”, IBM Systems Journal, 2001
• Fundamental security requirement for fraud and error prevention
ꟷ Dissemination of tasks and associated privileges for a specific business process among
multiple subjects
ꟷ Often implemented with RBAC

• Damage control
ꟷ Segregation of duties helps reducing the potential damage from the actions of one
person
ꟷ Some duties should not be combined into one position

João Paulo Barraca, André Zúquete SIO 21

Segregation of duties
ISACA (Inf. Systems Audit and Control Ass.) matrix guideline

João Paulo Barraca, André Zúquete SIO 22

Information flow models
• Authorization is applied to data flows
ꟷ Considering the data flow source and destination
ꟷ Goal: avoid unwanted/dangerous information flows

SL? SL?
data flow
src dst

• Src and Dst security-level attributes

ꟷ Information flows should occur only between entities with given security level (SL)
attributes
ꟷ Authorization is given based on the SL attributes

João Paulo Barraca, André Zúquete SIO 23

Multilevel security
• Subjects (or roles) act on different security levels
ꟷ Levels do not intersect themselves
ꟷ Levels have some partial order
• Hierarchy
• Lattice

• Levels are used as attributes of subjects and objects

ꟷ Subjects: security level clearance
ꟷ Objects: security classification

• Information flows & security levels

ꟷ Same security level → authorized
• Still, restricted to a “need to know”
ꟷ Different security levels → controlled

João Paulo Barraca, André Zúquete SIO 24

MS levels: Military / Intelligence organizations
U
• Typical levels R
• EU example
ꟷ Top secret ꟷ EU TOP SECRET
C
ꟷ Secret S sensivity ꟷ EU SECRET
ꟷ Confidential TS ꟷ EU CONFIDENTIAL
ꟷ Restricted grows ꟷ EU RESTRICTED
ꟷ Unclassified ꟷ EU COUNCIL / COMMISSION

• Portugal (NTE01, NTE04) • NATO example

ꟷ Muito Secreto ꟷ COSMIC TOP SECRET (CTS)
ꟷ Secreto ꟷ NATO SECRET (NS)
ꟷ Confidencial ꟷ NATO CONFIDENTIAL (NC)
ꟷ Reservado ꟷ NATO RESTRICTED (NR)
João Paulo Barraca, André Zúquete SIO 25
Security categories (or compartments) Top Secret

C1
• Self-contained information environments Secret
ꟷ May span several security levels
C2

Confidential
• Military environments
ꟷ Military branches, military units
C3 Restricted

• Civil environments
Unclassified
ꟷ Departments, organizational units

• An object can belong to different compartments and have a

different security classification in each of them
ꟷ (top-secret, crypto), (secret, weapon)

João Paulo Barraca, André Zúquete SIO 26

Security labels
• Label = Category + Level Lv2, C2 Lb2

• Relative order between labels

ꟷ Lb1 ≤ Lb2  C1  C2  Lv1 ≤ Lv2
Lv1, C1 Lb1
• Labels form a lattice
TS, all
TS, C1 TS, C2
S, all
S, C1 S, C2
C, all
C, C1 C, C2

U, all
João Paulo Barraca, André Zúquete SIO 27
Bell-La Padula MLS Model
D. Elliott Bell, Leonard J. La Padula, "Secure Computer Systems:
Mathematical Foundations”, MITRE Tech. Report 2547, Vol. I, 1973
• Access control policy for controlling information flows
ꟷ Addresses data confidentiality and access to classified information
ꟷ Addresses disclosure of classified information
• Object access control is not enough
• One needs to restrict the flow of information from a source to authorized destinations

• Combines access control matrixes with MLS

João Paulo Barraca, André Zúquete SIO 28

Bell-La Padula MLS Model: secure state transitions O5
• Simple security condition (no read up) W
W
ꟷ S can read O iff L(S)  L(O) O4 SB
R
R
• *-property (no write down)
ꟷ S can write O iff L(S) ≤ L(O) O3
ꟷ aka confinement property W
W
• Discretionary Security Property O2
R
SA
ꟷ DAC-based access control within the same security level R

O1

João Paulo Barraca, André Zúquete SIO 29

Biba Integrity Model
K. J. Biba, "Integrity Considerations for Secure Computer Systems", MITRE
Technical Report 3153, The Mitre Corporation, April 1977

• Access control policy for enforcing integrity control over data flows
ꟷ Uses integrity levels, not security levels
ꟷ Similar to Bell-La Padula, with inverse rules O3

R
• Simple Integrity Property (no read down) R

ꟷ S can read O iff I(S) ≤ I(O) O2 S

W
W
• Integrity *-Property (no write up)
O1
ꟷ S can write O iff I(S)  I(O) 30

João Paulo Barraca, André Zúquete SIO 30

Windows mandatory integrity control

• Allows mandatory (priority and critical) access control

enforcement prior to evaluate DACLs
ꟷ If access is denied, DACLs are not evaluated
ꟷ If access is allowed, DACLs are evaluated

João Paulo Barraca, André Zúquete SIO 31

Windows mandatory integrity control: integrity labels
• Untrusted
• Low (or AppContainer)
• Medium
• Medium Plus
• High
• System
• Protected Process
João Paulo Barraca, André Zúquete SIO 32
Windows mandatory integrity control: users and processes

• User integrity level

ꟷ Medium: standard users
ꟷ High: elevated users

• Process integrity level

ꟷ The minimum associated to the owner and the executable file
ꟷ User processes usually are Medium or High
• Except if executing Low-labeled executables
ꟷ Service processes: High

João Paulo Barraca, André Zúquete SIO 33

Windows mandatory integrity control

• Securable objects mandatory label

ꟷ NO_WRITE_UP (default)
ꟷ NO_READ_UP
ꟷ NO_EXECUTE_UP

João Paulo Barraca, André Zúquete SIO 34