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

Lecture Outline Some generic discussion about security  Objects that require protection  Insights from the real-world  Access control to memory and generic objects – Discretionary Me

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

– 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

 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

 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

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

 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

 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

 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

 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

 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

 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

 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

 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

 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 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

– 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

 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 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

Take-Grant Models, pg 2

 Create Rule: A subject A can

create a new graph G1 from

an old graph G0 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

X

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

 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

 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



o

s 

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