Lesson 5: Access Control in
Computer Security
Access Control
▪ Today we will start to cover Access Control
– material is from Gollmann’s Computer Security
book (Chapter 5) (most slides are from this book)
▪ A bit theoretical 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
A Model for Access Control
access reference
subject object
request monitor
source request guard resource
(e.g. users, (e.g. files,
processes) printers)
3
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.
4
Authorization
▪ Access control decision is actually an
authorization decision
▪ if o is an object, authorization answers
the question “Who is trusted to access
o?”
5
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
6
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)
7
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.
8
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
9
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.
10
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
11
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
12
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.
13
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.
14
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.
15
Access Control Matrix
▪ S … set of subjects
▪ O … set of objects
▪ A … set of access operations
▪ Access control matrix: M = (Mso)sS,oO,
Mso A; Mso specifies the operations subject
s may perform on object o.
[Link] [Link] [Link]
Alice {} {exec} {exec,read}
Bob {read,write} {exec} {exec,read,write}
16
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
17
Capabilities
▪ Focus on the subject
– access rights are stored with the subject
– capabilities rows of the access control matrix
Alice [Link]: {exec} [Link]: {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?
18
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
19
Access Control Lists (ACLs)
▪ Focus on the object
– access rights are stored with the object
– ACLs columns of the access control matrix
[Link] 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
20
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
21
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
22
Role-Based Access Control
(RBAC)
▪ Several intermediate concepts can be inserted
between subjects and objects
subjects
roles
procedures
data types
objects
23
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.
24
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
25
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
26
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
27
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
37
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
38
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
39
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
40
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.
41
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.
42
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.