Chapter 4

Access Control
 Access Control Definition
• RFC 4949 defines computer security as:

“Measures that implement and assure security services in a

computer system, particularly those that assure access control
service.”

• NIST IR 7298 defines access control as:

“a process by which use of system resources is regulated
according to a security policy and is permitted only by authorized
entities”
 Authentication vs. Authorization
• Authentication  Are you who you say you are?
– Restrictions on who (or what) can access system

• Authorization  Are you allowed to do that?

– Restrictions on actions of authenticated users

• Authorization is a form of access control

• Classic view of authorization…
– Access Control Lists (ACLs)
– Capabilities (C‐lists)

– Access Control implements a security policy that specifies who (or what in
the case of a process) may have access to each specific system resource and
the type of access that is permitted in each instance.
 Access Control Principles
• Authentication: Verification that the credentials of a user or other
system entity are valid.

• Authorization: Granting of a right or permission to a system entity to

access a system resource
o determines who is trusted for a given purpose.

• Audit: An independent review and examination of system records

and activities in order to
o test for adequacy of system controls
o ensure compliance with established policy and operational procedures
o detect breaches in security
o to recommend any indicated changes in control, policy and procedures.
 Authorization
database

Security administrator

Authentication Access control

Access
Authentication
control
function
function

User
System resources

Auditing

Figure 4.1 Relationship Among Access Control and Other Security Functions
 Access Control
• The central element of computer security.

• The principal objectives of computer security are

o to prevent unauthorized users from gaining access to
resources,

o to prevent legitimate users from accessing resources in an

unauthorized manner,

o and to enable legitimate users to access resources in an

authorized manner
 Lampson’s Access Control Matrix
 This matrix contains all of the relevant information needed by an OS to make
decisions about which users are allowed to do with the various system resources
o Subjects (users) index the rows
o Objects (resources) index the columns

Accounting Accounting Insurance Payroll

OS program data data data

Bob rx rx r  
Alice rx rx r rw rw
Sam rwx rwx r rw rw
Accounting
program rx rx rw rw rw

The model assumes a set of subjects, a set of objects, and a set of rules that
govern the access of subjects to objects.
 Access Control Policies
1) Discretionary Access 3) Role-Based Access
Control (DAC) Control (RBAC)
o Controls access based on the o Controls access based on the
identity of the requestor and on roles that users have within the
access rules (authorizations) stating system and on rules stating what
what requestors are (or are not) accesses are allowed to users in
allowed to do (the owner of the given roles
access permission can pass it to
others).

2) Mandatory Access 4) Attribute-Based Access

Control (MAC) Control (ABAC)
o Controls access based on o Controls access based on
comparing security labels with attributes of the user, the resource
security clearances (subject to be accessed, and current
clearance and object labels) environmental conditions

Note: these four policies are not mutually exclusive. An access control mechanism can
employ two or even all of these policies to cover different classes of system resources.
 Subjects, Objects, and Access Rights
The basic elements of access control are: subject, object, and access right.

Access
Subject Object
right
An entity
capable of Describes the way
A resource to in which a subject
accessing
which access may access an
objects. Held
is controlled object
accountable for
all actions

Three classes Could include:

Entity used to
• Owner contain • Read
• Group and/or • Write
• World receive • Execute
information • Delete
• Create
• Search
 Subjects & Objects
• A subject is typically held accountable for the actions
they have initiated
o an audit track may be used to record the association of a subject with
security relevant actions performed on an object by the subject.
• Owner: This may be the creator of a resource, such as a file. E.g. a project
administrator or leader may be assigned ownership.
• Group: a named group of users may also be granted access rights, E.g.
membership in the group is sufficient to exercise these access rights. a user
may belong to multiple groups.
• World: The least amount of access is granted to users who are able to
access the system but are not included in the categories owner and
group

• An object is a resource to which access is controlled.

o entity used to contain and/or receive information.
o E.g. records, blocks, pages, segments, files, portions of files, directories,
directory trees, mailboxes, messages, and programs
 Access Right
• Describes the way in which a subject may access an object
o Read: User may view information in a system resource.
• E.g. a file, selected records in a file, selected fields within a
record, or some combination).
• Read access includes the ability to copy or print.
o Write: User may add, modify, or delete data in system resource
• E.g. files, records, programs.
o Execute: User may execute specified programs.
o Delete: User may delete certain system resources, such as files
or records.
o Create: User may create new files, records, or fields.
o Search: User may list the files in a directory or otherwise search
the directory.
Discretionary Access Control (DAC)
• Traditional method of implementing access control
• Scheme in which an entity may enable another entity to access
some resource
o i.e. applied by operating system or a database management system
• Often provided using an access matrix (Lampson’s Access Control
Matrix)
o One dimension consists of identified subjects that may attempt
data access to the resources
o The other dimension lists the objects that may be accessed
• Each entry in the matrix indicates the access rights of a particular
subject for a particular object
 Simple Example of an Access Matrix

OBJECTS
File 1 File 2 File 3 File 4
Own Own
User A Read Read
Write Write
Own
SUBJECTS User B Read Read Write Read
Write

Read Own
User C Read Read
Write Write
(a) Access matrix
E.g.
• User A owns files 1 and 3 and has read and write access rights to those files.
• User B has read access rights to file 1, etc.
 Access Control Lists (ACLs)
 ACL: store Lampson's access control matrix by column
 E.g.: ACL for insurance data is in blue

 ACLs are preferable when:

o users manage their own files and
o protection is data oriented.
 With ACLs, it's also easy to change rights to a particular resource.

Accounting Accounting Insurance Payroll

OS program data data data

Bob rx rx r  
Alice rx rx r rw rw
Sam rwx rwx r rw rw
Accounting
program rx rx rw rw rw
 Capabilities (or C‐Lists)
 Store access control matrix by row
 E.g.: Capability (C‐List) for Alice is in red

 With C‐Lists, it is easy to delegate (and sub‐delegate and sub‐sub‐

delegate, and so on), and it is easier to add or delete users.

Accounting Accounting Insurance Payroll

OS program data data data

Bob rx rx r  
Alice rx rx r rw rw
Sam rwx rwx r rw rw
Accounting
program rx rx rw rw rw
 ACLs vs. Capabilities
r r
Alice ‐‐‐ file1 Alice w file1
r rw

w ‐‐‐
Bob r file2 Bob r file2
‐‐‐ r

rw r
Fred r file3 Fred ‐‐‐ file3
r r

Access Control List (ACL) Capability (C‐List)

• Note that arrows point in opposite directions…

• With ACLs, still need to associate users to files
 ACL C‐List
File 1 A B C User A File 1 File 3
Own R Own Own
R R W R R
W W W
• • •

File 2 B C User B File 1 File 2 File 3 File 4

Own Own
R R R R W R
W W
• • • •

File 3 A B User C File 1 File 2 File 4

Own R Own
R W W R R
W W
• • •

File 4 B C
Own (c) Capability lists for files of part (a)
R R
W
•
In practice, an access matrix is usually sparse and is
(b) Access control lists for files of part (a) implemented by decomposition in one of two ways.

Figure 4.2 Example of Access Control Structures

 Table 4.1
Authorization Table
for Files in Figure 4.2

Each row for one access

right of one subject to one
resource

• A data structure that is

not sparse
• More convenient than
either ACLs or C-lists
• Sorting this table by
subject is equivalent to
a C-List
• Sorting this table by
object is equivalent to
an ACL
A General Model for DAC
• The model assumes:
o a set of subjects,
o a set of objects, and
o a set of rules that govern the access of subjects to objects.

• Protection state of a system to be the set of information, at a

given point in time, that specifies the access rights for each
subject with respect to each object.

• We can identify three Requirements:

o representing the protection state,
o enforcing the access rights,
o and allowing subjects to alter the protection state in certain
ways.
 A

Each entry A[S, X] contains strings, called access attributes, that specify the access
rights of subject S to object X.

Extend the universe of objects in the access control matrix to the following:
• Processes: Access rights: ability to delete, stop (block), and wake up a process.
• Devices: Access rights: ability to read/write, to control and to block/unblock its use.
• Memory locations or regions: Access rights: ability to read/write certain regions
• Subjects: Access rights with respect to a subject have to do with the ability to grant or
delete access rights of that subject to other objects,
• subjects can alter the protection state in certain ways
• Every access by a
subject to an object is
mediated by the
controller for that
object,

• The controller’s decision

is based on the current
contents of the matrix.

• Certain subjects have

the authority to make
specific changes to the
access matrix.

• A request to modify
the access matrix is
treated as an access to
the matrix
 Modifying the Access Control
• Rules are needed to govern the modifications to the access matrix.
• Thus, we introduce to the access rights:
1. ‘owner’ and
2. ‘control’
3. and the concept of a copy flag.
• These rules deal with 1) transferring, 2) granting, and 3) deleting
access rights.
• Eg. Suppose that the entry α* exists in A[S0, X]. This means that S0
has access right α to object X.
• Because of the copy flag, S0 can transfer this right, with or without
copy flag, to another subject.
o Rule R1 in the following slide expresses this capability
Rule Command (by So) Authorization Operation

 *   *
R1 transfer   to S, X '*' in A[So, X] store   in A[S, X]
     Table 4.3
 *  * 
R2 grant   to S, X 'owner' in A[So, X] store   in A[S, X] Access
    
Control
'control' in A[So, S]
System
R3 delete  from S, X or delete  from A[S, X] Commands
'owner' in A[So, X]

'control' in A[So, S]
R4 w  read S, X or copy A[S, X] into w
'owner' in A[So, X]
add column for X to A;
R5 create object X None
store 'owner' in A[So, X]

'owner' in A[So, X] delete column for X from

R6 destroy object X
A
add row for S to A;
R7 create subject S none execute create object S;
store 'control' in A[S, S]
(Table is on
'owner' in A[So, S] delete row for S from A;
R8 destroy subject S page 116 in
execute destroy object S the textbook)
• Rule R1:
• α exists in A[S0, X] means that subject S0 has access right α to object X
• α* (* is the copy flag) means that S0 can transfer this right, with or
without copy flag, to another subject (copy flag should be carefully
transferred).

• Rule R2 states that subject S0 can add any access right to A[S, X] for any
subject S, if S0 has ‘owner’ access to X.

• Rule R3 permits S0 to delete any access right from any matrix entry in a row
for which S0 has the control right of the subject S or for any matrix entry in a
column for which S0 is the owner of the object X.
• Rule R4 states that S0 can permits the subject S to read that portion of the matrix
that it owns or controls.

• Rule R5 states that any subject can create a new object, which it owns, and can
then grant and delete access to the object.

• Rule R6; the owner of an object can destroy the object, resulting in the deletion of
the corresponding column of the access matrix.
• Rule R7 enables any subject to create a new subject; the creator owns
the new subject and the new subject has control access to itself.

• Rule R8 permits the owner of a subject to delete the row and column (if
there are subject columns) of the access matrix designated by that
subject.
UNIX File Access Control
UNIX files are administered by the OS using inodes (index nodes)

• Control structures with key information needed for a particular file

• Several file names may be associated with a single inode
• An active inode is associated with exactly one file; each file is controlled by
exactly one inode
• File attributes, permissions and control information are sorted in the inode
• On the disk there is an inode table, or inode list, that contains the inodes of all
the files in the file system
• When a file is opened its inode is brought into main memory and stored in
a memory resident inode table

Directories are structured in a hierarchical tree

• May contain files and/or other directories

• Contains file names plus pointers to associated inodes
 UNIX

ss

ss
as
la

la
cl
rc
File Access Control

rc
p
ne

e
ro

th
w
O

O
rw- r-- ---
 Unique user identification
number (user ID) user: :rw-
group::r--
 Member of a primary group
other::---
identified by a group ID
 Belongs to a specific group (a) Traditional UNIX approach (minimal access control list)

 12 protection bits
 9 of the protection bits specify
read, write, and execute
permission for the owner of the
file, members of the group and
all other users
 The owner ID, group ID, and
protection bits are part of the file’s
inode
 Traditional UNIX
File Access Control
 “Set user ID”(SetUID)
 Any program that is owned by, and SetUID to, the “superuser” potentially granted
unrestricted access to the system to any user executing that program

 “Set group ID”(SetGID)

 System temporarily uses rights of the file owner/group in addition to the real
user’s rights when making access control decisions
 Enables privileged programs to access files/resources not generally accessible

 Sticky bit
 When applied to a directory it specifies that only the owner of the file in the
directory can rename, move, or delete that file

 Superuser (root)
 Is exempt from usual access control restrictions
 Has system-wide access
When a process requests access to a file:
• Step 1 selects the ACL entry that most closely matches the requesting process. ACL entries
are looked at the order: owner, named users, groups, & others. Only a single entry
determines access.
• Step 2 checks if the matching entry contains sufficient permissions. A process can be a
member of more than one group; so more than one group entry can match. If any of these
matching group entries contain the requested permissions, one that contains the requested
permissions is picked (the result is the same no matter which entry is picked). If none of the
matching group entries contains the requested permissions, access will be denied no matter
which entry is picked.
 Role‐Based Access Control (RBAC)
• Traditional DAC systems define the access rights of individual users and
groups of users. In contrast, RBAC is based on:
o Roles that users assume in a system (instead of their Identity)
o Role is a job function within an organization. A role will have specific access rights
to one or more resources.
o Assign Access Rights to Roles (instead of individual users.)
o Users assigned to different Roles according to their Responsibilities.
o Users-to-Roles are Many-to-Many.

• The set of Users changes frequently (dynamic), and the assignment of a user to
one or more roles may also be dynamic.
• The set of Roles is relatively static, with only occasional additions or deletions.
• The set of Resources and the specific access rights associated with a particular
role are also likely to change infrequently (relatively static).
 Users Roles Resources

• Access rights are assigned to

Roles instead of individuals
Role 1
• Users are assigned to Roles.
(statically or dynamically,
Based on responsibilities)
• Users to Roles are Many-to-Many
• Users may change frequently Role 2

• Often, Roles are static

• A Role has specific access rights

Role 3

Figure 4.6 Users, Roles, and Resources

 Best practice for using RBAC
• RBAC allows to
o Segregate duties within a team and
o Grant only the amount of access to users that they need to perform the jobs.

• Instead of giving everybody (group) unrestricted permissions on a

resource, you can allow only certain actions at a particular scope.
• Planning the access control strategy, it’s a best practice to grant users
the least privilege to get their work done.
o Each role should contain the minimum set of access rights needed for that role.

• A role assignment consists of three elements:

o Security principal, (object that represents a user, group, service principal)
o Role definition, (collection of permissions.)
o Scope, (set of resources that the access applies to)
 Typically,
• Relates individual users to roles R1 R2 Rn
few Roles &
• Typically there are many more users U1 many Users,
than roles U2

• Each entry is either blank or marked U3

• A user may be assigned multiple roles

U4

U5

• A role contains the minimum set of

U6
access rights.
• A user is assigned to a role that
enables him/her to perform only Um

what is required.
• Multiple users may be assigned to OBJECTS
R1 R2 Rn F1 F1 P1 P2 D1 D2
the same Role. owner read
R1 control owner read * wakeup wakeup seek owner
control owner

R2 control write * execute owner seek *

ROLES

• has the same structure as the

Rn control write stop
DAC access control matrix,
with roles as subjects
Figure 4.7 Access Control Matrix Representation of RBAC
 Abstract models of RBAC functionality
RBAC3
• Role: A named job function within the Consolidated model
organization that controls this computer
system. (authority & responsibility)
RBAC1 RBAC2
Role hierarchies Constraints
• Permission: An approval of a particular
mode of access to one or more objects.
(access right, privilege, authorization). RBAC0
Base model
• Session: A mapping between a user and
an activated subset of the set of roles (a) Relationship among RBAC models
to which the user is assigned.

• Temporary one-to-many relationship (RH) Role

Hierarchy Oper-
• Least privilege: Only needed roles ations

• One user may have multiple roles, and (UA) User (PA) Permission
Assignment Assignment
multiple users may be assigned to a Users Roles
Permissions
single role (many-to-many).
user_sessions session_roles
• Flexibility and granularity:
the many-to-many relationships between Objects
users and roles and between roles and
permissions (not found in conventional Sessions
DAC schemes).
without the role hierarchy and
constraints, contains the four
• Without this flexibility and (b) RBAC models types of entities in an RBAC0
granularity, there is a risk that a system:
user may be granted more access
to resources than is needed Figure 4.8 A Family of Role-Based Access Control Models.
 Table 4.3 Scope RBAC Models

• RBAC0 contains the minimum functionality for an RBAC system

• RBAC1 includes the RBAC0 functionality and adds role hierarchies, which enable
one role to inherit permissions from another role
• RBAC2 includes RBAC0 and adds constraints, which restrict the ways in which
the components of a RBAC system may be configured
• RBAC3 contains the functionality of RBAC0, RBAC1, and RBAC2
 An example of a diagram of a role Hierarchy

• Role hierarchies reflect the hierarchical structure of roles in an organization.

• A line between two roles implies that the upper role includes all of the access rights of the
lower role,
• Typically, job functions with greater responsibility have greater authority to access resources
• Role hierarchies make use of the concept of inheritance to enable one role to implicitly
include access rights associated with a subordinate role.
 Constraints ‐ RBAC
• Provide a means of adapting RBAC to the specifics of
administrative and security policies of an organization
• A constraint is a defined relationship among roles or a condition
related to roles. Types:
Mutually Exclusive
Cardinality Prerequisite Roles
Roles

• A user can only be • Setting a maximum • Dictates that a user can

assigned to one role in number with respect to only be assigned to a
the set (either during a roles. E.g. Constraint particular role if it is
session or statically) already assigned to
•the maximum number of
• Any permission (access some other specified role
users that can be assigned to
right) can be granted to a given role • E.g. can be used to
only one role in the set structure the impl. of the
•the number of roles that a
• Separation of duties and user is assigned to, least privilege concept
capabilities (no collusion
•the number of roles a user
among individuals, roles can activate for a single
have non‐overlapping session
permissions)
 Attribute‐based Access Control (ABAC)
• ABAC is a logical access control model that controls access to
objects by evaluating rules against the attributes of entities (subject
and object), operations, and the environment relevant to a request.
• Define authorizations that express conditions on properties of both
the resource and the subject
o E.g. consider a configuration in which each resource has an attribute
that identifies the subject that created the resource.
o Then, a single access rule can specify the ownership privilege for all the
creators of every resource
• Pros:
o The strength of the ABAC approach is its flexibility and expressive power
• Cons:
o Main obstacle to its adoption in real systems has been concern about
the performance impact of evaluating predicates on both resource
and user properties for each access.
 Attribute‐Based Access
Control (ABAC)
Main obstacle to
Web services
its adoption in
have been
Can define real systems has
pioneering There is
authorizations been concern
Strength is technologies considerable
that express about the
its flexibility through the interest in
conditions on performance
and introduction of applying the
properties of impact of
expressive the eXtensible model to
both the evaluating
power Access Control cloud
resource and predicates on
Markup services
the subject both resource and
Language
user properties
(XAMCL)
for each access
 ABAC Model: Attributes
Subject Environment
Object attributes
attributes attributes

• A subject is an • An object (or • Describe the

active entity that resource) is a passive operational,
causes information information system- technical, and even
to flow among related entity situational
objects or changes containing or environment or
the system state receiving information context in which the
• Objects have information access
• Attributes define the occurs
attributes that can
identity and • These attributes
be leveraged to
characteristics of have so far been
make access control
the subject decisions largely ignored in
most access control
policies
 current
set of rules

to determine authorization
 Summary
• Access control principles • Attribute-based
o Access control context access control
o Access control policies o Attributes
o ABAC logical architecture
• Subjects, objects, and o ABAC policies
access rights • Identity, credential,
• Discretionary access and access
control management
o Identity management
o Access control model
o Credential management
o Protection domains o Access management
• UNIX file access control o Identity federation

o Traditional UNIX file access • Trust frameworks

control o Traditional identity
o Access control lists in UNIX exchange approach
o Open identity trust
• Role-based access framework

control • Bank RBAC system

o RBAC reference models