mandatory access control systemstrj1/cse497b-s07/slides/cse497b-lecture-24-macsystems.pdfmandatory...

CSE497b Introduction to Computer and Network Security - Spring 2007- Professor Jaeger

Mandatory Access Control Systems

CSE497b - Spring 2007Introduction Computer and Network Security

Professor Jaegerwww.cse.psu.edu/~tjaeger/cse497b-s07/

Page CSE497b Introduction to Computer and Network Security - Spring 2007 - Professor Jaeger

Mandatory Access Control• System-Defined Policy

– Fixed Set of Subject and Object Labels– Fixed Permission Assignments– Fixed Label Assignments: (e.g., file to object label)

2

O1 O2 O3

J R RW

RW

S2 N R RW

S3 N R RW


MAC and Systems• What is necessary to be a system that enforces MAC

policies?– Specify: MAC Policy Model– Enforce: Reference Monitor– Transitions: Changes of privilege must be controlled

• Plus, others– Management: Policy development tools– Services: MAC-aware services– Applications: Work with MAC limitations

• What do these systems look like?– We’ll examine Multics and SELinux

3


Multics• Multiplexed Information and Computing Service

– Project started as a timesharing system in 1965 -- Used until 2000

– Research project that led to a commercial product

• Invented a number of important OS features– Segmented and Virtual Memory– Shared Memory Multiprocessor– Online Reconfiguration– Hierarchical File Systems

4


Multics Security Features• Also, a number of security features were pioneered

– First Multilevel Secure (MLS) system– Isolation based on segments and rings– Ring crossing mechanisms to protect integrity– Guard-like functions for integrity protection (Gatekeepers)– One-way encrypted passwords– Covert channel defenses– And software assurance techniques...

• But, function over security– Multics Security Evaluation, 1974

5


Protection Rings

6

• Successively less-privileged “domains”• Example: Multics (64 rings in theory, 8 in practice)


What do rings mean?• What’s in a ring?

– Processes, with the code that they can access– Data they can access directly

• Execute in ring i– Process runs with rights of ring i– Data in rings >= i can be accessed– Any procedure may be accessible

• Ring-crossings (generalized)– If process calls procedure in a different ring– Traps to kernel to authorize transition– If authorized, process runs the new procedure in the new

ring

7


Multics Ring Interpretation• Kernel resides in ring 0• Process runs in a ring r

– Access based on current ring

• Process accesses data segments– Each data segment has an access bracket: (a1, a2)

• a1 <= a2– Describes read and write access

• r is the current ring• r <= a1: access permitted• a1 < r <= a2: r permitted; w denied• a2 < r: all access denied

8


Multics Ring Interpretation (con’t)• Also different procedure segments

– with call brackets: (c1, c2)• c1 <= c2

– and access brackets (a1, a2)– Rights to execute code in a new procedure segment

• (1) r < a1: access permitted with ring-crossing fault• (2) a1 <= r <= a2 = c1: access permitted and no fault• (3) a2 < r <= c2: access permitted through a valid gate• (4) c2 < r: access denied

• What’s it mean?– case 1: ring-crossing fault changes procedure’s ring

• increases from r to a1– case 2: keep same ring number– case 3: gate checks args, decreases ring number (to a2)

9


Examples• Process in ring 3 accesses data segment

– access bracket: (2, 4)– What operations can be performed?

• Process in ring 5 accesses same data segment– What operations can be performed?

• Process in ring 5 accesses procedure segment– access bracket (2,4) – call bracket (4, 6)– Can call be made?– Can new procedure segment access the data segment

above?

10


Multics Community• Multicians

11


Secure Operating Systems• Provably Secure OS (PSOS)• GEMSOS• KeyKOS and EROS (capability systems)• IX (Secure UNIX variant)• Trusted Solaris• Trusted IRIX (SGI)• Trusted Mach• Distributed Trusted Mach• XTS-400 and STOP (BAE Systems)• Flask (Microkernel based system)

12


MAC in Linux• In 2000, Linus authorized the development of a

reference monitor for Linux– So, he didn’t have to choose a single security approach

• Linux Security Modules framework was born– LSM defines an interface for reference monitoring modules– Anybody could build an LSM!

• Introduced in Linux 2.6– Version built for BSD– Underway for MAC OS X

13


Linux Security Modules Approach• Linux Security Modules framework• What security function and how does implementation

satisfy it?

14

System Interface

Entry Points

MonitorPolicy

AccessHook

AccessHook

AccessHook

Security-sensitiveOperation



Authorize Request?

Yes/No


SELinux• LSM + much more

15

Linux Kernel SELinux

LSM

SELinuxfs

SystemProcesses

SELinux-awareServices

SELinuxBootstrap

(1) Load Policy (2) Authenticate(3) Syscalls


SELinux uses Type Enforcement• MAC Policy

– Subjects and Objects Labeled• Access Matrix Policy

– Processes with subject label– Can access object of object label– If operations in matrix cell allow

• Focus: Least Privilege– Integrity bias

16

O1 O2 O3

S1 Y Y N

S2 N Y N

S3 N Y Y


SELinux Execute Transitions• Run the privileged passwd program• Simplified view -- takes 4 policy rules to do this

17

User Procuser_t

User Procuser_t

Root Procpasswd_t

Fork

Exec passwd_t


MAC Systems• Policy

– Define a fixed access policy (mandatory access control)– Multics MLS and ring policies; SELinux TE

• Enforcement– Use a reference monitor (remember the guarantees

required)– Multics kernel; Linux LSM (SELinux)

• Transitions– Enable controlled transition between privilege levels– Complexity most due to limiting transitions– Multics ring transitions; SELinux execute transitions

• Challenge– Getting programs to run with limited information flows

18


Assurance• We want to know

– Security model we are enforcing (Security Function)– That it enforces this model correctly (Assurance)

• Suppose– We have a system that enforces Bell-LaPadula– What should a system do that enforces BLP?– How do we know that the implementation is correct?

• Assurance – aims to answer these questions

19


Rainbow Series• Trusted Computer Systems Evaluation Criteria• From 1983-1999

– A variety of documents to help build secure systems– Password Management– Audit– Configuration Management

• Orange Book (1985)– Defined 6 classes of security systems

• Function that the class provides• Requirements for verifying that implementation met the class

– Requirements fall into a number of categories• Access control mechanism/policy• Authentication• Audit

20


Orange Book Classes• C1 and C2

– Discretionary protection• Authentication, audit for discretionary access• Testing and documentation

– C2 is the most common class for commercial products• B1, B2, and B3

– Labeled security protection: • Multi-level security (Bell-LaPadula)• More testing and more documentation

– B1: MLS on some objects; B2: MLS on all• B2 also introduces covert channel protections and config mgmt

– B3 more software engineering documentation• A1: Verified protection

– Requires correspondence between code and formal model21


Common Criteria• Started 1993 by US, Canada, and European Countries• Attempt to identify a set of common criteria to evaluate

information security– V1.0 1996, V2.0 1998, ISO Standard 15408 1999– A set of evaluation techniques used to vet technologies – … and tell which ones were good and bad (more or less).– This allows consumers of goods and services to know if the security

advertised is as good as is claimed• Based on some specified evaluation criteria

22


Common Criteria• Separate

– Protection Profile– Assurance Level

23

ProtectionProfile

SecurityTarget

• This is the definition of what and how the TOE (target of evaluation) meets a set of security requirements

EAL1 … EAL7

• This is really just the set of requirements for the class of products of this type (e.g., firewalls)


EAL Levels• EAL1: Functionally Tested

– Breathing• EAL2: Structurally Tested

– High-level design• EAL3: Methodically Tested and Checked

– High-level design motivates testing• EAL4: Methodically Designed, Tested, and Reviewed

– Low-level design and vulnerability analysis• EAL5: Semi-formally Designed and Tested

– Rigorous development using (semi-)formal models• EAL6: Semi-formally Verified Design and Tested

– Low-level design• EAL7: Formally Verified Design and Tested

24


Common Criteria and Linux• Linux is assured to:

– EAL4 for Controlled Access Protection Profile• Discretionary access control with a low-level system design

• With LSM and SELinux (MLS)– EAL4 for Labeled Security Protection Profile– Done September 6, 2006

• Challenges– Upstream all code

• Assure a mainline Linux kernel– Enable applications

• E.g., Polymorphic file system– Package into distribution

• That RedHat can deliver

25


Take Away

• Assurance of security enforcement requires– Security Function

• So we know what is being enforced– Justification for Function

• So we know that it is being enforced

• Assurance really aims for MAC policies– Fixed policies

• So we know what accesses are enforced– Reference monitor

• So we know the enforcement is comprehensive– Transitions

• So we can limit access after a privilege change

26

mandatory access control systemstrj1/cse497b-s07/slides/cse497b-lecture-24-macsystems.pdfmandatory...

Documents