Transcript Access Control Models

Multilevel Security
CySecLab
Graduate School of Information Security
Multi-level Security (MLS)
• The capability of a computer system to carry
information with different sensitivities (i.e.
classified information at different security levels),
permit simultaneous access by users with different
security clearances and needs-to-know, and
prevent users from obtaining access to information
for which they lack authorization.
• Typically use Mandatory Access Control
• Primary Security Goal: Confidentiality
Security Goal of MLS
• There are security classifications or security levels
• Users/principals/subjects have security clearances
• Objects have security classifications
• Example of security levels
•
•
•
•
Top Secret
Secret
Confidential
Unclassified
• In this case Top Secret > Secret > Confidential > Unclassified
• Security goal (confidentiality): ensures that information do
not flow to those not cleared for that level
Access Control Models
• Access Control Models:
• Three Main Types
• Discretionary
• Mandatory
• Non-Discretionary (Role Based)
Access Control Models
• Discretionary Access Control (DAC)
• A system that uses discretionary access control
allows the owner of the resource to specify
which subjects can access which resources.
• Access control is at the discretion of the owner.
Access Control Models
• Mandatory Access Control (MAC)
• Access control is based on a security labeling
system. Users have security clearances and
resources have security labels that contain data
classifications.
• This model is used in environments where
information classification and confidentiality is
very important (e.g., the military).
Access Control Models
• Non-Discretionary (Role Based) Access
Control Models
• Role Based Access Control (RBAC) uses a
centrally administered set of controls to
determine how subjects and objects interact.
• Is the best system for an organization that has
high turnover.
Access Control Models
• MAC: Mandatory Access Control
• Cannot be worked around
• I(OS) own it, not you.
• Ex: Directory “Secret” is owned by “Agent”. “Agent” does not have
authority to grant access to others. Only the “Owner” does.
• DAC: Discretionary Access Control
• It’s yours, do what you will.
• Same example: “Agent” can grant access to whomever she cares.
• RBAC: Role Based Access Control
• Depending on what your role is, maybe.
• If “Agent” has the correct Role, she can, otherwise she can’t.
Bell-LaPadula Model: A MAC Model for
Achieving Multi-level Security
• Introduce in 1973
• Air Force was concerned with security in timesharing systems
• Many OS bugs
• Accidental misuse
• Main Objective:
• Enable one to formally show that a computer system can
securely process classified information
Approach of BLP
• Use state-transition systems to describe computer
systems
• Define a system as secure iff. every reachable state
satisfies 3 properties
• simple-security property, *-property, discretionarysecurity property
• Prove a Basic Security Theorem (BST)
• so that give the description of a system, one can prove
that the system is secure
The BLP Security Model
• A computer system is modeled as a state-transition
system
• There is a set of subjects; some are designated as
trusted.
• Each state has objects, an access matrix, and the current
access information.
• There are state transition rules describing how a system
can go from one state to another
• Each subject s has a maximal sec level Lm(s), and a
current sec level Lc(s)
• Each object has a classification level
Elements of the BLP Model
Security levels, e.g.: {TS, S, C, U}
Lm: Max
Sec. Level
Lc: Current
Sec. Level
Objects
Subjects
Trusted
Subjects
L: Class.
Level
Current
Accesses
Access Matrix
The BLP Security Policy
• A state is secure if it satisfies
• Simple Security Condition (no read up):
• S can read O iff Lm(S) ≥ L(O)
• The Star Property (no write down): for any S that is not
trusted
• S can read O iff Lc(S) ≥ L(O)
• S can write O iff Lc(S) ≤ L(O)
(no read up)
(no write down)
• Discretionary-security property
• every access is allowed by the access matrix
• A system is secure if and only if every reachable
state is secure.
Implication of the BLP Policy
Objects
Highest
Can Write
Subject
Max Level
Can Read & Write
Lowest
Can Read
Current
Level
STAR-PROPERTY
•
Applies to subjects (principals) not to users
•
Users are trusted (must be trusted) not to
disclose secret information outside of the
computer system
•
Subjects are not trusted because they may have
Trojan Horses embedded in the code they
execute
•
Star-property prevents overt leakage of
information and does not address the covert
channel problem
Limitations with BLP
• Deal only with confidentiality, does not deal with
integrity at all
• Confidentiality is often not as important as integrity in
most situations
• Addressed by integrity models (such as Biba, Clark-Wilson,
which we will cover later)
• Does not deal with information flow through covert
channels
The Biba Model
• This model only deals with integrity alone and ignores
confidentiality
• Integrity is a constraint on who can write or alter it ->
No Read Down & No Write Up
• In the Biba model, users can only create content at or
below their own integrity level (a monk may write a
prayer book that can be read by commoners, but not
one to be read by a high priest). Conversely, users can
only view content at or above their own integrity level
(a monk may read a book written by the high priest,
but may not read a pamphlet written by a lowly
commoner
Historical Examples of MLS Systems
• SCOMP: Handling messaging at multiple levels of
classification with minimal kernel and four rings of
protection. (Military mail guards- allow mail to pass
from Low to High but not vice versa)
• Comparted Mode Workstations (CMWs): An
example of MLS clients. They allow data at different
levels to be viewed and modified at the same time,
and ensure that labels attached to the information
are updated appropriately.
Historical Examples of MLS Systems
• The NRL Pump: A one-way data transfer device to
allow secure one-way information flow.
• Low to High is easy, but ack must be sent back from
High to Low.
• Pump limits the bandwidth of possible backward
leakage
Future MLS Systems
• Vista: Vista essentially uses the Biba model. All
processes do, and all securable objects (directories,
files and registry keys) may, have an integrity label.
• SELinux: based on the Flask security architecture, which
separates the policy from the enforcement mechanism.
It has security server where policy decisions are made.
• AppArmor: Suse take a different path to the same goal
with SELinux. It keeps a list of all the paths each
protected application uses and prevents it accessing
any new ones.
Future MLS Systems
• Virtualization: Computes that have the look and
feel of ordinary windows boxes while
simultaneously giving the security folks what they
want, namely high-assurance separation between
material at different levels of classification.
• Embedded Systems: There are more and more
fielded systems which implement some variant of
Biba model. For example, medical-device and
electricity utility can be observed, but not
influenced.
Type Enforcement Model
• Type enforcement first proposed by W. E. Boebert
and R. Y. Kain.
• A Practical Alternative to Hierarchical Integrity Policies.
In In Proceedings of the 8 National Computer Security
Conference, 1985.
• Aim at ensuring integrity
• Key Idea for Type Enforcement:
• Use the binary being executed to determine access.
• What do DAC and MAC use?
Type Enforcement Model
• Integrity level should be associated with programs
(rather than processes)
• Trust in programs is required for integrity
• Examples of assured pipelines:
• Labeling: All printouts of documents must have security
labels corrected printed by a labeller.
• Encrypting: Before sending certain data to an output
channel, it must be encrypted by an encryption module
• Data must pass certain transforming system before
going to certain outputs
Type Enforcement Model
• Each object is labeled by a type
• Object semantics
• Example:
• /etc/shadow
• /etc/rc.d/init.d/httpd
etc_t
httpd_script_exec_t
• Objects are grouped by object security classes
• Such as files, sockets, IPC channels, capabilities
• The security class determines what operations can be
performed on the object
• Each subject (process) is associated with a domain
• E.g., httpd_t, sshd_t, sendmail_t
Case Study – SELinux Intro
• Originally started by the Information Assurance
Research Group of the NSA, working with Secure
Computing Corporation.
• Based on a strong, flexible mandatory access
control architecture based on Type Enforcement, a
mechanism first developed for the LOCK system
Case Study – SELinux Intro
• Theoretically, can be configured to provide high security.
• In practice, mostly used to confine daemons like web
servers
• They have more clearly defined data access and activity rights.
• They are often targets of attacks
• A confined daemon that becomes compromised is thus limited in
the harm it can do.
• Ordinary user processes often run in the unconfined domain
• not restricted by SELinux, but still restricted by the classic Linux
access rights.
Case Study – SELinux Terminology
• Subject: A domain or process.
• Object: A resource (file, directory, socket, etc.).
• Types: A security attribute for files and other objects.
• Roles: A way to define what “types” a user can use.
• Identities: Like a username, but specific to SELinux.
• Contexts: Using a type, role and identity is a “Context.”
Context is -> Identities : role : type
Case Study – SELinux vs Standard
Linux
Case Study – SELinux Allow Rule
• Source type(s) Usually the domain type of a process
attempting access
• Target type(s) The type of an object being accessed by the
process
• Object class(es) The class of object that the specified access
is permitted
• Permission(s) The kind of access that the source type is
allowed to the target type for the indicated object classes
Case Study – SELinux Allow Rule ex1
• Rule Example
allow user_t bin_t : file {read execute getattr};
->A process with a domain type of user_t can read, execute,
or get attributes for a file object with a type of bin_t
Case Study – SELinux Allow Rule ex2
• Rule Example: passwd program in linux
Composability Problem
• The problem of how to compose two or more
secure components into a secure system is hard.
• Most of the low-level problems arise when some
sort of feedback is introduced into the system. In
real life, feedback is pervasive.
• Composition of secure components or systems is
very often frustrated by higher-level
incompatibilities.
The Cascade Problem
• Connecting together two B3 systems in such a way
that security policy is broken
Covert Channel
• Covert channels of information flow
• communication channel based on the use of system
resources not normally intended for communication
between the subjects (processes) in the system
• Storage Channel: allow the direct or indirect writing of
a shared storage location by one process and the direct
or indirect reading of it by another
• Timing Channel: allow one process to signal
information to another process by modulating its own
use of system resources in such a way that the change
in response time observed by the second process
would provide information
Examples of Covert Channels
•
•
•
•
•
Using file lock as a shared boolean variable
By varying its ratio of computing to input/output
or its paging rate, the service can transmit
information to a concurrently running process
Timing of packets being sent
Covert channels are often noisy
However, information theory and coding theory
can be used to encode and decode information
through noisy channels
Polyinstantiation
• Suppose that our High user has created a file
named agents, and our Low user now tries to do
the same. If the MLS operating system prohibits
him, it will have leaked information
Practical Problems
• MLS systems are built in small volumes, and often to high standards of physical
robustness, using elaborate documentation, testing and other quality control
measures
• A trained Unix administrator can’t just take on an MLS installation without
significant further training
• Many applications need to be rewritten or at least greatly modified to run under
MLS operating systems
• Blind write-up: when a low level application sends data to a higher level one,
BLP prevents any acknowledgment being sent
• There are always system components — such as memory management — that
must be able to read and write at all levels
• they also prevent desired things from happening too (such as efficient ways of
enabling data to be downgraded from High to Low, which are essential if many
systems are to be useful)