Access Control Models: From the real-world to trusted computing potx

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


Access control to memory and generic objects
–
Discretionary Methods: Directory Lists, Access Control
Lists, and the Access Control Matrix, Take-Grant Model
–
Failures of DACs: Trojan Horses
–
Dominance and information flow, Multilevel security and
lattices
–
Bell-LaPadula and Biba’s Model

What is a trusted system? Trusted Computing Base
System-security vs. Message-security
System-security vs. Message-security

In the cryptographic formulation of security, we were concerned with the
confidentiality, authenticity, integrity, and non-repudiation of messages
being exchanged
–
This is a message-level view of security

A system-level view of security has slightly different issues that need to be
considered
–
Confidentiality: Concealment of information or resources from those
without the right or privilege to observe this information
–
Integrity: Trustworthiness of data (has an object been changed in an

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:

–
Data integrity (is the content unmodified?)
–
Origin integrity (is the source of the data really what is claimed, aka.
Authentication)

Two classes of integrity mechanisms: Prevention and Detection

Prevention: Seek to block unauthorized attempts to change the data, or
attempts to change data in unauthorized ways
–
A user should not be able to change data he is not authorized to change
–
A user with privileges to work with or alter the data should not be
allowed to change data in ways not authorized by the system
–
The first type is addressed through authentication and access control
–
The second type is much harder and requires policies

Detection: Seek to report that data’s integrity has been violated
–
Achieved by analyzing the system’s events (system logs), or analyze
data to see if required constraints are violated
Availability of Systems
Availability of Systems

Availability is concerned with system reliability
–
The security side of the issue: An adversary may try to make a resource

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


Examples:
–
Snooping: Unauthorized interception of information (passive Disclosure)
–
Modification/Alteration: Unauthorized change of information (active
Deception, Disruption, Usurpation)
–
Masquerading/Spoofing: Impersonation of one entity by another
(Deception and Disruption)
–
Repudiation of Origin: False denial that an entity sent or created data
(Deception)
–
Denial of Receipt: A false denial that an entity received some information
or message (Deception)
–
Delay: A temporary delay in the delivery of a service (Usurpation)
–
Denial of Service: A long-term inhibition of service (Usurpation)
Overview Security Policies
Overview Security Policies

Definition: A security policy is a statement of what is allowed and what is
not allowed to occur between entities in a system

Definition: A security mechanism is a method for enforcing a security
policy

Policies may be expressed mathematically

–
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

entities to deal with… hard to keep every process/user happy when sharing
resources… Even harder if one user is malicious

Several objects that need protection:
–
Memory
–
File or data on an auxiliary storage device
–
Executing program in memory
–
Directory of files
–
Hardware Devices
–
Data structures and Tables in operating systems
–
Passwords and user authentication mechanisms
–
Protection mechanisms
Basic Strategies for Protection
Basic Strategies for Protection

There are a few basic mechanisms at work in the operating system that
provide protection:
–
Physical separation: processes use different physical objects (different
printers for different levels of users)
–
Temporal separation: Processes having different security requirements

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

–
Tagged architectures: Every word of machine memory has one or more
extra bits to identify access rights to that word (these bits are set only by
privileged OS operations)
–
Segmentation: Programs and data are broken into segments. The OS
maintains a table of segment names and their true addresses. The OS
may check each request for memory access when it conducts table
lookup.

More general objects may be accessed from a broader variety of entry points
and there may be many levels of privileges:
–
No central authority!
Insight from Real-world Security Models
Insight from Real-world Security Models

Not all information is equally sensitive– some data will have more drastic
consequences if leaked than other.
–
Military sensitivity levels: unclassified, confidential, secret, top secret

Generally, fewer people knowing a secret makes it easier to control
dissemination of that information
–
Military notion of need-to-know: Classified information should not be
entrusted to an individual unless he has both the clearance level and the
need to know that information
–
Compartments: Breaking information into specific topical areas

(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.


The military has developed various models for securing information

We will look at several models for multilevel security
–
Object-by-Object Methods: Directory lists, Access control lists, Access
control matrix, Take-Grant Model
–
Lattice model: A generalized model
–
Bell-LaPadula Model
–
Biba Model
Access Control to Objects
Access Control to Objects

Some terminology:
–
Protection system: The component of the system architecture whose task
is to protect and enforce security policies
–
Object: An object is an entity that is to be protected (e.g. a file, or a
process)
–
Subject: Set of active objects (such as processes and users) that have
interaction with other
–
Rights: The rules and relationships allowed to exist between subjects and
objects


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,

Execute,Own Write
Process2 Append Read,Own Read
Read,Write,
Execute,Own
Access Control Matrix, pg. 2
Access Control Matrix, pg. 2

All accesses to objects by subjects are mediated by an enforcement
mechanism that uses the access matrix
–
This enforcement mechanism is the reference monitor.
–
Some operations allow for modification of the matrix (e.g. owner might
be allowed to grant permission to another user to read a file)
–
Owner has complete discretion to change the access rules of an object it
owns (discretionary access control)

The access control matrix is a generic way of specifying rules, and is not
beholden to any specific access rules
–
It is therefore very flexible and suitable to a broad variety of scenarios
–
However, it is difficult to prove assertions about the protection provided
by systems following an access control matrix without looking at the
specific meanings of subjects, objects, and rules
–
Not suitable for specialized requirements, like the military access control
model.
Take-Grant Models

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

r, w
r, w
Grant Operation:
Take-Grant Models, pg. 2
Take-Grant Models, pg. 2

Create Rule: A subject A can
create a new graph G
1
from an old
graph G
0
by adding a vertex B and
an edge from A to B with rights set
X.

Remove Rule: Let A and B be
distinct vertices. Suppose there is
an edge with rights X. Rules Y
may be removed from X to
produce X\Y. If X\Y is empty, the
edge is deleted.
A B
X={r,g}
Create Operation:
Delete Operation:
A B
X={r,g}
A B
X\Y={r}

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

A B C
t
X
V
3. B grants to V the X to C
g
X
A B C
t
X
V
4. A takes X to C from V
g
X
{t,g}
X
Problems with Discretionary Access Control
Problems with Discretionary Access Control

Discretionary access controls are inadequate for enforcing information flow
policies
–
They provide no constraint on copying information from one object to
another

Example: Consider Alice, Bob, and Eve. Alice has a file X that she wants
Bob to read, but not Eve.
–
Alice authorizes Bob via the following Access Control Matrix
–

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

“claimed” operations, but also
participates in subversive activities
 FileX FileY Prog.Troy
Alice Own  
Bob Read Write Execute
Eve  Read
Read,
Write,
Execute
Prog.Troy Read Write 
Solution:
Impose Mandatory Access
Controls (MAC… yes, another
MAC!) that cannot be bypassed.
Dominance and Information Flow
Dominance and Information Flow

There are two basic ways to look at the notion of security privileges:
Dominance and Information Flow.

For all essential purposes, they are the same, and its just a matter of semantics.

Let’s start with dominance:
–
Each piece of information is ranked at a particular sensitivity level (e.g.
unclassified, confidential, secret, top secret)
–
The ranks form a hierarchy, information at one level is less sensitive than
information at a higher level.
–

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

NOT
 →
BA →
CBA =⊕