ITE 408

ChapTEr 6

aCCEss ConTrol
Access Control Definitions
1/2
NISTIR 7298 defines access control as:

“the process of granting or denying

specific requests to: (1) obtain and use
information and related information
processing services; and (2) enter specific
physical facilities”
Access Control Definitions
2/2
RFC 4949 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 (users, programs,
processes, or other systems) according to
that policy”
Access Control Principles
• In a broad sense, all of computer security is
concerned with access control

• RFC 4949 defines computer security as:

“measures that implement and assure

security services in a computer system,
particularly those that assure access control
service”
 Authentication vs.
Authorization
• Authentication  Are you who you say you are?
o Restrictions on who (or what) can access the
system
• Authorization  Are you allowed to do that?
o Restrictions on actions of authenticated users
• Authorization is a form of access control

• Access Control implements a security policy that

specifies who 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
o detect breaches in security
o to recommend any indicated changes in control and policy.
 This Source:
function Based on [SAND94].
Verifies that the This function
credentials of a user determines who is
or other system trusted for a given
entity is valid. purpose.

An independent review and

examination of system records
and activities

Source: Based on [SAND94].

 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, processes) index the rows
o Objects (resources) index the columns

Accounting Accounting Insurance Payroll

program data data data

Bob rx r  
Alice rx r rw rw
Sam rwx r rw rw
Accounting
program 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
• Discretionary access • Role-based access
control (DAC)
o Controls access based on the control (RBAC)
identity of the requestor and on o Controls access based on the
access rules (authorizations)
stating what requestors are (or roles that users have within the
are not) allowed to do system and on rules stating
• Mandatory access what accesses are allowed to
control (MAC) users in given roles
o Controls access based on
comparing security labels with
• Attribute-based access
security clearances (subject
clearance and object labels)
control (ABAC)
o Security labels indicate how o Controls access based on
sensitive or critical system attributes of the user, the
resources are. resource to be accessed, and
o security clearance indicate current environmental
system entities are eligible to conditions
access certain resources
 Subjects, Objects, and
Access Rights
The basic elements of access control are: subject, object, and access right

Access
Subject Object
right

Describes the way in

An entity capable of A resource to which
which a subject may
accessing objects access is controlled
access an object

Three classes Could include:

• Owner •Read
Entity used to store or •Write
• Group •Execute
process information
• World •Delete
•Create
•Search
 Subjects & Objects
• A subject is an active entity or agent that can perform
actions and operations
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. For
system resources, ownership may belong to a system administrator.
• 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 of 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, etc.).
• 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: The user may execute specified programs.
o Delete: The user may delete certain system resources, such as
files or records.
o Create: The user may create new files, records, or fields.
o Search: The 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
• 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
• For each object, an ACL lists users and their permitted access rights
• With ACLs, it's easy to change rights to a particular resource.

r
file1 --- Alice
r

w
file2 r Bob
---

rw
file3 r Fred
r
 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 add or delete users.

r
Alice w file1
rw

---
Bob r file2
r

r
Fred --- file3
r
 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
• ACL: store Lampson's access control matrix by column
Capability: Store access control matrix by row
(b) Access control lists for files of part (a)

Figure 4.2 Example of Access Control Structures

Subject Access
Mode
Object
Table 4.1
A Own File 1
Authorization Table
A Read File 1
for Files in Figure 4.2
A Write File 1
A Own File 3
Each row for one access
A Read File 3 right of one subject to one
A Write File 3 resource
B Read File 1
B Own File 2 • A data structure that is
not sparse
B Read File 2
B Write File 2 • More convenient than
B Write File 3 either ACLs or C-lists
B Read File 4 • Sorting this table by
C Read File 1 subject is equivalent to
C Write File 1 a C-List
C Read File 2 • Sorting this table by
C Own File 4 object is equivalent to
C Read File 4 an ACL
C Write File 4 (Table is on page 113 in the textbook)
 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.
• Allows subjects to alter the protection state in
certain ways.
 OBJECTS
subjects files processes disk drives
S1 S2 S3 F1 F2 P1 P2 D1 D2  Each entry A[S, X] contains
strings, called access
control owner owner read * read attributes
S1 wakeup wakeup seek owner
control owner

 S1 may read file F1,

SUBJECTS S2 control write * execute owner seek *
because ‘read’ appears in
A[S1, F1].
S3 control write stop

* - copy flag set

Figure 4.3 Extended Access Control Matrix

To represent the protection state, we extend the universe of objects in the

access control matrix to include the following:
 Processes: Access rights include the ability to delete a process, stop (block), and wake
up a process.
 Devices: Access rights include the ability to read/write the device, to control its operation
(e.g., a disk seek), and to block/unblock the device for use.
 Memory locations or regions: Access rights include the ability to read/write certain
regions of memory that are protected
 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
 Access Control Functions
The module evaluates each request by a subject to access an
object to determine if the access right exists. An access attempt
triggers the following steps:

1. A subject S0 issues a request of type α for object X.

2. The request causes the system (the operating system or an

access control interface module) to generate a message of the
form (S0, α, X) to the controller for X.

3. The controller interrogates the access matrix A to determine if

α is in A[S0, X]. If so, the access is allowed; if not, the access is
denied and a protection violation occurs.
• 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
 Such accesses are mediated
by an access matrix
controller, which controls
updates 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

ì a* ü ìa *ü
R1 transfer í ý to S, X 'a*' in A[So, X] store í ý in A[S, X]
î a þ îa þ
ìa *ü ì a* ü Access
R2 grant í ý to S, X 'owner' in A[So, X] store í ý in A[S, X] Control
îa þ î a þ
System
'control' in A[So, S]
Commands
R3 delete a from S, X or delete a from A[S, X]
'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; page 116 in the
R8 destroy subject S textbook)
execute destroy object S
• 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.

• 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 permit 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 using inodes (index
nodes)
• Control structures that contain the key information needed for a
particular file
• An active inode is associated with exactly one file
• 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

ss
la

a
cl
File Access Control

rc

cl
p

er
ne

u
ro

th
w
O

O
rw- r-- ---
user: :rw-
group::r--
 Each UNIX user is assigned a other::---
unique user identification
number (user ID). (a) Traditional UNIX approach (minimal access control list)
 A user is also a member of a
primary group, and possibly Figure 4.5 UNIX File Access Control
a number of other groups,

ss

s
as
la

as
each identified by a group

cl
rc

cl
up

er
ne
ID

ro

th
w
O

O
 When a file is created, it is
 9 protection bits
designated as owned by a
particular user and marked  Specify read, write, and execute
with that user’s ID. It also permission for the owner of the file,
belongs to a specific group,
which initially is either its members of the group and all other
creator’s primary group or users
the group of its parent  The owner ID, group ID, and protection bits are
directory
part of the file’s inode
 Access Control on Unix
• To List all the users of the system
ls /etc/passwd
• To read the content of the file
cat /etc/shadow
• How can we see the Matrix or ACL
ls – l /etc/shadow
• Switch to a different user u
su username
• Create a file (check permission by ls – l filename)
echo “Hello” > file1.txt
• Change permission on the file for others
chmod 660 file1.txt
 Mandatory Access
Control (MAC)
• Based on multilevel security
top secret > Secret > confidential > restricted > unclassified
• Subject has security clearance of a given level
• Object has security classification of a given level
• Two required properties for confidentiality
o No read up: This property states that a subject with a certain security level
should not be able to read data at a higher security level (i.e., no subject
should read data "up" to a higher classification level).
• It prevents information from flowing from lower security levels to higher
security levels.
o No write down: This property dictates that a subject with a certain security
level should not be able to write data to a lower security level (i.e., no subject
should write data "down" to a lower classification level).
• It prevents information from being written to less secure areas
• Clearance or classification is determined by
administrator; user can not overwrite security policy
 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 are 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
Role 2
• Users may change frequently
• Often, Roles are static
• A Role has specific access rights
Role 3

Figure 4.6 Users, Roles, and Resources

• Relates individual users to roles Typically,
R1 R2 Rn
• Typically there are many more few Roles &
users than roles
U1
many Users,
U2
• Each entry is either blank or
marked U3

• A user may be assigned multiple U4

roles U5

• A role contains the minimum set of U6

access rights.
• A user is assigned to a role that Um

enables him/her to perform only what

is required.
OBJECTS
• Multiple users may be assigned to the R1 R2 Rn F1 F1 P1 P2 D1 D2

same Role. R1 control owner owner

control
read * read
owner
wakeup wakeup seek owner

R2 control write * execute owner seek *

ROLES

• has the same structure as the Rn control write stop

DAC access control matrix,

Figure 4.7 Access Control Matrix Representation of RBAC
with roles as subjects
 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.
• 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)
• User Principal: John_Doe
• Group Principal: IT_Admin_Group
• Service Principal: WebApp_Service
o Role definition, (collection of permissions.)
• Role: Database_Administrator
• Permissions: Read, Write, Execute on specific databases.
o Scope, (the set of resources to which the access permissions apply)
• Scope: Production_Databases
• Resources: DB_Server_1, DB_Server_2
 Abstract models of RBAC functionality

• Role: A named job function within the

organization that controls this computer
system. (authority & responsibility)

• Permission: An approval of a particular

mode of access to one or more objects.
(access right, privilege, authorization).

• Session: A mapping between a user and

an activated subset of the set of roles
to which the user is assigned.

• Temporary one-to-many relationship

• Least privilege: Only needed roles

• One user may have multiple roles, and

multiple users may be assigned to a
single role (many-to-many).

• Flexibility and granularity:

the many-to-many relationships between
users and roles and between roles and
permissions (not found in conventional
DAC schemes).

• Without this flexibility and

granularity, there is a risk that a without the role hierarchy and
constraints, contains the four
user may be granted more access types of entities in an RBAC0
to resources than is needed system:
 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 an RBAC system may be configured
• RBAC3 contains the functionality of RBAC0, RBAC1, and RBAC2
 An example of a diagram of a role Hierarchy
Director

Project Lead 1 Project Lead 2

Production Quality Production Quality

Engineer 1 Engineer 1 Engineer 2 Engineer 2

Engineer 1 Engineer 2

Engineering Dept

Figure 4.9 Example of 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.
Case Study: RBAC
Functions and Roles for Banking Example
Functions and Roles for Banking Example
 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
Roles Cardinality Prerequisite 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. particular role if it is
session or statically) already assigned to
• the maximum number of
• Any permission (access users that can be some other specified
right) can be granted to assigned to a given role role.
only one role in the set
• Separation of duties and
capabilities (no collusion
among individuals, roles
have non-overlapping
permissions)
 Attribute-Based Access
Control (ABAC)

Main obstacle to
its adoption in Web services
real systems has have been
Can define been concern pioneering
There is
authorizations about the technologies
Strength is its considerable
that express performance through the
flexibility and interest in
conditions on impact of introduction of
expressive applying the
properties of evaluating the eXtensible
power model to cloud
both the resource predicates on Access Control
services
and the subject both resource Markup
and user Language
properties for (XAMCL)
each access
 ABAC Model: Attributes
Subject Object Environment
attributes attributes attributes
• A subject is an • An object (or • Describe the
active entity that resource) is a operational,
causes information passive information technical, and even
to flow among system-related situational
objects or changes entity containing or environment or
the system state receiving context in which the
information information access
• Attributes define the occurs
identity and • Objects have • These attributes
characteristics of attributes that can have so far been
the subject be leveraged to largely ignored in
make access most access control
control decisions policies
 ABAC
Relies upon the
Distinguishable because
evaluation of attributes
it controls access to
of the subject, attributes
objects by evaluating
of the object, and access
rules against the
control rule defining the
attributes of entities,
allowable operations for
operations, and the
subject-object attribute
environment relevant to
combinations in a given
a request
environment

Allows an unlimited
Systems are capable of
number of attributes to
enforcing DAC, RBAC,
be combined to satisfy
and MAC concepts
any access control rule
 Subject Object Environmental
Attributes Attributes Attributes

Clearance Owner Temperature

Name Type Time

Etc. Affiliation Etc. Classification Etc. Security

2b 2c 2d

Permit
1 3

Access
control Deny
mechanism
Subject (user)
2a

Access Control
Policies

Figure 4.10 ABAC Scenario

 Summary
• Access control principles • Attribute-based
o Access control context
access control
o Access control policies
o Attributes
• Subjects, objects, and o ABAC logical
access rights architecture
o ABAC policies
• Discretionary access
control
• Identity,
o Access control model credential, and
o Protection domains access
• UNIX file access control management
o Traditional UNIX file access o Identity management
control o Credential
o Access control lists in UNIX management
o Access management
• Role-based access
o Identity federation
control
o RBAC reference models