Computer Security:

Principles and Practice

Chapter 4 – Access Control

First Edition
by William Stallings and Lawrie Brown

Lecture slides by Lawrie Brown

 Access Control
 “The prevention of unauthorized use of a
resource, including the prevention of use
of a resource in an unauthorized manner“
 central element of computer security
 assume have users and groups
 authenticate to system
 assigned access rights to certain resources
on system
Access Control Principles
 Access Control Policies
 An access control policy, which is embodied in an
authorization database, dictates what types of access
are permitted, under what circumstances, and by
whom. Access control policies are generally grouped
into the following access control categories:
 Discretionary access control (DAC): based on the identity of the
requestor and on access rules (authorizations) stating what
requestors are (or are not) allowed to do. This policy is termed
discretionary because an entity might have access rights that permit
the entity, by its own volition, to enable another entity to access
some resource.
 Mandatory access control (MAC): based on
comparing security labels (which indicate how
sensitive or critical system resources are) with
security clearances (which indicate system entities are
eligible to access certain resources). This policy is
termed mandatory because an entity that has
clearance to access a resource may not, just by its
own volition, enable another entity to access that
resource.
 i.e. In the U.S. Government, the classifications are TOP
SECRET, SECRET, CONFIDENTIAL, and UNCLASSIFIED.
 Cont.
 Role-based access control (RBAC): based on the roles that users
have within the system and on rules stating what accesses are
allowed to users in given roles.
 DAC is the traditional method of implementing access
control.
 MAC is a concept that evolved out of requirements for
military information security and is best covered in the
context of trusted systems.
 RBAC has become increasingly popular.
 Can employ two or even all three of these policies to cover
different classes of system resources.
Access Control Policies
 Access Control Requirements
 Reliable input: it assumes that a user is authentic.
 Support fine and coarse specifications.
 Fine-grained Specifications: Allow access regulated at the level
of individual fields / records in files.
 Course-grained Specifications: System administrators should be
able to choose course-grained specifications for some classes of
resources accesses.
 least privilege:
 It should be implemented so that each system entity is granted
the minimum system resources and authorizations needed to do
its work. This principle tends to limit damage that can be caused
by an accident, error, or unauthorized act.
 Cont.
 Open and closed policies:
 A closed policy only allows accesses that are
specifically authorized. [most useful and most used]
 An open policy allows all accesses except those
expressly prohibited. [useful in some applications]
 Administrative policies
 To specify who can add, delete, or modify
authorization rules, and also need access control and
other control mechanisms to enforce these
administrative policies.
 Access Control Elements
 subject - entity that can access objects
 a process representing user/application
 often have 3 classes: owner, group, world.
 Owner: This may be the creator of a resource, such as a file.
For system resources, ownership may belong to a system
administrator. For project resources, a project administrator
or leader my be assigned ownership.
 Group: In addition to the privileges assigned to an owner, a
named group of users may also be granted access rights,
such that membership in the group is sufficient to exercise
these access rights.
 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 for this resource.
 Cont.
 object - access controlled resource
 e.g. files, directories, records, programs
etc
 number/type depend on environment
 access right - way in which subject
accesses an object
 e.g. read, write, execute, delete, create,
search
Discretionary Access Control
 often provided using an access matrix
 lists subjects in one dimension (rows)
 lists objects in the other dimension (columns)
 each entry specifies access rights of the
specified subject to that object
 access matrix is often sparse
 can decompose by either row or column
 Access Control Structures
Objects

File 1 File 2 File 3

User A
User A Own Own File 1 File 2
Read Read Own Read
Subjects Write Write Read
User B Read Own Write
Read
Write
User C Read Read Read Capability Lists
Write
Access Matrix
Extended Access Control Matrix
 Cont.
• Processes: Access rights include the ability to
delete a process, stop (block), and wakeup 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 locations
of regions of memory that are protected so that
the default is that access is not allowed.
•
 Cont.
 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, as explained subsequently.
 A separate access control module is
associated with each object type.
 Copy flag: allows grant (delegation), either
with or w/o delegation of copy flag.
 Cont.
 Transfer {r, r*} on X from S to S’ allowed if any
of the following hold:
 A[S,X] = r* (S has right r on X, and copy flag

set)
 A[S,X] = “owner” (S owns X)

 A[S,X] = r and A[S,S’] = “control” (S has right r

on X, and S created S’)

 Delete {r} on X from S’ allowed if any of the

following hold
 A[S,X] = “owner”
 S[S,S’] = “control”
 Access Control Function
 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 (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 check 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.
Access Control Function
 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 the roles that users
assume in a system rather than the user's identity.
 RBAC systems assign access rights to roles
instead of individual users.
 Users are assigned to different roles according to
their responsibilities.
 The relationship of users to roles is many to
many.
 Role-
Based
Access
Control
 Role-
Based
Access
Control
 RBAC Reference 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 restricts the ways in which the components of
a RBAC system may be configured.
 RBAC3 includes RBAC0 plus the added
functionality of both RBAC1 and RBAC2.

RBAC
An RBAC system contains the
0
0

four types of entities:

 User: An individuals that has
access to this computer system,
& associated user ID.
 Role: A named job function
within the organization that
controls this computer system.
Typically, associated with each role
is a description of the authority and responsibility conferred on this
role, and on any user who assumes this role.
 Permission: An approval of a particular mode of access to one or more
objects. Equivalent terms are access right, privilege, and authorization.
 Session: A mapping between a user and an activated subset of the set of roles
to which the user is assigned.
 RBAC1
 Job functions with greater authority 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.

Director

Project Lead 1 Project Lead 2

Production Quality Production Quality

Engineer 1 Engineer 1 Engineer 2 Engineer 2

Engineer 1 Engineer2

Engineering Dept.
 RBAC2
 RBAC2 includes RBAC0 and adds constraints, which restricts the
ways in which the components of a RBAC system may be
configured.
 A constraint is a defined relationship among roles or a condition
related to roles.
 Mutual exclusive roles:
• A user can be assigned to only one role in the set (either during a
session or statically).
• Any permission can be granted to only one role in the set.
 Cardinality:
• Set a maximum number with respect to roles such as the maximum
number of users that can be assigned to a specific role. i.e. a project
leader role or a department head role would be limited to one user.
 Prerequisite roles:
• A user can only be assigned to a particular role if it is already assigned
to some other specified role. i.e. a user assigned to a project lead role
must get the production engineer and quality engineer roles.
 Summary
 introduced access control principles
 subjects, objects, access rights
 discretionary access controls
 access matrix, access control lists (ACLs),
capability tickets
 UNIX traditional and ACL mechanisms
 role-based access control
 case study