Access control

Overview
 Access control concepts
» Matrix, ACLs, Capabilities
 Classical Access Control Models
– Discretionary Access Control (DAC)
– Mandatory Access Control (MAC)
– Role-Based Access Control (RBAC)
– Other Access Control Models

1
 IT security and Privacy
 The state of a system is the collection of the current
values of all memory locations, all secondary storage,
and all registers and other components of the system.
 The subset of this collection that deals with protection
is the protection state of the system.
 An access control matrix is one tool that can describe
the current protection state.
 Security mechanisms can be divided into internal
mechanisms that are enforced by the IT system and
external mechanisms that are implemented outside of
the system. 3

2
 IT - Security
 Traditionally, term IT - Security has evolved in the recent
years. For a long time, secure systems had been
concentrated on security aspects to protect the IT-system
and its information against unauthorised or inappropriate
use.
 Emphasis of IT-security was initially on confidentiality in
the meaning of secrecy of classified information (military).
 Since the late eighties, IT security has been defined by
Confidentiality, Integrity and Availability.

 Confidentiality and integrity, which can be mainly

protected by means of access control.
 Incidents of personal data abuses have demonstrated
the need for protection against the malfunctioning of the
system or system misuses.

3
 Authorization
 Authorization is the act of checking whether a user has
permission to conduct some action.
 Whereas authentication is about verifying identity,
authorization is about verifying a user’s authority.
 E.g. ATM withdrawal per day (limit 40,000)
 Operating systems do authorization checks all the time.
E.g. Alice attempts to delete a file, the operating system
checks whether Alice is allowed to do so.
 A general mechanism called an access control list
(ACL) is used by many operating systems.
7

4
 9

Access control: introduction

 Two important cases:

» An attacker has access to the raw bits representing the
information
=> need for cryptographic techniques
» There is a software layer between the attacker and the
information
=> access control techniques

10

10

5
 11

11

12

12

6
 13

13

Access control policy: introduction

 Access control techniques are ways to build this
software layer such that it allows for simple, flexible
and efficient implementation of a security policy
 Access control techniques are used in:
» Operating systems
» Databases
» Web servers
» Execution platforms for mobile code
» …

14

14

7
 Access control: introduction
 Different access control models exist to accommodate
different policies
 Model should be simple, expressive, intuitive,
manageable, implementable,…

15

15

Terminology
• 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
accesses an object
– e.g. read, write, execute, delete, create,
search

16

16

8
 Access control matrix
 The rights in a cell specify the accesses of the subject (row) to the object
(column)

 Example:
Subject/ object File_1 File_2 File_3 Process_1

Chris Read, Write - Write -

Janet - Execute - Suspend
Barbara - Read Read -
Frank Read - - -

 The access control matrix is typically a conceptual vehicle not an

implementation structure
17

17

Access control lists (ACL)

ACL is a set of users and a corresponding set of
resources they are allowed to access.
File_1 File_2
Chris:r Janet:x
Chris:w Barbara:r
Frank:r

each column of the access matrix is stored with the

object corresponding to that column

18

18

9
 Capability lists

Chris File_1/r, File_1/w, File_3/w

Janet File_2/x, Process_1/s

each row of the access matrix is stored with the

subject corresponding to that row

19

19

ACL vs Capabilities
ACCESS REVIEW
• ACL's provide for superior access review on a per-
object basis
• Capabilities provide for superior access review on a
per-subject basis
REVOCATION
• ACL's provide for superior revocation facilities on a
per-object basis
• Capabilities provide for superior revocation facilities
on a per-subject basis
20

20

10
 ACL vs Capabilities
 The per-object basis usually wins out so most Operating
Systems protect files by means of ACL's
 Many Operating Systems use an abbreviated form of
ACL's with just three entries (Unix)
» owner
» group
» other

21

21

Controls Assessments
 We are looking at all access permissions including
building access, access to server rooms, access to
networks and applications and utilities.
 These are all implementations of access control and are
part of a layered defense strategy, also known as
defense in depth, developed by an organization.
 Defense in depth describes an information security
strategy that integrates people, technology and
operations capabilities to establish variable barriers
across multiple layers and missions of the organization.
22

22

11
 Controls Assessments – E.g.
 A technical example of defense in depth, is when a
username and password are required for logging in to
your account.
 Followed by a code sent to your phone to verify your
identity.
 This is a form of multi-factor authentication using
methods on two layers, something you have and
something you know.
 The combination of the two layers is much more difficult
for an adversary to obtain than either of the
authentication codes individually. 23

23

Controls Assessments Contd.

 Another example of multiple technical layers is when
additional firewalls are used to separate untrusted
networks with differing security requirements, such as
the internet from trusted networks that house servers
with sensitive data in the organization.
 A non-technical example, a lock on the door provides a
physical barrier to access the data storage devices.
 Second, a technical access rule prevents access to the
data via the network.
 Finally, a policy, or administrative control defines the
rules that assign access to authorized individuals. 24

24

12
 Principle of Least Privilege
 The Principle of Least Privilege (NIST SP 800-179) is a
standard of permitting only minimum access necessary
for users or programs to fulfill their function.
 Users are provided access only to the systems and
programs they need to perform their specific job or
tasks.
 To preserve the confidentiality of information and ensure
that it is only available to personnel who are authorized,
we use privileged access management. That means
each user is granted access only to the items they need
and nothing further.
25

25

Principle of Least Privilege E.g.

 For example, only individuals working in billing will be
allowed to view consumer financial data, and even
fewer individuals will have the authority to change or
delete that data.
 This maintains confidentiality and integrity while also
allowing availability by providing administrative access
with an appropriate password or sign-on that proves the
user has the appropriate permissions to access that
data.
 Limited access due to time.
 Health record needs when required and for a particular
patient. 26

26

13
 Privileged Access Management
 Privileged accounts are those with permissions beyond
those of normal users, such as managers and
administrators.
 Broadly speaking, these accounts have elevated
privileges and are used by many different classes of
users, including:
» Systems administrators,
» Help desk or IT support staff,
» Security analysts

27

27

Segregation of Duties
 A element of authorization is the principle of segregation
of duties (also known as separation of duties).
 Segregation of duties is based on the security practice
that no one person should control an entire high-risk
transaction from start to finish.
 Segregation of duties breaks the transaction into
separate parts and requires a different person to
execute each part of the transaction.

28

28

14
 Segregation of Duties
 For example, an employee may submit an invoice for
payment to a vendor (or for reimbursement to
themselves), but it must be approved by a manager
prior to payment;
 In another instance, almost anyone may submit a
proposal for a change to a system configuration, but the
request must go through technical and management
review and gain approval, before it can be implemented.

29

29

Segregation of Duties
 Another implementation of segregation of duties is dual
control. This would apply at a bank where there are two
separate combination locks on the door of the vault.
 Some personnel know one of the combinations and
some know the other, but no one person knows both
combinations.
 Two people must work together to open the vault; thus,
the vault is under dual control.

30

30

15
 Physical Access
 Badge Systems and Gate Entry
 Environmental Design
 Biometrics
 Monitoring
» Camera
» Logs
» Security Guards
» Alarm system

31

31

What are Logical Access Controls?

 Whereas physical access controls are tangible methods
or mechanisms that limit someone from getting access
to an area or asset.
 Logical access controls are electronic methods that limit
someone from getting access to systems, and
sometimes even to tangible assets or areas. Types of
logical access controls include:
» Passwords
» Biometrics (implemented on a system, such as a smartphone or laptop)
» Badge/token readers connected to a system

32

32

16
 Discretionary Access Control (DAC)
 Discretionary access control (DAC) is a specific type of
access control policy that is enforced over all subjects
and objects in an information system.
 In DAC, the policy specifies that a subject who has
been granted access to information can do one or more
of the following:
» Pass the information to other subjects or objects
» Grant its privileges to other subjects
» Change security attributes on subjects, objects, information systems or
system components
» Choose the security attributes to be associated with newly created or
revised objects; and/or
» Change the rules governing access control; mandatory access controls 33
restrict this capability

33

Discretionary Access Control (DAC)

 In a DAC system, a user who has access to a file is

usually able to share that file with or pass it to someone
else.
 This grants the user almost the same level of access as
the original owner of the file.
 Hence, security of the object is literally up to the
discretion of the object owner.
 Rule-based access control systems are usually a form
of DAC.
34

34

17
 Discretionary Access Control (DAC) Revisited

• DAC allows access rights to be propagated at

subject’s discretion
– often has the notion of owner of an object
– used in UNIX, Windows, etc.
• "A means of restricting access to objects based on
the identity and need-to-know of users and/or
groups to which the object belongs. Controls are
discretionary in the sense that a subject with a
certain access permission is capable of passing
that permission (directly or indirectly) to any other
subject."
35

35

Mandatory Access Control (MAC)

 A mandatory access control (MAC) policy is one that is
uniformly enforced across all subjects and objects
within the boundary of an information system.
 In simplest terms, this means that only properly
designated security administrators, as trusted subjects,
can modify any of the security rules that are established
for subjects and objects within the system.

36

36

18
 Mandatory Access Control (MAC)
 This also means that for all subjects defined by the
organization (that is, known to its integrated identity
management and access control system), the
organization assigns a subset of total privileges for a
subset of objects, such that the subject is constrained
from doing any of the following:
» Passing the information to unauthorized subjects or objects
» Granting its privileges to other subjects
» Changing one or more security attributes on subjects, objects, the
information system or system components
» Choosing the security attributes to be associated with newly created or
modified objects
» Changing the rules governing access control 37

37

 Although MAC sounds very similar to DAC, the primary

difference is who can control access. With Mandatory
Access Control, it is mandatory for security
administrators to assign access rights or permissions;
with Discretionary Access Control, it is up to the object
owner’s discretion.

38

38

19
 Role-Based Access Control (RBAC)
 Role-based access control (RBAC), as the name
suggests, sets up user permissions based on roles.
 Each role represents users with similar or identical
permissions.
 Role-based access control provides each worker
privileges based on what role they have in the
organization.
 Only Human Resources staff have access to personnel files, for
example; only Finance has access to bank accounts; each
manager has access to their own direct reports and their own
department.
 Very high-level system administrators may have access to
everything; new employees would have very limited access, the39
minimum required to do their jobs.
39

Security models/policies

 Security models that will be discussed are:-

 Military security policy
 Commercial security policies
» Bell LaPadula Model
» Biba Model
» Role-Based and Task-based Access Control Models
» Clark-Wilson policy
» Separation of duty
» Chinese wall security policy

40

40

20
 Military Security Policy
 Classification of information
» Ranks of levels: unclassified, restricted, confidential, secret,
top secret
 Need-to-know
» Access to sensitive data is allowed only to subjects who need
to know them to perform their jobs
» Compartment
• Projects describing the subject matter of the information
 Security class (of information)
» Determined by both rank and compartment
» Example: <secret, {crypto}>
41

41

The Need-To-Know Principle

• Even if someone has all the necessary
official approvals (such as a security
clearance) to access certain information,
they should not be given access to such
information unless they have a need to
know:
– That is, unless access to the specific
information necessary for the conduct of one's
official duties.
• More easily implemented using DAC

42

21
 Military Security Policy
 Clearance
» A clearance is an indication that a person is trusted to access
information up to
• A certain level of sensitivity, and
• Certain categories of information
» Denoted in the same way as security classes
 A subject can read an object only if
» The clearance level is at least as high as that of the
information, and
» The subject has a need-to-know about all compartments for
which the information is classified
» Dominate relation
43

43

Security Models
• Multi-level security models
– Bell La Padula model -- multi-level
confidentiality
– Biba model -- multi-level integrity
– Models for determining the system security
policy

44

44

22
 Bell-LaPadula Model: A MAC Model
(Use other lecture notes to study BLP)
• Introduced in 1973
• Air Force was concerned with security in time-
sharing systems
– Many OS bugs
– Accidental misuse
• Basic idea
– Information should not flow downward
• Main Objective
– Enable one to show that a computer system can
securely process classified information

45

45

Basic Idea
• There are security classifications or security levels
• Example
– Top Secret
– Secret
– Confidential
– Unclassified
• In this case,
• Top Secret > Secret > Confidential > Unclassified

46

46

23
 Multi level security

TS

Lattice of S
security
labels
C
Information Dominance
Flow
U
47

47

A Simplified Version of the Model

• A computer system is modeled as a state-
transition system
– In each state, each subject is given a level
(clearance), and each object is given a level
(security class)
• A state is secure if it satisfies
– Simple Security Condition (no read up):
• S can read O iff L(S) ≥ L(O)
– The Star Property (no write down)
• S can write O iff L(S) ≤ L(O)
48

48

24
 Bell-Lapadula model (BLP)
SIMPLE-SECURITY
Subject S can read object O only if
• label(S) dominates label(O)
• information can flow from label(O) to label(S)
STAR-PROPERTY
Subject S can write object O only if
• label(O) dominates label(S)
• information can flow from label(S) to label(O)
49

49

STAR property
 Applies to subjects not to users
 Users are trusted (must be trusted) not to disclose
secret information outside of the computer system
 Subjects are not trusted because they may have Trojan
Horses embedded in the code they execute
 Star-property prevents overt leakage of information and
addresses Trojan horse problem

50

50

25
 Issues with BLP

• Deal only with confidentiality

– does not deal with integrity at all

• Does not deal with information flow

through covert channels

• The approach of defining a secure system to

be one in which every reachable state is
secure is flawed 51

51

Trojan horses
 A Trojan Horse is rogue software installed, perhaps
unwittingly, by duly authorized users
 A Trojan Horse does what a user expects it to do, but
in addition exploits the user's legitimate privileges to
cause a security breach

52

52

26
 Trojan horse example
ACL
A:r
File F
A:w

B:r
File G
A:w

Subject B cannot read file F

53

53

Trojan horse example

Principal A ACL
executes
A:r
read File F
Program Goodies A:w

Trojan Horse
B:r
File G
write A:w

Subject B can read contents of file F copied to file G 54

54

27
 Trojan Horse Revisited (Cont’d)

• Viruses and logic bombs are examples of

Trojan Horses
• It is possible to embed Trojan Horses in
hardware and firmware
• It is possible to embed Trojan Horses in
critical system software such as compilers
and Database Management Systems

55

55

Need for Multi-Level Integrity Protection

• Bell-LaPadula and other information-flow based

security definitions address confidentiality, what
about integrity
• What does integrity mean?
– System integrity: system behave as expected
– Data integrity: data not changed in “incorrect” ways
• One difference between confidentiality & integrity
– A subject cannot leak a piece of confidential
information without reading it, but can introduce low-
integrity information without reading any
• Some trust has to be placed on subjects for integrity
56

56

28
 Integrity Defined (Biba)

• A subsystem possesses the property of

integrity if it can be trusted to adhere to a
well-defined code of behavior
• How to guarantee integrity?
– The subsystem needs to be initially determined
(by some external agency) to perform properly.
• e.g., using program verification technique
– Ensure that subsystem cannot be corrupted to
perform in a manner contrary to the original
determination.
57

57

Biba: Integrity Levels

• Each subject (program) has an integrity
level
– reflects confidence in the program executing
correctly (what does “correctly” mean?)
• Each object has an integrity level
– reflects degree of confidence in the data
• quality of info in an object vs. importance of
an object
• Integrity levels are totally ordered
• Integrity levels different from security
levels
– a highly sensitive data may have low integrity 58
(e.g., information collected by spy)
58

29
 Five Mandatory Policies in Biba

• Strict integrity policy

• Subject low-water mark policy
• Object low-water mark policy
• Low-water mark Integrity Audit Policy
• Ring policy

59

59

Strict Integrity Policy

• Rules:
– s can read o iff i(s) ≤ i(o)
• no read down
• stops indirect sabotage by contaminated data
– s can write to o iff i(o) ≤ i(s)
• no write up
• stops directly malicious modification
• Ensures no information path from low-
integrity object to high-integrity object
– Why is this desirable? 60

60

30
 Subject Integrity Levels

• What does it mean that a subject is trusted

to execute correctly at integrity level i1?
• Three possibilities:
– Generate information at level i1 from any data
– Generate information at level i1 when reading
data of integrity level i1 or higher
– Generate information at any level i ≤ i1 when
reading data of integrity level i or higher

61

61

Object Integrity Levels

• An object integrity level may be based on

– Quality of information (levels may change)
– Importance of the object (levels do not change)
• Intuitively, quality integrity level should be
at least as high as importance integrity level
• Quality integrity level may be higher than
importance integrity level

62

62

31
 Subject Low-Water Policy
• Subject’s integrity level decreases as
reading lower integrity data
• The reading rule is relaxed:
– When s reads o, the integrity level of s is set to
min[i(s), i(o)]
– Can read down, but lower integrity level
– If the integrity levels are not totally ordered,
then glb[i(s), i(o)]
• Ensures that there is no information path
from low integrity data to high integrity
data 63

63

Object Low-Water Mark Policy

• The writing rule is relaxed:

– When s writes o, the integrity level of o is set to
min[i(s),i(o)]
– Implies that object integrity level represents
quality rather than importance
• Also ensures that there is no information
path from a low integrity object to a high
integrity object

64

64

32
 Low-Water Mark Integrity Audit Policy

• The integrity levels of subjects and objects

both change to reflect the contamination
– After s observes o, the integrity level of s is
lowered to min(i(s), i(o))
– After s modifies o, the integrity level of o is
lowered to min(i(s), i(o))

65

65

The Ring Policy

• Integrity levels of subjects and objects are

fixed
• Rules
– Any subject can read any object
– s can write to o iff i(o) ≤ i(s)
• Intuitions
– subjects are trusted to process inputs correctly,
and to generate outputs of a certain integrity
level
66

66

33
 Summary of Biba’s Policies

• Different policies assume different kinds of trust

in subjects
– The ring model assumes subjects can correctly process
inputs and generate data of a certain integrity level
– The low-water mark models assume subjects do not
introduce low integrity information themselves, but
may be contaminated by the source
– The strict integrity model assumes subjects may be
contaminated by the source and can only generate data
of a certain integrity level

67

67

Key Difference between Confidentiality

and Integrity
• For confidentiality, no trust needs to be
placed on subjects
– Theoretically, no subject needs to be trusted for
confidentiality; however, one does need trusted
subjects in BLP to make system realistic

• For integrity, one has to trust subjects

– Therefore, one has to justify such trust

68

68

34
 Clark-Wilson Commercial Security Policy
 In commercial environment, preventing unauthorized
data modification is usually paramount
» No user of the system, even if authorized, may be permitted
to modify data items in such a way that assets or accounting
records of the company are lost or corrupted
 Introduce the notion of well-formed transactions

69

69

Clark-Wilson Commercial Security Policy

 Example
» A purchasing agent creates an order, and sends the order to
the supplier and the receiving department

» The supplier ships the goods. The receiving department

receives and checks the delivery, and signs the delivery form,
which then goes to the accounting department

» The supplier sends an invoice to the accounting department.

An accountant compares the invoice with the order and the
delivery form, and issues a check to the supplier
70

70

35
 Clark-Wilson Commercial Security Policy
• Well-formed transactions
– Date items must satisfy some integrity constraints
• Constrained Data Items (CDIs)
– Perform the steps in order
– Perform exactly the steps listed
– Authenticate the individuals who perform the steps
– Can manipulate data only through trusted code!
• Called Transformation Procedures (TPs)
• Policy defined in terms of access triples
– <userID, TP, {CDIs}>
– Combine a transformation procedure, one or more
constrained data items, and the identification of 71
authorized user
71

Separation of Duty

• Required division of responsibilities

– Also a part of Clark-Wilson model
• Examples
– Different people must issue orders, receiver
goods, and write checks
– Any check with amount over $100,000 must
have two separate authorization signatures from
designated officials

72

72

36
 Clark-Wilson Model (Cont’d)

• Mechanisms are needed to ensure

– A data item can be manipulated only by a specific set of
programs
– Programs must be inspected for proper construction;
controls must be provided on the ability to install and
modify these programs
– Each user must be permitted to use only certain sets of
programs
– Assignment of people to programs must be controlled
and inspected

73

73

Differences from Other Models

• A data item is not associated with a
particular security level, but rather with a
set of trusted parties.

• A user is not given read/write access to data

items, but rather permissions to execute
certain programs

74

74

37
 The Clarke-Wilson Model for Integrity (1)
• Unconstrained Data Items (UDIs)
– data with low integrity
• Constrained Data Items (CDIs)
– data items within the system to which the
integrity model must apply
• Integrity Verification Procedures (IVPs)
– confirm that all of the CDIs in the system
conform to the integrity specification
• Transformation Procedures (TPs)
– well-formed transactions 75

75

The Clarke-Wilson Model for Integrity (2)

• C1: (Certification) All IVPs must properly

ensure that all CDIs are in a valid state at
the time the IVP is run

• C2: All TPs must be certified to be valid.

That is, they must take a CDI to a valid final
state, given that it is in a valid final state to
begin with. For each TP, the security officer
must specify the set of CDIs that the TP has
been certified 76

76

38
 The Clarke-Wilson Model for Integrity (3)

• E1: (Enforcement) The system must ensure

that only TPs can access CDIs and any TP
can only access the CDIs it is certified for

• E2: The system must maintain a relation of

the form, (UserID, TPi, (CDIa, CDIb,
CDIc,…). A user can only execute TPs that
it is allowed to access
77

77

The Clarke-Wilson Model for Integrity (4)

• C3: The relation in E2 must be certified to

meet the separation of duty requirement

• E3: The system must authenticate the identity

of each user attempting to execute a TP

78

78

39
 The Clarke-Wilson Model for Integrity (5)
• C4: All TPs must be certified to write to an
append-only CDI (the log) all information
necessary to permit the nature of the
operation to be reconstructed

• C5: Any TP that takes a UDI as input must

be certified to perform only valid
transformations, or no transformations, for
all possible values of the UDI. The
transformation either rejects the UDI or
transforms it into a CDI 79

79

The Clarke-Wilson Model for Integrity (6)

• E4: Only the agent permitted to certify

entities may do so. An agent that can
certify entity (TP or CDI) may not have any
execute rights with respect to that entity.

80

80

40
 Mandatory Access Control

• Mandatory access controls (MAC) restrict

the access of subjects to objects based on a
system-wide policy
– Denying users full control over the access to
resources that they create
– The system security policy (as set by the
administrator) entirely determines the access
rights granted

81

81

Multi-Level Security (MLS)

• The capability of a computer system to

– Carry information with different sensitivities
– Permit simultaneous access by users with
different security clearances and needs-to-
know, and
– Prevent users from obtaining access to
information for which they lack authorization
• Typically use MAC
• Primary Security Goal: Confidentiality
82

82

41
 Why MAC is Necessary -- Inherent
Weakness of DAC
• Unrestricted DAC allows information from
an object which can be read to any other
object which can be written by a subject
– Do not provide multi-level security
• Suppose our users are trusted not to do this
deliberately. It is still possible for Trojan
Horses to copy information from one object
to another
83

83

Discretionary versus Mandatory

 Discretionary access controls (DAC) allow access

rights to be propagated from one subject to another
Possession of an access right by a subject is sufficient
to allow access to the object
 Mandatory access controls (MAC) restrict the access
of subjects to objects on the basis of security labels

84

84

42
 Inherent weakness of DAC

 Unrestricted DAC allows information to be copied from

an object which can be read to any other object which
can be written by a subject
 Suppose our users are trusted not to do this deliberately.
It is still possible for Trojan Horses to copy information
from one object to another.

85

85

Role-Based Access Control (RBAC)

 Role-based access control (RBAC), as the name
suggests, sets up user permissions based on roles.
 Each role represents users with similar or identical
permissions.
 Role-based access control provides each worker
privileges based on what role they have in the
organization.
 Only Human Resources staff have access to personnel files, for
example; only Finance has access to bank accounts; each
manager has access to their own direct reports and their own
department.
 Very high-level system administrators may have access to
everything; new employees would have very limited access, the86
minimum required to do their jobs.
86

43
 Role-Based Access Control (RBAC)
 Access depends on function, not identity
 Example:
» Allison, bookkeeper for Math Dept, has access to financial
records.
» She leaves.
» Betty hired as the new bookkeeper, so she now has access
to those records
» The role of “bookkeeper” dictates access, not the identity of
the individual.

87

87

Roles
 Role:
» many-to-many relation between users and permissions
» Corresponds to a well-defined job or responsibility
 When a user starts a session, he can activate some or
all of his roles
 A session has all the permissions associated with the
activated roles

88

88

44
 RBAC advantage
• For each job position, let:
U  Number of individuals in job position
P  Number of permissions required for job position
(U  P )  (U  P )  RBAC advantage
U , P  2  (U  P )  (U  P )

89

89

RBAC (NIST standard)

UA PA
Users Roles Operations Objects

Permissions
user_sessions role_sessions
(one-to-many) (many-to-many)

Sessions

90

90

45
 Core RBAC (relations)
 Users: set of users
 Roles: set of roles
 Operations: set of operations
 Objects: set of objects
 UA ⊆ Users x Roles
 assigned_users: Roles  2Users
» assigned_users(r) = { u  Users | (u, r) UA}
 PRMS = 2Operations x Objects
 PA ⊆ PRMS x Roles
 assigned_permissions: Roles  2PRMS
» assigned_permissions(r) = { p PRMS | (p, r) PA}
 subject_user: Subjects  Users
 subject_roles: Subjects  2Roles
» subject_roles(s) = {r | (subject_user(s), r)  UA)}
91

91

Axioms
 Rule of role authorization:
(s  Subjects)(u  Users)(r  Roles)
r  subject_roles(s)  u  subject_users(s) 
u  assigned_users(r)
» A subject can never have an active role that is not authorized
for its user

92

92

46
 Axioms
 Definition:
access: Subjects x Operations x Objects  BOOLEAN
access(s, op, o) = 1 if subject s can access object o using
operation op; 0 otherwise
 Rule of object access authorization:
(s  Subjects)(op  Operations)(o  Objects)
access(s, op, o)  (r  Roles)(p  PRMS)
[r subject_roles(s)  p  assigned_permissions(r)  (op, o) p]
» A subject s can perform an operation op on object o only if
there exists a role r that is included in the subject’s active role
set and there exists a permission that is assigned to r such
that the permission authorizes operation op on o
93

93

Role Hierarchies
 Reflect enterprise structure
» Partially ordered set of roles (R, 6)
 Used to further reduce the number of user- and
permission-role assignments
» If (u, r) 2 UA then u is (implicitly) assigned to all roles
s6r
» If (p, r) 2 PA then p is (implicitly) assigned to all roles
s>r

94

94

47
 A typical role hierarchy
 If Jason is assigned to PL1
then he can also activate all
roles less senior than PL1
 If permission p is assigned to
QE1 then it can also be used
by any role more senior than
QE1
 Jason can use p

95

95

RBAC with Role Hierarchy

RH
(role hierarchy)

UA PA
Users Roles Operations Objects

Permissions
user_sessions role_sessions
(one-to-many) (many-to-many)

Sessions

96

96

48
 RBAC with Role Hierarchy
 authorized_users: Roles 2Users
authorized_users(r) = {u | r’ ≥ r  (r’, u)  UA)
 authorized_permissions: Roles 2PRMS
authorized_users(r) = {p | r’ ≥ r  (p, r’)  PA}
 RH ⊆ Roles x Roles is a partial order
» called the inheritance relation
» written as ≥.
(r1 ≥ r2)  authorized_users(r2) ⊆ authorized_users(r1) &
authorized_permisssions(r1) ⊆ authorized_permisssions(r2)

97

97

Separation of Duty
 No single user possesses all the permissions
needed to perform a sensitive task
 Prevents accidental or malicious violation of
business requirements
 Examples
» A cheque must be raised and authorised by two
different people
» A nuclear missile must be armed and launched by two
different people

98

98

49
 Varieties of Separation of Duty
 Static SoD
» No user can have the opportunity to access both file1
and file2
» Based on configuration of system
 Dynamic SoD
» No user can have access to both file1 and file2 at the
same time
» Based on current state of system
 Historical SoD
» No user can have accessed both file1 and file2
» Based on all previous states of the system

99

99

Constrained RBAC
RH
Static (role hierarchy)
Separation
of Duty

UA PA
Users Roles Operations Objects

Permissions
user_sessions
(one-to-many) Dynamic
Separation
of Duty
Sessions

100

100

50
 Constrained RBAC: Static SoD
 SSD ⊆ 2Roles x N is a collection of pairs (rs, n)
» rs: role set
» n: n ≥ 2 is a natural number
 For each (rs, n) in SSD no user is authorized for
n or more roles in rs

101

101

SoD with Role Hierarchies

 Two roles can be mutually exclusive only if
neither one inherits the other
 If two roles are mutually exclusive, no role
can inherit from both
 If two roles are mutually exclusive, there can
be no “root” or “super user”.

102

102

51
 Constrained RBAC: Dynamic SoD
 DSD ⊆ 2Roles x N is a collection of pairs (rs, n)
» rs: role set
» n: n ≥ 2 is a natural number
 For each (rs, n) in SSD no user is allowed to
activate n or more roles in rs in one session

103

103

Harrison-Ruzzo-Ullman Model
 In HRU model, a configuration (or state) of a protection
system is defined as a triple (S,O,A), where S is the set
of current subjects, O is the set of current objects S O,
and A is an access matrix, with a row for every subject
in S and a column for every object in O.
 A[s,o] is a subset of R, the finite set of generic rights,
and gives the rights to object o possessed by subject s.

104

104

52