Access Control Models: From the
Access Control Models: From the
real-world to trusted computing
real-world to trusted computing
Lecture Motivation
Lecture Motivation

We have looked at protocols for distributing and establishing keys used for
authentication and confidentiality

But who should you give these keys to? Who should you trust? What are the
rules governing when to and not to give out security credentials

In this lecture, we will look at the broad area of secure and trusted systems
–
We will focus on access control models
–
These methods are often used to abstract the requirements for a
computer system
–
But, they hold for general systems where security is a concern (e.g.
networks, computers, companies…)
Lecture Outline
Lecture Outline

Some generic discussion about security

Objects that require protection

Insights from the real-world

unauthorized manner?)
–
Availability: Is the system and its resources available for usage?
Confidentiality in Systems
Confidentiality in Systems

Many of the motivations behind confidentiality comes from the military’s
notion of restricting access to information based on clearance levels and
need-to-know

Cryptography supports confidentiality: The scrambling of data makes it
incomprehensible.
–
Cryptographic keys control access to the data, but the keys themselves
become an object that must be protected

System-dependent mechanisms can prevent processes from illicitly
accessing information
–
Example: Owner, group, and public concepts in Unix’s r/w/x definition
of access control

Resource-hiding:
–
Often revealing what the configuration of a system is (e.g. use of a
Windows web server), is a desirable form of confidentiality
Integrity in Systems
Integrity in Systems

Integrity includes:

or service unavailable
–
Implications often take the form: Eve compromises a secondary system
and then denies service to the primary system… as a result all requests of
the first system get redirected to second system
–
Hence, when used in concert with other methods, the effects can be very
devastating

Denial of service attacks are an example:
–
Preventing the server from having the resources needed to perform its
function
–
Prevent the destination from receiving messages
–
Denial of service is not necessary deliberate
Threats
Threats

There are several threats that may seek to undermine confidentiality,
integrity, and availability:
–
Disclosure Threats: Causing unauthorized access to information
–
Deception Threats: Causing acceptance of false data
–
Disruption Threats: Prevention of correct operation of a service
–
Usurpation Threats: Unauthorized control of some service

–
Allowed and disallowed states may be specified
–
Rules may be formulated for which entity is allowed to do which action

These policies may seek to accomplish:
–
Prevention
–
Detection
–
Recovery

This lecture will focus primarily on formal statements of security policies
–
Specifically, we will focus on policies associated with access control and
information flow
Objects that Need Protection
Objects that Need Protection

Modern operating systems follow a multiprogramming model:
–
Resources on a single computer system (extend this to a generic system)
could be shared and accessed by multiple users
–
Key technologies: Scheduling, sharing, parallelism
–
Monitors oversee each process/program’s execution

Challenge of the multiprogramming environment: Now there are more

are executed at different time
–
Logical separation: Operating system constrains a program’s accesses
so that it can’t access objects outside its permitted domain
–
Cryptographic separation: Processes conceal their data in such a way
that they are unintelligible to outside processes
–
Share via access limitation: Operating system determines whether a
user can have access to an object
–
Limit types of use of an object: Operating system determines what
operations a user might perform on an object

When thinking of access to an object, we should consider its granularity:
–
Larger objects are easier to control, but sometimes pieces of large
objects don’t need protection.
–
Maybe break objects into smaller objects (see Landwehr)
Access Control to Memory
Access Control to Memory

Memory access protection is one of the most basic functionalities of a
multiprogramming OS

Memory protection is fairly simple because memory access must go through
certain points in the hardware
–
Fence registers, Base/Bound registers

(compartments) and using that as a component in deciding access
–
Security levels consist of sensitivity levels and the corresponding
compartments
–
If information is designated to belong to multiple compartments, then the
individual must be cleared for all compartments before he can access the
information.
Real-world Security Models, pg. 2
Real-world Security Models, pg. 2

Documents may be viewed as a collection of sub-objects, some of which are
more sensitive than others.
–
Hence, objects may be multilevel in their security context.
–
Level of classification of an object or document is usually the
classification of its most sensitive information it contains.

Aggregation Problem: Often times the combination of two pieces of data
creates a new object that is more sensitive than either of the pieces separately

Sanitization Problem: Documents may have sensitive information removed
in an effort to sanitize the document. It is a challenge to determine when
enough information has been removed to densensitize a document.
Multilevel Security Models
Multilevel Security Models

We want models that represent a range of sensitivities and that separate
subjects from the objects they should not have access to.

Directory-based Access Control (aka. Capability List): A list for each subject
which specifies which objects that subject can access (and what rights)

Access Control List: A list for each object that specifies which subjects can
access it (and how).
Access Control Matrix
Access Control Matrix

Access control matrix arose in both OS research and database research

Example:

What does it mean for a process to read/write/execute another process?
–
Read is to receive signals from, write is to send signals to, and execute is
to run as a subprocess

Formally, an access control matrix is a table in which each row represents a
subject and each column represents an object.
–
Each entry in the table specifies the set of access rights for that subject to
that object
–
In general access control matrices are sparse: most subjects do not have
access rights to most objects
–
Every subject is also an object!!!
 File1 File2 Process1 Process2
Process1 Read,Write,Own Read
Read,Write,

Take-Grant Models

Take-Grant Models represent a
system using a directed graph

Nodes in the graph are either
subjects or objects

An arc directed from node A to
node B indicates that the
subject/object A has some access
rights to subject or object B.

Access rights are: read (r), write
(w), take (t), grant (g)

Take implies that node A can take
node B’s access rights to any other
node

Grant implies that node B can be
given any access right A possesses
A B C
t
r, g
r, g
Take Operation:
A B
C
g

Take-Grant Models, pg. 3
Take-Grant Models, pg. 3

Since the graph only includes arcs corresponding to non-empty entries in the
access control matrix, the model provides a compact representation

Question of Take-Grant Models: Can an initial protection graph and rules be
manipulated to produce a particular access right for A to access C with?

Example:
A B C
t
X
A B C
t
X
X
A B C
t
X
V
1. A creates V with {t,g}
{t,g}
A B C
t
X
V
2. B takes g to V from A
{t,g}
g

Bob can subvert Alice’s discretion by copying X into Y. Bob has write
privileges, and Eve has read privileges for Y.
–
This case is a simplistic version of what can be much more
pathological… The Trojan Horse…
 FileX FileY
Alice Own 
Bob Read Write
Eve  Read
DAC and Trojan Horses
DAC and Trojan Horses

What if Bob isn’t bad… Eve could still
read X by convincing Bob to use a
program carrying a Trojan Horse
(Troy)

Consider the new access control
matrix:
–
Eve has created Troy and given it
to Bob, who has execute privileges
–
Troy inherits Bob’s read privileges
to X, and write privileges to a file
Y (perhaps public)
–
Eve has read privileges to file Y

Trojan Horses perform normal

Hence, higher level information dominates lower level information

Formally, we define a dominance relation on the set of objects and subjects
if:

We say that o dominates s (or s is dominated by o) if .
( )
osos
compcomp)rankrank(os ⊆∧≤⇔≤
≤
os ≤
Dominance and Information Flow, pg. 2
Dominance and Information Flow, pg. 2

Now let us look at information flow:
–
Every object is given a security class (or a security label):
Information flowing from objects implies information flowing
between the corresponding security classes
–
We define a can-flow relationship to specify that
information is allowed to flow from entities in security class A
to entities in security class B
–
We also define a class-combining operator
to specify that objects that contain information from security
classes A and B should be labeled with security class C
–
Implicitly, there is the notion of cannot-flow
BA