Access Control

 Today we will start to cover Access Control

– material is from Gollmann’s Computer Security
book (Chapter 3 and partially 4) (most slides are
from his course too)
• I will provide handouts before the final exam
 A bit theoretic concept
– because it is more than read, write, execute
 But still an operating system related concept
– the resources are to be accessed but by whom?
– access control paradigms center around this
question
1
A Model for Access Control

access reference
subject object
request monitor

source request guard resource

(e.g. users, (e.g. files,
processes) printers)

2
Basic Terminology
 Subject/Principal: active entity – user or
process
 Object: passive entity – file or resource
 Access operations: read, write, ...
– Access operations vary from basic
memory/file access to method calls in an
object-oriented system.
– Comparable systems may use different
access operations.
3
Authorization
 Access control decision is actually an
authorization decision
 if o is an object, authorization answers
the question “Who is trusted to access
o?”

4
Simple analogy
 Consider a paper-based office in which
certain documents should only be read
by certain individuals
 We could implement access control by
– storing documents in filing cabinets
– issuing keys to the relevant individuals for
the appropriate cabinets

5
Simple analogy
 The reference monitor is the set of
locked filing cabinets
– An access request (an attempt to open a
filing cabinet) is granted if the key fits the
lock (and denied otherwise)

6
Options for Focusing Control
 Subjects and objects provide a different focus
of control
 What is the subject allowed to do?
 What may be done with an object?
 Traditionally, multi-user operating systems
manage files and resources, i.e. objects
– Access control takes the second approach
 Application oriented IT systems, like DBMSs,
offer services for the user and control the
actions of subjects.
7
 Elementary access operations
 On the most elementary level, a subject may
• observe an object, or
• alter an object.
 We refer to observe and alter as access modes.
 The four Bell-LaPadula (BLP) access rights:
• execute
• read
• append, also called blind write
• write

8
BLP Access Rights and Modes
 Mapping between access rights and access
modes. execute append read write
observe X X
alter X X
 Write access usually includes read access. Hence, the write
right includes observe and alter mode.
 Few systems implement append. Allowing users to alter an
object without observing its content is rarely useful
(exception: audit log).
 A file can be used without being opened and read.
Example: use of a cryptographic key. This can be expressed
by an execute right that includes neither observe nor alter
mode.
9
 Unix
 Access control  Applied to a directory, the
expressed in terms access operations take
of three operations: different meanings:
 read: list contents
 read: from a file
 write: create, delete or
 write: to a file
rename files in the
 execute: a file directory
 execute: search directory

 These operations differ from the Bell-LaPadula model. Unix write

access does not imply read access
 Unix controls who can create and delete files by controlling the write
access to the file’s directory
10
Windows NT Family
 Permissions
– read, write, execute, delete, change
permission, change ownership
 file deletion and change of permissions
are not directory operations
 Terminology for access right
manipulation
– grant / revoke – if done by other party
– assert / deny – if done by the owner itself
11
Ownership
 Ownership is an aspect often
considered in access control rules.
 When a new object is created, in many
operating systems the subject creating
the object becomes its owner.

12
Who Sets the Policy?
Security policies specify how subjects access
objects. There are two mechanisms for deciding
who is in charge of setting the policy:
 The owner of a resource decides who is
allowed access. Such policies are called
discretionary as access control is at the
owner’s discretion.
 A system wide policy decides who is allowed
access. Such policies are called mandatory.

13
Access Control Structures
 Requirements on access control structures:
– The access control structure should help
to express your desired access control
policy.
– You should be able to check that your
policy has been captured correctly.
 Access rights can be defined individually for
each combination of subject and object.
 For large numbers of subjects and objects,
such structures are cumbersome to manage.
– Intermediate levels of control are preferable.

14
Access Control Matrix
 S … set of subjects
 O … set of objects
 A … set of access operations
 Access control matrix: M = (Mso)sS,oO,
Mso  A; Mso specifies the operations subject
s may perform on object o.

bill.doc edit.exe fun.com

Alice {} {exec} {exec,read}
Bob {read,write} {exec} {exec,read,write}
15
Access Control Matrix ctd.
 The access control matrix is
– an abstract concept
– not very suitable for direct
implementation
• Management of the matrix is likely to be
extremely difficult if there are ten thousands of
files and hundreds of users (resulting in millions
of matrix entries)
• The matrix is likely to be extremely sparse and
therefore implementation is inefficient
16
 Capabilities
 Focus on the subject
– access rights are stored with the subject
– capabilities  rows of the access control matrix

Alice edit.exe: {exec} fun.com: {exec,read}

 Good match between capabilities and distributed

system security
– Security policies have to deal with roaming
 Problems of capabilities
– How to check who may access to a specific object?
– How to revoke a capability?
17
Protection and Authenticity of
Capabilities
 If used in a single system
– you may rely on the operating system’s
integrity and mechanisms employed by it
 If used over a network
– authenticity and protection is mostly
cryptographic

18
 Access Control Lists (ACLs)
 Focus on the object
– access rights are stored with the object
– ACLs  columns of the access control matrix
fun.com Alice: {exec} Bill: {exec,read,write}
 Access rights are often defined for groups of users
– because individual subjects may create a huge list
 ACLs are typical for operating systems security
– In UNIX, ACLs are attached to files

19
Aggregation Techniques
 ACLs and capability lists are of limited
use (one focuses on subjects, the other
focuses on objects)
 need to aggregate subjects and objects

• Groups
• Roles
• Procedures Role-based Access Control
• Data types
20
 Groups & Negative Permissions
 Groups are an intermediate layer between users
and objects. users

groups

objects
 To deal with special cases, negative permissions
withdraw rights
users

groups

objects
21
Role-Based Access Control
(RBAC)
 Several intermediate concepts can be inserted
between subjects and objects

subjects

roles

procedures
data types
objects
22
Role Based Access Control (RBAC)
 Data types: A data type is a set of objects with
the same structure (e.g. bank accounts)
– each object is of a certain data type and can be
accessed only through procedures defined for this
data type.
 Procedures: high level access control methods
with more complex semantics than read or write
– procedures can only be applied to objects of certain
data types; example: funds transfer between bank
accounts.
 Roles: collection of procedures assigned to
roles; a user can have more than one role and
more than one user can have the same role.
23
 Example
 Objects are bank  We define procedures for
accounts – Crediting accounts (CA)
 Subjects are bank – Debiting accounts (DA)
employees – Transferring funds between
accounts (TF)
 The set of bank
– Creating new accounts (NA)
accounts forms a data
 We assign procedure
type
– CA and DA to the Teller role
 We define roles – TF to the Clerk role
– Teller – NA to the Administrator role
– Clerk – The Administrator role can run all
– Administrator the procedures

24
 RBAC continued
 Roles are a good match for typical access
control requirements in businesses
 Roles implemented in
– Window NT onwards (as global and local groups)
– IBM’s OS/400
– Oracle
– .NET framework
 There is no generally accepted standard for
RBAC
25
RBAC – a quote
“The term RBAC itself does not have a
generally accepted meaning, and it is used
in different ways by different vendors and
users”
R. Sandhu, D. Ferraiolo, and R. Kuhn: The
NIST Model for Role-Based Access
Control: Towards a Unified Standard,
Proceedings of the 5th ACM Workshop on
Role-Based Access Control, Berlin,
Germany, July 26-27, 2000
26
Security Labels and Partial
orderings
 In several approaches to access control,
functions are used to associate entities with a
security label
– a value that can be compared using an operator
 We can use a set L of security labels.
– We need a way of comparing labels but we need
not compare any pair of labels.
 A data structure with the property that some,
but not all, elements can be compared is
called a partial ordering.
27
Partial orderings
 A partial ordering  (read as ‘less or equal’ –
but not necessarily numeric comparison) on a
set L is relation on LL that is
 reflexive: for all aL, aa
 transitive: for all a,b,cL, if ab and bc, then ac
 antisymmetric: for all a,bL, if ab and ba, then
a=b
 Examples for partial orderings
– the integers with the relation ‘is divided by’
– a power set P(C) with the subset relation 
28
29
30
31
32
 Lattices
 General Rule: a subject may observe an object only if
the subject’s label is higher than or equal to the object’s
label.
 Lattices are a mathematical structure where these
questions have unique answers
 Given two objects with different labels, what is the minimal
label a subject must have to be able to observe both objects?
 Given two subjects with different labels, what is the maximal
label an object can have so that it can be observed by both
subjects?
 A lattice is a partially ordered set in which every pair of
elements has a greatest lower bound and a least upper
bound

33
 System Low and System High
 If a  b, we say ‘a is dominated by b’ or
‘b dominates a’.
 If a label exists that is dominated by all
other labels, it will be called System Low.
 If a label exists that dominates all other
labels, it will be called System High.
 What are System Low and System High in
the power set lattice example?
34
 root

uid1 uid2 uid3

guest

A ‘flat’ lattice

35
Models & Policies
 A security policy captures the security
requirements of an enterprise or
describes the steps that have to be
taken to achieve security
 A security model is a formal description
of a security policy
 Bell-LaPadula (BLP) model is the most
famous one
36
Information flow policies
 To address confidentiality requirements
 We assume the existence of a lattice of
security labels
 Every subject and object is assigned a security
label using a security function 
 Information can flow from an entity x to an
entity y if (x) <= (y)
– information can flow from low security entity to
high security one
 Read and write access rights are defined in
terms of information flow principles
37
Read Access
 Information flow from an object o to a
subject s
 Read access is granted if (o) <= (s)
– you can read an object if your security
label is larger than the object’s
 This condition is known as “no read up”
or the simple security (ss) property in
BLP terms
38
Write Access
 Information flow from a subject s to an object o
 Write access is granted if (s) <= (o)
– you can write to an object if your security label is
smaller than object’s
– quite counter-intuitive, but necessary to prevent
confidentiality violations such as
• a top secret user writing to an insecure printer
 This condition is known as “no write down” or
the -property (star property) in BLP terms
 No read-up and no write-down properties are
“mandatory access control” policies of BLP

39
Information flow blocked by -property

read
1 2
Trojan copy
Not
allowed
3 due to *-
property
read

A Trojan aims to read a high document and copy its

contents to a low file.
40
 No Write-Down
 The  - property prevents high level entities from
sending legitimate messages to low level entities
 Two ways to escape from this restriction:
– Temporarily downgrade a high level subject;
(downgrade current security level); BLP
subjects should have no memory of their own!
They have to forget what they knew when
downgraded
• Possible with processes, but not for human beings :)
– Identify trusted subjects which are permitted to
violate the -property.
• We redefine the -property and demand it only for
subjects, which are not trusted.
41
Discretionary Security Policy
 Mandatory access control properties (ss and *
properties) do not check whether a particular
access is specifically permitted
 Discretionary Security Property (ds-property)
– Defines the capability of a subject to operate on an
object

In BLP, access must be permitted by

the access control matrix Mso.

42
 Multi level security (MLS)
 MLS: access control based on a partial ordering
(actually a lattice) of security levels

 Traditional: hierarchical top secret

security levels (linear order):
secret

confidential

unclassified

43
 Compartments
 In multi-level security, generally categories are used
as well as the security levels in lattices
 C is a set of all categories, e.g. project names, company
divisions, academic departments, etc.
 A compartment is a set of categories (a subset of C).
 H is a set of security levels which are hierarchically
ordered.
 A security label (the function ) is a pair (h,c), where h 
H is a security level and c  C is a compartment.
 The partial ordering  is defined by (h1,c1)  (h2,c2) if and
only if h1  h2 and c1  c2 .
44
 Compartments - Example
 Two hierarchical levels:
– public, private (public  private)
 Two categories: PERSONNEL, ENGINEERING
 For examples, the following relations hold:

(public, {PERSONNEL})  (private, {PERSONNEL})

(public, {PERSONNEL})  (public,{PERSONNEL,ENGINEERING})

 But the following one cannot be compared

(public, {PERSONNEL})  (private, {ENGINEERING})

45
Corresponding Lattice

46
The Bell-LaPadula Model
 Implements an information flow policy using a
lattice with compartments and an access
control matrix
 An example: evaluating a read access request
in BLP
– A read access request by subject s to object o is
granted if
 (o) <= (s) (information flow policy) and
• r  M [s, o] (appropriate entry in the access control matrix)
 BLP model actually a state machine
47
 State Machine Models
 State machines (automata): popular tool for modelling
many aspects of computing systems including security.
 The essential features of a state machine model are the
concepts of a state and of state transitions.
– A state is a representation of the system under investigation at one
moment in time. It should capture exactly those aspects of the
system relevant to the problem.
– The state transition (next state) function defines the next state
depending on the present state and the input. An output may also
be produced.
 To design a secure system with the help of state machine
models:
– define state set so that it captures “security”
– check that initial state of the system is ‘secure’
– check that all state transitions starting in a “secure”
state yield a “secure” state
 Security is then preserved by all state transitions. The
system will always be ‘secure’.
48
States in BLP model
 A state in BLP model is
– the current subjects, objects and access
matrix among them and
– the security levels of subjects and objects
– current accesses by subjects to objects

49
 Basic Security Theorem
 A state is secure, if all current access tuples
(s,o,a) are permitted by the ss-, -, and ds-
properties.
 A state transition is secure if it goes from a
secure state to a secure state.
 How would you define state transition in BLP?

Basic Security Theorem: If the initial state of

a system is secure and if all state transitions are
secure, then the system will always be secure.
50
Harrison-Ruzo-Ullman Model
 BLP has no policies for changing access rights or for
the creation and deletion of subjects and objects.
 The Harrison-Ruzzo-Ullman (HRU) model defines
authorization systems that address these issues.
 The components of the HRU model:
– set of subjects S
– set of objects O
– set of access rights R
– access matrix M = (Mso)sS,oO : entry Mso is a
subset of R giving the rights subject s has on
object o
51
Primitive Operations in HRU
 Six primitive operations for manipulating subjects,
objects, and the access matrix:
– enter r  R into Mso
– delete r  R from Mso
– create subject s
– delete subject s
– create object o
– delete object o

52
 Examples
 Subject s creates a file f  The owner s of file f
so that s owns the file grants read access to
(access right o) and has another subject p
read and write
permission to the file
(access rights r and w). command grant_read(s,p,f)
if o in Ms,f
command create_file(s,f) then enter r in Mp,f
create f
end
enter o into Ms,f
enter r into Ms,f
enter w into Ms,f
end

53
 Security vs. Complexity in
HRU Model
 The access matrix describes the state of the system;
commands change the access matrix.
 HRU can model policies for allocating access rights. To
verify compliance with a given policy, you have to check
that no undesirable access rights can be granted.
 HRU model has some definitions and theorems about
the decidability of the safety of the system
– Saying that HRU model does not help to verify safety
in its full generality, but verification is possible with
some restrictions
 The moral of those theorems is:
– The more expressive and complex the security
model, the more difficult to verify security
54