Chapter 4:

Access Control
2

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 secu-
rity
• Assume have users and groups
 authenticate to system
 assigned access rights to certain re-
sources on system
3

Access Control Principles

4

Access control policies

• Discretionary access control (DAC):
based on the identity of the requestor and
access rules
• Mandatory access control (MAC): based
on comparing security labels with security
clearances (mandatory: one with access to
a resource cannot pass to others)
• Role-based access control (RBAC): based
on user roles
• Attribute-based access control: based
on the attributes of the user, the resources
and the current environment
5

Access Control Requirements

• Reliable input: a mechanism to authenti-

cate
• Fine and coarse specifications: regulate ac-
cess at varying levels (e.g., an attribute or
entire DB)
• Least privilege: min authorization to do its
work
• Separation of duty: divide steps among dif-
ferent individuals
• Open and closed policies: accesses specifi-
cally authorized or all accesses except
those prohibited
• Administrative policies: who can add,
6

Access Control Elements

• Subject: entity that can access objects

 a process representing user/application
 often have 3 classes: owner, group,
world
• Object: access controlled resource
 e.g. files, directories, records, programs
etc
 number/type depend on environment
• Access right: way in which subject ac-
cesses an object
 e.g. read, write, execute, delete, create,
search
7

Discretionary Access Control

• Often provided using an access ma-

trix
 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
8

Access Control Structures

• Access control lists (decomposed by

column)
• Capability tickets (decomposed by row)
• See page 119
• Also see alternative table
representation on page 120 (tabular but
not sparse)
9

An access matrix
10

Access matrix data structures

11

Alternate
authorization
table
12

An Access Control Model

• Extend the universe of objects to

include processes, devices, memory
locations, subjects
13

Access Control Function

14

Access control system commands

15

Protection Domains: More Useful

• Set of objects together with access rights to those ob-

jects
• More flexibility when associating capabilities with pro-
tection domains
• In terms of the access matrix, a row defines a protec-
tion domain
• User can spawn processes with a subset of the access
rights of the user
• Association between a process and a domain can be
static or dynamic
• In user mode certain areas of memory are protected
from use and certain instructions may not be executed
• In kernel mode privileged instructions may be executed
and protected areas of memory may be accessed
16

Role-Based Access Control

Access based on
‘role’, not identity

Many-to-many
relationship
between
users and roles

Roles often static

17
Role-Based
Access Control

Role-users and
roles-object
access matrix
18

General RBAC, Variations

• A family of RBAC with four models

1. RBAC0: min functionality
2. RBAC1: RBAC0 plus role (permission) inheritance
3. RBAC2: RBAC0 plus constraints (restrictions)
4. RBAC3: RBAC0 plus all of the above
• RBAC0 entities
 User: an individual (with UID) with access to system
 Role: a named job function (tells authority level)
 Permission: equivalent to access rights
 Session: a mapping between a user and set of roles
to which a user is assigned
19

Role-Based
Access Control

Double arrow: ‘many’ relationship

Single arrow: ‘one’ relationship
20

Example Of Role Hierarchy

• Director has most privileges
• Each role inherits all privileges from lower
roles
• A role can inherit from multiple roles
• Additional privileges can be assigned to a
role
21

Constraints

• A condition (restriction) on a role or between

roles
 Mutually exclusive
• role sets such that a user can be assigned to only one
of the role in the set
• Any permission can be granted to only one role in the
set
 Cardinality: set a maximum number (of users) wrt
a role (e.g., a department chair role)
 Prerequisite role: a user can be assigned a role
only if that user already has been assigned to
some other role
22

Attribute-based Access Control

• Fairly recent
• Define authorizations that express conditions on
properties of both the resource and the subject
 Each resource has an attribute (e.g., the subject that
created it)
 A single rule states ownership privileges for the
creators
• Strength: its flexibility and expressive power
• Considerable interest in applying the model to
cloud services
23

Types Of Attributes

• Subject attributes
• Object attributes
• Environment attributes
24

Subject Attributes

• A subject is an active entity that causes

information to flow among objects or
changes the system state
• Attributes define the identity and
characteristics of the subject
 Name
 Organization
 Job title
25

Object Attribute

• An object (or resource) is a passive

information system-related entity
containing or receiving information
• Objects have attributes that can be
leveraged to make access control
decisions
 Title
 Author
 Date
26

Environment Attributes

• Describe the operational, technical, and

even situational environment or context
in which the information access occurs
 Current date
 Current virus/hacker activities
 Network security level
 Not associated with a resource or subject
• These attributes have so far been largely
ignored in most access control policies
27

Sample ABAC Scenario

1. A subject requests
access to an object
2. AC is governed by a
set of rules (2a):
assesses the
attributes of subject
(2b), object (2c) and
env (2d)
3. AC grants subject
access to object if
authorized
28

ACL vs ABAC trust relationships

29

ACL vs ABAC trust relationships

30
Identity, Credential, and Access
Management (ICAM)
• A comprehensive approach to managing and
implementing digital identities, credentials, and access
control
• Developed by the U.S. government
• Designed to create trusted digital identity
representations of individuals and nonperson entities
(NPEs)
• A credential is an object or data structure that
authoritatively binds an identity to a token possessed
and controlled by a subscriber
• Use the credentials to provide authorized access to an
agency’s resources
31

ICAM
1. Connects digital identity
to individuals

2. Data structures that

binds
a token possessed
by a subscriber

4. Identity verification
of
individuals from
external
organizations

3. Management of how access

is granted to entities
32
Case Study: RBAC System For A Bank
33
Case Study: RBAC System For A Bank

• b has more access than A (strict ordering)

• Inheritance makes tables simpler
34

Case Study: RBAC System For A Bank

35

Summary

• introduced access control prin-

ciples
 subjects, objects, access rights
• discretionary access controls
 access matrix, access control lists
(ACLs), capability tickets
 UNIX traditional and ACL mechan-
isms
• role-based access control
• case study
End of Chapter 4