1. Secure Operating System Example: SELinux

2. Mandatory Protection Systems
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. 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)

4. 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

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

6. 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

7. 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

8. 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

10. 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

12. 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”

14. 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}

15. 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

16. 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

17. 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

18. 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

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

20. 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