Li Xiong

CS573 Data Privacy and Security

Access Control

What is Access Control?

Security Engineering by Ross Anderson, 2001 Its function is to control which principles

(persons, processes, machines, …) have access to which resources in the system – which files they can read, which programs they can execute, and how they share data with other principles, and so on.

Access control is pervasive OS (unix, windows), databases, Java

Night Club Example

Authentication ID Check

Access Control Over 18 - allowed in Over 21 - allowed to drink On VIP List - allowed to access VIP area

Enforcement Mechanism Walls, Doors, Locks, Bouncers

Access control and other security services Identification and Authentication – establishing and

verifying the identity of the user Something you know, such as a password or a

personal identification number (PIN). Something you have, such as a smart card or

security token. Something you are, such as fingerprint, voice,

retina, or iris characteristics. Where you are, for example on or off campus,

inside or outside a company firewall Access control determines which subject can access

what resources after identification and authentication

Access control and other security services Enforcement mechanisms Auditing – posteriori analysis of all the

requests and activities of users in the system Deterrent – users may be discouraged from

attempting violations Means to analyze users behavior to detect

possible violations

Access control and other security services

Access control

Access control mechanisms – low level software functions that can be used to implement a policy Access matrix model Implementation approaches

Access control policies – high level guidelines that determine how accesses are controlled Discretionary access control (DAC) Mandatory access control (MAC) Role based access control (RBAC) Attribute based access control (ABAC)

Access Matrix Model

A set of subjects S A set of objects O A set of rights R An access control matrix

One row for each subject One column for each subject/object Elements are right of subject on an another

subject or object

Access matrix

Implementation approaches

Access control lists (ACLs) Capabilities Authorization relation or table

Access control lists (ACLs)

Each object is associated with an ACL Storing the matrix in columns Modern OS typically take the ACL approach

Capabilities

Each subject is associated with a capability list Storing the matrix in rows

Authorization relation

Each row, or tuple, specifies one access right of a subject to an object

Relational databases typically use it

Access control

Access control mechanisms – low level software functions that can be used to implement a policy Access matrix model Implementation approaches

Access control policies – high level guidelines that determine how accesses are controlled Discretionary access control (DAC) Mandatory access control (MAC) Role based access control (RBAC)

Discretionary AC

Name AccessTom YesJohn NoCindy Yes

ApplicationAccess List

Restricts access to objects based solely on the identity of users who are trying to access them

No restrictions on information flow

Individuals Resources

database 1

database 3

database 2

Mandatory AC

Governs access based on the classification of subjects and objects Assign a security level to all information – sensitivity of

information Assign a security level to each user – security clearance Military and government: Top secret (TS) > secret (S) >

confidential (C) > unclassified (U) Access principles

Read Down – a subject’s clearance must dominate the security level of the object being read

Write Up – a subject’s clearance must be dominated by the security level of the object being written

Mandatory AC (cont)

Individuals Resources/Information

Database 1 DS

Database 3 C

Database 2 S

Write up

Read down

TS

C

S

U

Information can only flow upwards or within the same class

Role-Based AC

Governs the access based on roles Access authorizations on objects are specified for roles Users are given authorizations to adopt roles A user has access to an object based on the roles

Role-Based AC

Individuals Roles Resources

Role 1

Role 2

Role 3

Database 1

Database 3

Database 2

User’s change frequently, Roles don’t

Role-based Access Control Benefits Authorization management – assigning users to roles

and assigning access rights to roles Hierarchical roles – Inheritance of privileges based on

hierarchy of roles Least privilege – allow a user to sign on with least

privilege required for a particular task Separation of duties – no single user should be given

enough privileges Object classes – objects can be grouped based on

classifications

RBAC Reference Model (Sandhu ‘96)

RBAC0, minimum requirement RBAC1, RBAC0 + role hierarchies RBAC2, RBAC0 + constraints RBAC3, RBAC1 + RBAC2

Models Hierarchies Constraints

RBAC0 No No

RBAC1 Yes No

RBAC2 No Yes

RBAC3 Yes Yes

user_sessions session_roles

(UA)User Assign-

ment

(PA)PermissionAssignment

USERS OBSOPS

SESSIONS

ROLES

PERMISSIONS

Core RBAC System

USERS

ProcessProcess

Person

Intelligent Agent

ROLES

DeveloperBudgetManager

Help Desk Representative

A role is a job function with some associated semantics regarding responsibility and authority (permissions).

Director

MTM relation betweenUSERS & PRMS

Permissions

SQL

A permission is an approval of a particular access to one or more objects Database – Update Insert Append Delete Locks – Open Close Reports – Create View Print Applications - Read Write Execute

UA (user assignment)

SUSERSxROLEUA

A user can be assigned to one or more roles

Developer

USERS set ROLES set

Help Desk Rep

A role can be assignedto one or more users

PA (permission assignment)

PRMSROLESrspermissionassigned 2):(_ SUSERSxROLEUA

A prms can be assigned to one or more roles

Admin.DB1

PRMS set ROLES set

A role can be assignedto one or more prms

User.DB1

ViewUpdateAppend

CreateDeleteDrop

SESSIONS

Each session is a mapping of one user to possibly many roles

USER

guest

user

admin

invokes SQL

DB1.table1

FIN1.report1

APP1.desktop

SESSION

user_sessions

(RH)Role Hierarchy

session_roles

(UA)User Assign-

ment

(PA)PermissionAssignment

USERS OBSOPS

SESSIONS

ROLES

PERMISSIONS

Role Hierarchy RBAC

Tree Hierarchies

ProductionEngineer 1

Engineer 1

Quality Engineer 1

Engineering Dept

ProductionEngineer 2

Engineer 2

Quality Engineer 2

ProductionEngineer 1

Project Lead 1

Quality Engineer 1

Director

ProductionEngineer 2

Project Lead 2

Quality Engineer 2

Lattice Hierarchy

ProductionEngineer 1

Engineer 1

Quality Engineer 1

Engineering Dept

ProductionEngineer 2

Engineer 2

Quality Engineer 2

Project Lead 1

Director

Project Lead 2

user_sessions

(RH)Role Hierarchy

session_roles

(UA)User Assign-

ment

(PA)PermissionAssignment

USERS OBSOPS

SESSIONS

ROLES

PERMISSIONS

SSD

DSD

Constrained RBAC

Static mutual exclusion constraints

Two mutually exclusive roles: cannot both have the same user as members

Two mutually exclusive roles: cannot both have the same permissions

Two mutually exclusive permissions: one role cannot have both permissions

Cardinality constraints

On user-role assignment At most k users can belong to the role At least k users must belong to the role Exactly k users must belong to the role

Dynamic Constraints

At most k users can activate the same role in one session

No user is allowed to activate n or more roles in one session

Constraints with Role Hierarchies

Two roles can be mutually exclusive only if neither one inherits the other

If two roles are mutually exclusive, no roles can inherit from both

If two roles are mutually exclusive, there can be no “root” or “super users”

Separation of Duty

Constraints is a means rather than an end Separation of duty is the goal

No single user possesses all the permissions needed to accomplish a sensitive task

Permission assignment problem

Attribute based Access Control (ABAC) Access control decisions are made based on a set of

characteristics, or attributes, associated with the requestor and/or the resource

A requester provides a set of attributes, they are checked against permissible attributes E.g. a person in UltraMegaCorp tries to access an

administration interface for customer data in Atlanta must present credentials with a division attribute of “customer relations division” and a title of “senior manager” and a location attribute of “Atlanta”

No need for predefined list of roles or permissions

References

Access control: principle and practice, Sandhu, 1994

Role-based Access Control Models, Sandhu, 1996

Coming up

Hippocratic databases Fine-grained access control Policy management and enforcement