1. Secure Operating System

2. Mandatory Protection Systems
Problem of discretionary access control: untrusted processes can modify protection states
Mandatory protection system:
Subjects and objects represented by labels
Protection state: the operations that subject labels may perform on object labels
Labeling state: mapping objects to labels
Transition state: defines what relabeling is allowed

3. Example Transition State Labeling State file1 file2 … secret
unclassified
trusted
untrusted
R,W R R
Process 1
R,W R
R,W W
R,W W
Process 2
R,W R
R,W
R,W
Protection State

4. Mandatory Access Control
In a mandatory protection system
The set of labels are defined by trusted administrators
The set of labels are immutable
Protection state, labeling state, and transition state can only be modified by trusted administrators through trusted programs
This is called Mandatory Access Control (MAC)

5. Reference Monitor
An authorization system that determines whether a subject is allowed to perform an operation on an object
Takes as input a request
Returns a binary response indicating whether the request is authorized or not

6. Source: Operating system security, Jaeger’08, Morgan & Claypool

7. Secure Operating System
A system with a reference monitor access enforcement mechanism that satisfies the requirements below when it enforces a mandatory protection system.
Complete Mediation: all security-sensitive ops
Tamperproof: untrusted processes cannot modify access enforcement system
Verifiable: small TCB

8. Examining Unix Complete mediation
Problem1: not all file access is mediated by RM, e.g., if a process possesses a file descriptor, it can perform any ad hoc command on the file using system calls ioctl or fcntl, as well as read and modify file metadata.
Problem 2: not all system resources are mediated

9. Examining Unix Tamperproof
Any user process can modify the protection state at its discretion.
User processes can access and modify kernels through special file systems (e.g., /proc, /kmem.)
Any root user process can modify any aspect of the protection system

10. Examining Unix Verifiable Effectively unbounded TCB
Impossible to prove that security goals are met as long as TCB is OK

11. Secure Operating System Example: SELinux

12. Securing Linux Linux Security Module (LSM) introduced in early 2000’s
Provides a generic reference monitor interface
Allows for different security models to be used
Supports POSIX.1e capability system as an optional security model
Two popular LSMs: AppArmor and SELinux

13. How does LSM work? Predefined LSM hooks were placed in Linux kernels
The hooks are interfaces to the reference monitor
Hook placement is non-trivial
Over 150 hooks
A security model just needs to implement the hooks

15. Security-Enhanced Linux (SELinux)
A MAC security model using LSM
Provides fine-grained access control policy
Policy writers define the policy – a non-trivial job
Quality of protection depends largely on the policy specification

17. Step 1: Convert call to LSM hooks to authorization queries
Parameters to an LSM call
Subject: the current process that is making the call
Object: inode
Operations requested
Convert subject and object to labels
Called “context” in SELinux
Stored in kernel
Each object also has a “data type”

19. Step2: Retrieve SELinux Policy Entry for the access request
Example policy statement:
allow <subject_type> <object_type>:<object_class> <operation_set>
allow user_t passwd_exec_t:file execute
allow passwd_t shadow_t:file {read write}

20. SELinux Protection State
All the policy statements constitute the protection state of SELinux
Can be large and complicated
More than 1000 labels defined in the reference policy
Tens of thousands of allow statements
More flexible than standard Unix access control
Allows restriction of access not possible or cumbersome under Unix

21. SELinux Labeling State
Map users/systems resources to labels
Labeling state defines how newly created processes and resources are labeled
File context specification: define mapping from file paths to object context
e.g.,
<file path expr> <context>
/etc/shadow.* system_u:object_r:shadow_t:s0
/etc/*.* system_u:object_r:etc_t:s0

22. SELinux Transition State
Defines under what conditions labels of subjects/objects may change
e.g., file label transition
type_transition <creator_type> <default_type>:<class> <resultant_type>
type_transition passwd_t etc_t:file shadow_t
A process with passwd_t label creates a file that would have etc_t, but with this policy the file will have the shadow_t label

23. SELinux Transition State
Defines under what conditions labels of subjects/objects may change
e.g., user label transition
type_transition <current_type> <executable_file_type>:process <resultant_type>
type_transition user_t passwd_exec_t:process passwd_t
A process with user_t label will change to passwd_t when executing a file with passwd_exec_t label

24. SELinux Transition State
All the transition must be authorized
i.e., there must be corresponding “allow” statements for the transition

25. SELinux Security Complete Mediation Tamperproof Verifiable
All accesses to all objects have to go through the reference monitor
Depends on LSM hook placement
No errors have been found since Linux 2.6
Tamperproof
Policy protects kernel from “weak accesses”
Verifiable