ACCESS CONTROL
Access Control
Concepts
Access Control
What is access control?
2
SECURITY INNOVATION ©2003
Access Control
• Provides limits on who can do what with
objects on the computer
• Can’t happen without identification and
authentication
• Is not the same as identification and
authentication
3
SECURITY INNOVATION ©2003
Access Control
Policy-Based Control of:
WHO has access to specific systems
WHAT they can do with them, and
WHEN they are allowed access
4
SECURITY INNOVATION ©2003
Access Control Layers:
Administrative
Physical
Technical
5
SECURITY INNOVATION ©2003
Administrative Access Controls
•
•
•
•
•
•
•
6
Security Policies & Procedures
Security Awareness & Training
Separation of Duties
Hiring Procedures
Employee Termination Policy
Disaster Recovery & Contingency Plan
User Registration for Computer Access
SECURITY INNOVATION ©2003
Physical Access Controls
•
•
•
•
•
•
•
7
Network Segregation
Perimeter Security
Security Guards
Badge Systems
Biometric Access Controls
Closed Circuit TV Monitoring
Sensors & Alarms
SECURITY INNOVATION ©2003
Technical (Logical) Controls
• Administrative and physical access controls
are based on traditional security threats and
thus are well understood
• Technical or logical access controls mirror
new software systems technology and the
evolving threat model. For these reasons a
discussion of technical controls is more
complex and we address access control within
this context.
8
SECURITY INNOVATION ©2003
Technical (Logical) Controls
In general technical controls involve….
•
•
•
•
•
•
9
Access Control Software
Passwords
Smart Cards
Encryption
System Access
Network Access
SECURITY INNOVATION ©2003
Analogy of Organizational
Security
• Multi-level security policies (MLS-policies)
• Different levels of security
– E.g. top secret, secret, confidential, public
• Relating security levels
– To subjects (persons) and objects (rooms or items)
• Control
– Access right is only granted if person has the appropriate
authorization, i.e. security level
11
SECURITY INNOVATION ©2003
Access Control
• Protection objects: system resources for
which protection is desirable
– Memory, file, directory, hardware resource,
software resources, etc.
• Subjects: active entities requesting accesses to
resources
– User, owner, program, etc.
• Access mode: type of access
– Read, write, execute
12
SECURITY INNOVATION ©2003
Access Control Requirement
• Cannot be bypassed
• Enforce least-privilege and need-to-know
restrictions
• Enforce organizational policy
13
SECURITY INNOVATION ©2003
Access Control
• Access control: ensures that all direct accesses
to object are authorized
• Protects against accidental and malicious
threats by regulating the reading, writing and
execution of data and programs
• Need:
– Proper user identification and authentication
– Information specifying the access rights is protected form
modification
14
SECURITY INNOVATION ©2003
Access Control
• Access control components:
– Access control policy: specifies the authorized
accesses of a system
– Access control mechanism: implements and enforces
the policy
• Separation of components allows to:
– Define access requirements independently from
implementation
– Compare different policies
– Implement mechanisms that can enforce a wide
range of policies
15
SECURITY INNOVATION ©2003
Closed v.s. Open Systems
Open System
Closed system
(maximum privilege)
(minimum privilege)
Access
requirements
Access
requirements
Allowed
accesses
Exists Rule?
yes
Access
permitted
16
no
Access
denied
Disallowed
accesses
Exists Rule?
no
Access
permitted
SECURITY INNOVATION ©2003
yes
Access
denied
Access Control
Access
Control
Subjects
Reference monitor
• Active subjects:
– e.g. processes, persons, groups ….
• Passive objects:
– e.g. data, memory banks, ...
17
SECURITY INNOVATION ©2003
Objects
How It Works
C
A
B
SUBJECT
A.
B.
C.
D.
E.
18
E
D
REFERENCE MONITOR
OBJECT
Subject – User or Process
Request for Access
Reference Monitor – Decides on the Access
Reference Monitor Grants or Denies Access Request
Object – File / Printer / Nodes on Network
SECURITY INNOVATION ©2003
Program Execution
User X
Monitor
Program
Network
Disk
19
Memory
SECURITY INNOVATION ©2003
Reference Monitor
• Makes access control work
• You can tell it
– What a subject is allowed to do
– What may be done with an object
• In order to specify these things, you need to
know all the possibilities, or you need to
define things narrowly so that what you don't
know doesn’t become allowed
20
SECURITY INNOVATION ©2003
Reference Monitors
• Single level
• Easy to implement…..BUT
• May become a bottle-neck…
IF the access-control monitor is defeated, THEN
all accesses are vulnerable
21
SECURITY INNOVATION ©2003
Ideal Reference Monitor
Real
most things
• Sees everything a program is about to do
before it does it
• Can instantly and completely stop program
execution (or prevent action)
• Has no other effect on the program or system
limited
Can we build this?
Probably not unless we can build a time
machine...
22
SECURITY INNOVATION ©2003
Protecting the Reference
Monitor
• It must not be possible to circumvent the
reference monitor by corrupting it
• Mechanisms
– Type checking
– Sandboxing: run processes in isolation
– Software fault isolation: rewrite memory access
instructions to perform bounds checking
– User/Kernel modes
– Segmentation of memory (OS resources aren’t part
of virtual memory system)
23
SECURITY INNOVATION ©2003
Example Reference Monitors
• Operating Systems
– File system
– Memory (virtual memory, separate address spaces)
• Firewalls
– Regulate network access
• Java Virtual Machine
– Regulates Java programs’ resource usage
Operate at different levels of abstraction
– Interface (Subjects, Objects, Actions) varies
24
SECURITY INNOVATION ©2003
Reference Monitors
• Cannot enforce all Security Policies
• Some policies depend on:
– Knowing about the future
• If the program charges the credit card, it must eventually
ship the goods
– Knowing about all possible executions
• Information flow – can’t tell if a program reveals secret
information without knowing about other possible
executions
25
SECURITY INNOVATION ©2003
Access Control
• You want to protect some of the files you create
– Is confidentiality an issue ?
• Operating systems are designed to protect users from
each other
– Is integrity an issue ?
• Terminology
– An active subject wishes to use an access operation on a passive
object.
• (Sam wishes to read the production log)
– The same entity can sometimes be either subject or object
• (Sam wishes to execute the production program
– The production program wishes to read the production log)
• We could specify what the subject is allowed to do,
or what may be done with the object
26
SECURITY INNOVATION ©2003
Access Control - Modes
• There is a lot of computing history behind the four
access modes
–
–
–
–
Execute (usually includes Read capability)
Read
Append (blind write)
Write -which includes Read capability
• Note that these modes do not directly allow for
entities (say an active user) to create objects, and to
grant access modes to that object
– Sam needs to create a file for the latest production report,
and needs all members of the production team to have read
access to that file
27
SECURITY INNOVATION ©2003
Basic Access Control
•
•
•
•
1
:
2–4 :
5–7 :
8 – 10 :
Type of file.
Owner’s permission.
Group’s permission.
Other’s permission.
PERMISSION
28
MEANING
- rwx rwx rwx
File. Everyone can read, write and execute this.
- rwx r-x r-x
File. Everyone can read and execute this but only the owner
can write to it.
- r-- r-- ---
File. The owner and everyone in his group can only read
this file, but the others have no access to it.
d rw- rw- rw-
Directory. Everyone can read and write. No one including
the owner can traverse it.
l rwx r-x r-x
Link. The permissions for a link generally do not matter.
SECURITY INNOVATION ©2003
Access Control List
UNIX
• An access control list (ACL) is an ordered list
of access control entries that define the
protections that apply to an object and its
properties
• ACLs entry contains
– Attributes:
• Defines special file modes
– Base permissions:
• Reflect the basic access rights
– Extended permissions:
• specify, permit, deny
29
SECURITY INNOVATION ©2003
Access Control List
ACL Entries
30
Description
1. attributes: setuid,setgid,stickybit
Special file modes.
2. base permissions
Standard Unix file permissions.
3. owner(owner_user): rwx
owner and access rights
4. (owner_group): r-x
group and access rights
5. others: r--
other's rights
6. extended permissions
Additional ACL entries.
7. enabled
enabled or disabled
8. permit --x u:some_user, g:some_group
Permits access to the specified user-group
combination in a boolean AND manner.
9. deny rwx g:a_group
Forbids access to the specified user-group
combination in a boolean AND manner.
SECURITY INNOVATION ©2003
Auditing
• Is a feature which provides accountability to
all system activities from file access to
network and database
• Each audit event such as user login is
formatted into fields such as the event type,
user id, file names and time
• Audit events
 Administrative event class
• Security administrator events
• System administrator events
• Operator events
 Audit event class
• Describes the operation of the audit system itself
31
SECURITY INNOVATION ©2003
Audit Trail
• Record of both completed and attempted
access and service chronological record of
system activities
• Enables reconstruction and examination of the
sequence of events and changes in audit event
• Monitoring system changes
 Files system permission & checksum should be set,
snapshots taken & made read only
 Snapshots are made regularly and compared with
the original for changes
 Eg: tripwire, rdist utility, securemax (from open
Vision), ESM….
32
SECURITY INNOVATION ©2003
Windows 2000 File System
• Supports two file system
– FAT (File Allocation Table)
• File system does not record security information such as
owner or access permission of a file or directory
– NTFS (New Technology Files System)
• Supports a variety of multi-user security models
• NTFS Vs FAT




33
Fault tolerance
Access Control by directory or file
Can compress individual or directories
POSIX support
SECURITY INNOVATION ©2003
Windows 2000 Auditing
• Windows 2000's object access is an important
source of OS-level information about how
users employ your network. This category can
track the source, time, and method of access to
files, folders, registry keys, and printers. It can
gather specific details about the logon session
under which an access attempt occurred or
the application through which a user tried to
open an object. Object-access events can be
linked to corresponding logon or processtracking events.
34
SECURITY INNOVATION ©2003
Windows 2000 Access Control
• Each object has two Access Control Lists.
– A discretionary Access Control List (DACL)
– A system Access Control List (SACL).
• Windows 2000 auditing is able to track
object access at both the system level and
the object level. This is accomplished by
first enabling the Audit object access
category for success and failure events.
Second, you need to enable auditing for
each object you want to monitor.
35
SECURITY INNOVATION ©2003
Discretionary Access Control
List (DACL)
• The DACL controls who
can access the object
and how.
the object's Access
Control Settings
permissions for only
one user or one group
at a time
36
SECURITY INNOVATION ©2003
System Access Control List
(SACL).
• The SACL defines the
actions for which
Windows 2000 audits an
object. An object's SACL
consists of access
control entries (ACEs).
An ACE defines exactly
which types of access
Windows 2000 records
in the Security log when
a specified user or
group accesses the
object.
37
SECURITY INNOVATION ©2003
audit the Everyone group's
successful attempts to gain write
access and failed attempts to
gain read access.
Access Control List
• Data structure of an ACL
ACL size - # of bytes of memory
allocated
ACL Revision – revision # for the
ACL’s data structure
ACE Count - # of ACE’s in the ACL
38
SECURITY INNOVATION ©2003
Access Control Entries
• Contains the following access control information
– A security identifier (SID)
– An access mask – specifies access rights
– A set of bit flags that determines which child objects
can inherit the ACE
– A flag that indicates the type of ACE
39
SECURITY INNOVATION ©2003
ACE Types
• 3 Generic types
Type
Description
Accessdenied
Used in a DACL to deny access.
Accessallowed
Used in a DACL to allow access.
System-audit
Used in a SACL to log attempts to
access.
• Object-Specific ACE types
40
Type
Description
Access-denied,
object-specific
Used in a DACL to deny access to a property or property set, or to limit
inheritance to a specified type of child object.
Access-allowed,
object-specific
Used in a DACL to allow access to a property or property set, or to limit
inheritance to a specified type of child object.
System-audit,
object-specific
Used in a SACL to log attempts to access a property or property set, or to limit
inheritance to a specified type of child object
SECURITY INNOVATION ©2003
Access Rights
• Generic Access Rights
Constant in Win32 API
Meaning
GENERIC_ALL
Read, write, and execute access
GENERIC_EXECUTE
Execute access
GENERIC_READ
Read access
GENERIC_WRITE
Write access
• Standard Access Rights
Constant in Win32 API
Meaning
DELETE
The right to delete the object.
READ_CONTROL
The right to read the information in the object's security descriptor, not
including the information in the SACL.
SYNCHRONIZE
The right to use the object for synchronization. Some object types do not
WRITE_DAC
The right to modify the DACL in the object's security descriptor.
WRITE_OWNER
The right to change the owner in the object's security descriptor.
– Other rights like, SACL
access
support
thisrights,
access right.
Object-specific access rights, user rights
41
SECURITY INNOVATION ©2003
Access Control: How does it Work?
The Windows Model
42
SECURITY INNOVATION ©2003
Access Checking & Audit
Generation
• Function “AccessCheckAndAuditAlarm” determines whether
the subject is allowed or denied access and then
determines is there a need to generate an auditing entry in
the security log.
• It considers the following
– Subjects access token
– Subject’s desired access mask (a data structure 32 bit log,
each bit corresponding to a particular access rights)
– Object’s security descriptor
• After the access-checking is complete, this function
returns a granted access mask (it is identical to
desired access mask except that all bits are initially
turned off)
43
SECURITY INNOVATION ©2003
Auditing
• Here, we generate entries in the security log for
successful or failed attempts to access an object
• After the access checking is over, the function will
tell us what need to be logged in
–
–
–
–
44
Subject’s access token
Desired access mask – subject
Granted access mask – access check
Object’s SACL
SECURITY INNOVATION ©2003
Access Control - Strategies
TYPES:
• Discretionary Access Control (DAC)
• Roles-Based Access Control (RBAC)
• Mandatory Access Control (MAC)
45
SECURITY INNOVATION ©2003
Access Control - Strategies
• Discretionary access control:
– Owner principle: owner decides about access
control
• Role-based access control:
– Access rights depend on the roles of subjects
• Mandatory access control:
– System rules (MAC) decide about access
– System rules govern owner principle
– Examples: SE-VMS, Trusted Solaris
46
SECURITY INNOVATION ©2003
Discretionary Access Control
(DAC)
• Owner principle: owner decides about access
control
• Conditions:
– There is a subject
– There is an object
– There are other users
DAC: “The subject (a) decides who
among users (c) has what level of access
on the object (b)”
47
SECURITY INNOVATION ©2003
Discretionary Access Control
• Owner of an object can arbitrarily grant
access rights to other subjects
• Problem of how to limit propagation of rights
– Granted access rights can be granted again to
other subjects
• Problem of Trojan horses
48
SECURITY INNOVATION ©2003
DAC and the Trojan Horse
Scenario
Robert: read, write
Classified
Robert
Ivan: read, write
REJECTED!
Read Classified
Black is not allowed
To access Classified
Ivan
49
SECURITY INNOVATION ©2003
Non
Classified
DAC and the Trojan Horse
Scenario
Word
Robert
Processor
Uses shared program
Robert: read, write
TH
Reads
Classified Robert’s Classified
Ivan, Robert: read, write
TH
Copies
Robert’s Classified
Classified
To Ivan’s
Directory
Ivan
50
Inserts Trojan Horse
Into shared program
SECURITY INNOVATION ©2003
Discretionary Access Control
• DAC mechanisms have an inherent weakness.
• They are vulnerable to Trojan Horse attacks.
51
SECURITY INNOVATION ©2003
DAC Weakness
• How great is the threat of malicious software?
• Consider the following points:
– How much software on your own system did you write?
– How much software on your system can you absolutely
vouch for?
– More and more software is written overseas these days.
– It only takes one bad engineer in a group of a thousand good
engineers to embed a Trojan Horse in a product.
– If you store information that is worth stealing, the Trojan
Horse attack is very attractive
– Are you running a browser that downloads and executes
Java applets?
52
SECURITY INNOVATION ©2003
DAC Weakness
Want to know more?
A Guide to Understanding
Discretionary Access Control in
Trusted Systems, NCSC-TG-003
53
SECURITY INNOVATION ©2003
Role-Based Access Control
(RBAC)
• Access Based on Organizational Roles or
Functions
• Enforces Security Policies
• Reduces Complexity & Cost
54
SECURITY INNOVATION ©2003
RBAC Mechanism
• Users are associated with roles.
• Roles are associated with permissions.
• A user has a permission only if the user has an
authorized role which is associated with that
permission.
55
SECURITY INNOVATION ©2003
Role-Based Access Control
• Role-based security model is a tupel
– RBAC = (S, O, RL, P, sr, pr, session)
Such that:
S is a set of users of a system
O is a set of objects
RL is set of roles
P is a set of access rights
sr (subject roles), pr (privileges), sess (sessions) are
relations
56
SECURITY INNOVATION ©2003
RBAC Mechanism
Example: The Three Musketeers
(User/Permission Association)
Athos
palace
Aramis
uniform
Porthos
57
weapons
SECURITY INNOVATION ©2003
D'Artagnan
RBAC Mechanism
Athos
Porthos
Aramis
D'Artagnan
palace
Musketeer
uniform
weapons
Athos
palace
Aramis
uniform
Porthos
58
weapons
SECURITY INNOVATION ©2003
D'Artagnan
RBAC Mechanism
Example: (D’Artagnon becomes a Musketeer)
palace
D'Artagnan
Musketeer
uniform
weapons
palace
D'Artagnan
uniform
weapons
59
SECURITY INNOVATION ©2003
Role-Based Access Control
• Roles (instead of persons) determine access rights
• Subjects may have different roles according to
their tasks
• Example Trusted Solaris (root is divided into 4
roles)
– Security officier, system admin, ...
• Example Banking:
– teller, account executive, manager, V.P., customer
60
SECURITY INNOVATION ©2003
RBAC Model
• Role Hierarchies, e.g, teller inherits employee
• Conflict of Interest Constraints:
– Static Separation of Duty: user cannot be
authorized for both roles, e.g., teller and auditor
– Dynamic Separation of Duty: user cannot act
simultaneously in both roles, e.g., teller and
account holder
• Role Cardinality: maximum number of users
authorized for role, e.g., branch manager
61
SECURITY INNOVATION ©2003
Banking Example: Hierarchy of
Roles
Employee
Customer
Account
executive
Teller
Manager
V.P.
62
SECURITY INNOVATION ©2003
Role-Based Access Control
Summary
• Express organizational policies
– Separation of duties
– Delegation of authority
• Flexible: easy to modify to meet new security
requirements
• Supports
– Least-privilege
– Separation of duties
– Data abstraction
RBAC is independent from DAC and
MAC (they may coexist)
63
SECURITY INNOVATION ©2003
Mandatory Access Control (MAC)
• Why Do We Need a MAC Policy?
• We know that DAC policies inherently cannot
prevent a malicious software (Trojan horse)
attack. A policy is needed that can address the
malicious software problem.
64
SECURITY INNOVATION ©2003
Mandatory Access Control (MAC)
• A Mandatory Access Control policy is a policy
in which people do not have control over the
authorization of people to information.
Note how this policy differs from a DAC
policy.
65
SECURITY INNOVATION ©2003
Mandatory Policies are ….
• Global - sensitivity of information does not
change relative to its "location" in the system
• Persistent- sensitivity of information does not
change with respect to time. For example,
time does not state that information is TS on
MWF but only C the remaining days of the
week
66
SECURITY INNOVATION ©2003
Mandatory Access Control Policy
Definitions
• Access Class
– User - Clearance
– Information - Sensitivity
– Clearance and Sensitivity can be mapped to system attributes
call Access Classes.
• Object
– Any passive entity that contains information. It may be
helpful to consider this as a file.
• Subject
– Active entities operating on behalf of users. It may be helpful
to consider this as being associated with a process.
67
SECURITY INNOVATION ©2003
MAC Policy Implementation
• Each subject has a label (or access class).
• Each object has a label (or access class).
– The ability of a subject to access an object is based
upon a comparison of the subject’s label and the
object’s label.
– Two labels are compared using the "dominance"
operator "≥".
i.e., if label A dominates label B, we write A ≥ B.
Object labels and subject labels are a
requirement of MAC policy implementations.
68
SECURITY INNOVATION ©2003
MAC Policy Implementation
Example
• As an example, consider the set of military
classification levels
• {Top Secret, Secret, Confidential, Unclassified}.
• Where:
–
–
–
–
Top Secret ≥ Secret
Top Secret ≥ Confidential ≥
Top Secret ≥ Unclassified ≥
Secret ≥ Confidential ≥ etc.
• Technically , Top Secret ≥ Top Secret. Secret ≥ Secret ,
etc.
69
SECURITY INNOVATION ©2003
Access Control is Defined by…
• Policies
• Access Control Methods
– Access Matrix, Capabilities, Access Control Lists
(ACLs)
• Trusted Computing
• Operating System Certification
70
SECURITY INNOVATION ©2003
Security Models
• Security Models
–
–
–
–
71
Bell-LaPadula
Biba
Chinese Walls
Clark-Wilson
SECURITY INNOVATION ©2003
Bell and LaPadula Model (BLP)
• David Bell and Len LaPadula, 1973 on initiative of US
Air Force
• The Bell and LaPadula Model is a mathematical
description of a Security Policy
– A state machine model written at MITRE, Bedford MA for the
Multics operating system
• Has been the most influential model of security over
the past ~30 years.
– The policy in the BLP model and some of the elements of the
model are embedded within the TCSEC. It purports to
implement the Department of Defense (DoD) security policy.
72
SECURITY INNOVATION ©2003
What is the TCSEC?
• The Trusted Computer System Evaluation Criteria
– AKA “The Orange Book”
• Written by the DoD to describe the security and
assurance requirements necessary for government
and military systems
– Defined several “rating classes”, which were inclusive and
increasing C2, B1, B2, B3, A1
– Operating system centric
• Used for 17 years as the de facto standard for trusted
systems
• Retired in 1999 in favor of a new criteria and
methodology called the Common Criteria.
73
SECURITY INNOVATION ©2003
Bell and LaPadula Model
• The Bell and LaPadula Model specifies read
and write access between a subject and an
object based upon the dominance relationship
between the subject’s label (or access class)
and the object’s label (or access class).
• Core of operating system is the reference
monitor (security kernel) that checks all
accesses
74
SECURITY INNOVATION ©2003
Bell and LaPadula Model
• The Bell and LaPadula Model is the most
common model for MAC policies.
• Applies only to secrecy (not integrity) of
information.
• It includes both discretionary and mandatory
access rules
• Both checks are made upon request for access.
• We will only look at the MAC aspects of the
model since we are using the model to
demonstrate a MAC policy.
75
SECURITY INNOVATION ©2003
BLP Mandatory Access Control
• Lets S be the set of all subjects in a system and
O be the set of all objects in a system.
• For each subject s in S there exists a label or
access class for s called C(s).
• For each subject o in O there exists a label or
access class for o called C(o).
76
SECURITY INNOVATION ©2003
Simple Security and Star Property
• The Simple Security Property:
– The normal "no read up" policy where
Secret users can read Secret, Confidential and Unclassified
information (read down allowed) but
– Secret users cannot read Top Secret (no read up)
• Confinement property (the *-Property, pronounced
’Star Property’)
– A subject has write access to an object only if classification of the
object dominates the clearance of the subject. This is required to
prevent malicious software from writing down.
• Tranquility property
– The classification of an object does not change while the object is
being processed by the system.
Information cannot flow downward!
77
SECURITY INNOVATION ©2003
Why the *-Property is needed
• Recall the shared word processor that
contained a Trojan horse program. If a Secret
user uses the program on a system that does
not enforce the *-Property, the Trojan horse
could read Secret files and write them to
Unclassified files, where Ivan (the person who
installed the Trojan and who is an Unclassified
user) can read them.
• If, however, a system enforces the *-Property, a
Trojan horse cannot write down.
78
SECURITY INNOVATION ©2003
Mandatory Access Control
• In a computer system, a mandatory policy can
protect information in objects from
unauthorized access even in the face of
malicious software.
79
SECURITY INNOVATION ©2003
Summary of the BLP rules:
• No read up and No write down.
– The BLP Model is often described in terms of
secure information flows. The Figure below shows
such a flow diagram. This is another way of saying
that there is "no read up" and "no write down."
• As indicated by the diagram on the next slide,
a subject can only both read and write an
object if the object has the same access class
value as the subject.
80
SECURITY INNOVATION ©2003
Bell and LaPadula Model
High
O5
Write
S2
O3
Write
Read
Read
Write
Write
O2
S1
Read
O1
81
O4
Read
Low
SECURITY INNOVATION ©2003
Subject Object
Bell and LaPadula Example
• Consider the following objects and subjects:
– File1 has an access class value of Secret.
– File2 has an access class value of Confidential.
– File3 has an access class value of Top Secret.
– Subject1 has an access class value of Top Secret.
– Subject2 has an access class value of Confidential
82
SECURITY INNOVATION ©2003
Bell and LaPadula Example
• Under the BLP Model the following accesses
are allowed:
– Subject1 can read File1, File2 and File3.
– Subject1 can write only File3.
– Subject2 can read File2.
– Subject2 can write File1, File2 and File3.
83
SECURITY INNOVATION ©2003
Bell and LaPadula
• Can an Unclassified user blindly write to
Secret?
– Yes. The model allows it, but most
implementations prohibit arbitrary blind writeups.
84
SECURITY INNOVATION ©2003
Mandatory Access Control Issues
• How does Alice, a Secret user, write information
to an Unclassified file?
– Remember we can only write up
The Notion of Sessions
85
SECURITY INNOVATION ©2003
Mandatory Access Control Issues
• Systems that support MAC policies, must also
support the notion of a session level.
– When a user logs on they request a session level,
which can be any level up to their clearance level.
• If Alice logs on and requests a session level of Secret, a
Secret level subject is created on her behalf. This subject
can read files at or below Secret and can write files at or
above Secret.
• While Alice is logged in, she can re-negotiate a new
session level to any other level that she is allowed to
operate at. This means if she needs to write an
unclassified file, she must negotiate an unclassified
session.
– Session negotiation should use the trusted path
86
SECURITY INNOVATION ©2003
Bell and LaPadula
• Where does data integrity fit into a
Mandatory Access Control scheme that
enforces the BLP Model?
Nowhere!
87
SECURITY INNOVATION ©2003
Integrity
• The term integrity is used in two ways in the
context of computer security.
• Program or execution integrity refers to a
system’s ability to provide protected domains
of execution.
• Data integrity refers to keeping data free from
unauthorized modification
88
SECURITY INNOVATION ©2003
Secrecy versus Integrity
• Secrecy and data integrity concerns are distinct.
The Golden Triangle of
COMPUSEC
Availability
• Secrecy concerns the prevention of unauthorized
disclosure of data or information.
89
SECURITY INNOVATION ©2003
Biba Integrity Model
• In addition to enforcing a policy for secrecy,
we would like systems to enforce a
mandatory policy for data integrity too.
• The Biba Integrity Model addresses the
unauthorized modification problem by
restricting read and write accesses.
• Uses integrity levels and integrity
compartments much like sensitivity levels and
sensitivity compartments
90
SECURITY INNOVATION ©2003
Biba Integrity Model
• Focus on integrity
• Assurance of integrity requires that data not flow
from a receptacle of lower integrity to a receptacle of
higher integrity
• If a process can write above its security level,
trustworthy data could be contaminated by the
addition of less trustworthy data
• Biba rules:
– No write up.
– No read down.
91
SECURITY INNOVATION ©2003
Chinese-Wall Model (BresherNash)
• Drives commercial Security policies and is oriented
towards confidentially.
• Previous actions of a subject determines (i.e. restricts)
access rights i.e. rights are continually decreasing
• Rights are usually read, write, execute
• Read-Access:
– Only if no previous access to another object of the same conflict
class but different company
• Conflict classes’ – group of competitive companies
• Write-Access:
– Only if all previous read-accesses are concerned with objects of
the same company.
• Protects ‘leaking’ of information
92
SECURITY INNOVATION ©2003
Clark-Wilson Model
• Earlier models emphasized the government
approach of confidentiality.
• The commercial approach is more concerned
with integrity
• As opposed to subject/object pairs as earlier
lattice models used, C-W model uses
subject/program/model triples
• Characterized by well-formed’ transactions:
– Exact order of known actions
– Authentication of user performing actions
93
SECURITY INNOVATION ©2003
Clark-Wilson Model
• Addresses all 3 integrity goals
– Prevents unauthorized users from making
modifications
– Maintains internal and external consistency
– Prevents authorized users from making improper
modifications
• Files cannot be tampered with while being
changed
• All changes must be logged
• Integrity of data is consistent
94
SECURITY INNOVATION ©2003
Mandatory Access Control
Conclusions
• A MAC policy can prevent malicious software
(e.g., Trojan horses) from directly leaking
information from high to low.
– Recall that we trust users to not give the store
away, but we generally can’t say the same thing
for software.
– So we build systems that enforce a MAC policy on
applications and we don’t have to worry about the
application software.
– For example, a subject running at Secret cannot
write any information at a level below Secret.
95
SECURITY INNOVATION ©2003
Trojan horse can write between
objects at the same level.
• For example, a Trojan horse can read one
Secret file and copy it to another Secret file.
– Is this a problem?
96
SECURITY INNOVATION ©2003
Mandatory Access Control and the
Trojan Horse Scenario
• This scenario would require a bad guy (e.g., Ivan) to
have a Secret clearance. (The reason why personnel
security is important.)
– He installs a Trojan horse into a shared word processor
program.
– Sue, a Secret user, uses the word processor and the Trojan
horse copies her Secret files into John’s directory. But John is
already cleared for Secret information so the Trojan horse
does not get him any information he is not already cleared to
see.
– In general, systems that support a MAC policy also support a
DAC policy to provide a convenient separation of user’s
data.
97
SECURITY INNOVATION ©2003
A Potential Problem with the
Mandatory Access Control
Approach
• Covert Channels can still leak information
from high to low in spite of a MAC policy.
98
SECURITY INNOVATION ©2003
Covert Channels
• Covert channels are flows of information
between access class levels counter to a MAC
policy but which are allowed by an
implementation.
– Covert channels are a means of leaking
information from high to low, one bit at a time.
– If the rate of transmitting bits across the channel
(the channel baud rate) is great, this threat is
significant.
99
SECURITY INNOVATION ©2003
Covert Channels
• Covert channels involve two programs, of
which one must be a Trojan horse.
• Covert channels are a little complicated to
implement.
• However, if information being stored is very
valuable, the covert channel threat is real.
100
SECURITY INNOVATION ©2003
Covert Channels-Storage
• Covert storage channels exploit a resource
common to both a high subject and a low
subject.
• Automated flow analysis tools can identify
every storage channel in a formal specification
of a system’s interface.
101
SECURITY INNOVATION ©2003
Covert Channels-Timing
• Covert timing channels exploit a mechanism
where a high subject can affect the timing of
low subject.
• No automatic means exist for identifying
every existing timing channel at a system’s
interface.
• Timing channels are identified by a
examination of the interface.
102
SECURITY INNOVATION ©2003
Covert Channels-Example
The classic example of a covert storage
channel is the disk exhaustion channel.
Step 1
• Ivan, (a low user) introduces a Trojan horse program
(e.g., Star Trek game) into the system and somehow
gets a high user to execute it.
• When the high user plays the Star Trek game a subprogram is spawned and goes to sleep. The subprogram contains the Trojan horse and wakes up and
starts running at a time when activity on the system is
low (e.g., at 0100).
103
SECURITY INNOVATION ©2003
Covert Channels
Step 2
• John starts another program (a low program) that will
wake up at 0105, (5 minutes later than the high
program). This allows the high program time to
initialize the channel.
• The high program finds a high file to copy (fileA).
• The high program initializes the channel by
repeatedly creating files until the "disk full" exception
is returned.
• The two programs will synchronize with each other
by reading a system clock. The high program will
signal bits on every even millisecond and the low
program will receive bits on every odd millisecond.
104
SECURITY INNOVATION ©2003
Covert Channels
Step 3
• The high program starts reading the bits out of FileA.
The following steps are repeatedly performed until
the high program is through reading the file.
– The high program does: (on even milliseconds)
• If a bit is a 0, the high program deletes one file. (Creating room
on the disk for a file to be created.)
• If a bit is a 1, the high program does not delete a file. (So there is
no room on the disk to create a file).
– The low program does: (on odd milliseconds)
• The low program always tries to create a file. If there is room on
the disk, the create file call is successful.
• If the call is successful, the low program writes a 0 into a
destination file.
• If there is no room on the disk, the create file call will fail, with
the "disk full" exception. If the call is unsuccessful, the low
program writes a 1 into the destination file.
105
SECURITY INNOVATION ©2003
Storage Channel Example
Conclusions:
• The channel baud rate of the previous
example is 1 bit every 2 milliseconds.
• This is 500 bits per second, which is 30,000 bits
per minute.
– The timing scheme used in the example is very
conservative. Much higher baud rates are
generally attainable.
106
SECURITY INNOVATION ©2003
Covert Channels
Countermeasure
• One way to close the disk exhaustion channel is to
partition the disk into volumes and allocate each
volume to a different security level. For example,
volume 0 is for TS files, volume 1 is for S files and
volume 2 is for C files.
• Under this partitioning scheme, a C subject cannot tell
if the TS volume is full or not. Recall that in the covert
channel scenario, the C subject determined if the disk
was full by attempting to create a file. Under the
partitioning scheme, C subjects create files on a
separate volume than the TS subjects.
107
SECURITY INNOVATION ©2003
Covert Timing Channels
• Covert timing channels exploit a mechanism where a
high subject can affect the timing of a low subject.
– A potential timing channel, which exists on single processor
systems, uses the fact that both the high subject and the low
subject use the same physical processor.
• To signal a 1, the high subject performs a lengthy operation
(e.g., disk I/O) and signals a 0 by performing a short operation.
• When the high subject finishes its operation, the low subject is
scheduled to run.
• When the low subject gets scheduled, it reads the system clock
and determines how long the high subject operation took.
108
SECURITY INNOVATION ©2003