Multilevel Security CySecLab Graduate School of Information Security.

Slides:



Advertisements
Similar presentations
Information Flow and Covert Channels November, 2006.
Advertisements

Operating System Security
1 cs691 chow C. Edward Chow Confidentiality Policy CS691 – Chapter 5 of Matt Bishop.
Access Control Chapter 3 Part 3 Pages 209 to 227.
Chapter 6 Security Kernels.
Access Control Methodologies
Access Control Patterns Fatemeh Imani Mehr Amirkabir university of technology, Department of Computer Engineering & Information Technology.
Access Control Intro, DAC and MAC System Security.
1 UCR Access Control/Capabilities Some slides/ideas adapted from Ninghui Li.
CMSC 414 Computer and Network Security Lecture 13 Jonathan Katz.
Verifiable Security Goals
CMSC 414 Computer and Network Security Lecture 11 Jonathan Katz.
User Domain Policies.
2  A system can protect itself in two ways: It can limit who can access the system. This requires the system to implement a two-step process of identification.
Mandatory Flow Control Bismita Srichandan. Outline Mandatory Flow Control Models Information Flow Control Lattice Model Multilevel Models –The Bell-LaPadula.
Lecture 7 Access Control
SELinux. 2SELinux Wikipedia says: Security-Enhanced Linux (SELinux) is an implementation of mandatory access control using Linux Security Modules (LSM)
ADVANCED LINUX SECURITY. Abstract : Using mandatory access control greatly increases the security of an operating system. SELinux, which is an implementation.
CMSC 414 Computer and Network Security Lecture 19 Jonathan Katz.
Computer Security & OS Lab. DKU May 26 Younsik Jeong Ph.D. Student.
CH14 – Protection / Security. Basics Potential Violations – Unauthorized release, modification, DoS External vs Internal Security Policy vs Mechanism.
SELinux US/Fedora/13/html/Security-Enhanced_Linux/
Security Policy What is a security policy? –Defines what it means for a system to be secure Formally: Partition system into –Secure (authorized) states.
1 Confidentiality Policies September 21, 2006 Lecture 4 IS 2150 / TEL 2810 Introduction to Security.
© G. Dhillon, IS Department Virginia Commonwealth University Principles of IS Security Formal Models.
1 A pattern language for security models Eduardo B. Fernandez and Rouyi Pan Presented by Liping Cai 03/15/2006.
Session 2 - Security Models and Architecture. 2 Overview Basic concepts The Models –Bell-LaPadula (BLP) –Biba –Clark-Wilson –Chinese Wall Systems Evaluation.
Security Architecture and Design Chapter 4 Part 3 Pages 357 to 377.
Security+ All-In-One Edition Chapter 19 – Privilege Management Brian E. Brzezicki.
Next-generation databases Active databases: when a particular event occurs and given conditions are satisfied then some actions are executed. An active.
Chapter 5 Network Security
Chapter 7 Securing Commercial Operating Systems. Chapter Overview Retrofitting Security into a Commercial OS History of Retrofitting Commercial OS's Commercial.
CS426Fall 2010/Lecture 251 Computer Security CS 426 Lecture 25 Integrity Protection: Biba, Clark Wilson, and Chinese Wall.
SELinux. The need for secure OS Increasing risk to valuable information Dependence on OS protection mechanisms Inadequacy of mainstream operating systems.
Multics CysecLab Graduate School of Information Security KAIST.
Information Security CS 526 Topic 17
COEN 350: Network Security Authorization. Fundamental Mechanisms: Access Matrix Subjects Objects (Subjects can be objects, too.) Access Rights Example:
Trusted Operating Systems
The SELinux of First Look. Prologue After many discussions with a lot of Linux users, I’ve come to realize that most of them seem to disable SELinux rather.
Access Control: Policies and Mechanisms Vinod Ganapathy.
Privilege Management Chapter 22.
Security-Enhanced Linux Eric Harney CPSC 481. What is SELinux? ● Developed by NSA – Released in 2000 ● Adds additional security capabilities to Linux.
Archictecture for MultiLevel Database Systems Jeevandeep Samanta.
Computer Security: Principles and Practice
CS426Fall 2010/Lecture 211 Computer Security CS 426 Lecture 21 The Bell LaPadula Model.
5/7/2007CoreMcClug/SELinux 1 By: Corey McClurg. Outline A History of SELinux What is SELinux and how do I get it? Getting Started Mandatory Access Control.
Computer Science and Engineering Computer System Security CSE 5339/7339 Session 16 October 14, 2004.
Lecture9 Page 1 CS 236 Online Operating System Security, Con’t CS 236 On-Line MS Program Networks and Systems Security Peter Reiher.
Design and Implementation MAC in Security Operating System CAI Yi, ZHENG Zhi-rong, SHEN Chang-xiang Presented By, Venkateshwarlu Jangili. 1.
Security-Enhanced Linux Stephanie Stelling Center for Information Security Department of Computer Science University of Tulsa, Tulsa, OK
Database Security. Introduction to Database Security Issues (1) Threats to databases Loss of integrity Loss of availability Loss of confidentiality To.
Database Security Database System Implementation CSE 507 Some slides adapted from Navathe et. Al.
Access Controls Mandatory Access Control by Sean Dalton December 5 th 2008.
PREPARED BY: MS. ANGELA R.ICO & MS. AILEEN E. QUITNO (MSE-COE) COURSE TITLE: OPERATING SYSTEM PROF. GISELA MAY A. ALBANO PREPARED BY: MS. ANGELA R.ICO.
EN Lecture Notes Spring 2016 ACCESS CONTROL MODELS.
CS526Topic 19: Integrity Models1 Information Security CS 526 Topic 19: Integrity Protection Models.
Lecture 2 Page 1 CS 236 Online Security Policies Security policies describe how a secure system should behave Policy says what should happen, not how you.
MLS/MCS on SE Linux Russell Coker. What is SE Linux? A system for Mandatory Access Control (MAC) based on the Linux Security Modules (LSM) framework Uses.
Security Architecture and Design Chapter 4 Part 4 Pages 377 to 416.
SE Linux Implementation Russell Coker. What is SE Linux? A system for Mandatory Access Control (MAC) based on the Linux Security Modules (LSM) framework.
Access Control Model SAM-5.
Access Control CSE 465 – Information Assurance Fall 2017 Adam Doupé
SELinux (Security Enhanced Linux)
Information Security CS 526 Topic 17
Advanced System Security
OS Access Control Mauricio Sifontes.
Computer Security Access Control
Advanced System Security
Presentation transcript:

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 time- sharing 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, discretionary- security 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 L m (s), and a current sec level L c (s) Each object has a classification level

Elements of the BLP Model Subjects Trusted Subjects Objects Current Accesses Security levels, e.g.: {TS, S, C, U} L m : Max Sec. Level L: Class. Level L c : Current Sec. Level Access Matrix

The BLP Security Policy A state is secure if it satisfies Simple Security Condition (no read up): S can read O iff L m (S) ≥ L(O) The Star Property (no write down): for any S that is not trusted S can read O iff L c (S) ≥ L(O)(no read up) S can write O iff L c (S) ≤ L(O)(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 Highest Can Read & Write Lowest Subject Max Level Current Level Can Write Can Read Objects

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, 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_t /etc/rc.d/init.d/httpd 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)