## Linux Security Modules
- Goal: Enforce mandatory access control
- LSM Framework: Interface for a reference monitor
- LSM:
	- Security module
	- Implementing a reference monitor
	- Here: SELinux
- Motivation
	- Lots of attacks against Windows in 2000
	- MPS is required for a secure OS
	- How to enforce MPS in commercial OS?
	- Idea: Approximate a secure OS
- Requirements for a secure OS
	- Security policy (e.g. information flow, least privilege)
	- Reference monitor (complete mediation, tamperproof, validation)
	- Formal assurance (OS with reference monitor must enforce policy)

### LSM Framework
- 2001: Secure Linux Project
	- Goal: Refactor security features into Linux
	- e.g., Argus Pitbull, Security-Enhanced Linux (SELinux), AppArmor
	- Problem: All different ideas, which to include?
	- Solution: Linux Security Modules (add another level of indirection)
- LSM Project: 
	- *Linux Security Modules*
	- Idea:
		- Authorization interface for a security model to act as access control mechanism
		- Interface for *any* authorization module
	- Module implements policy and the reference monitor
	- Focus: Mediation
	- Current LSMs:
		- Argus Pitbull
		- Security-Enhanced Linux (SELinux)
		- AppArmor
- LSM as general interface for authorization queries
- Complete mediation? Not known

#### Requirements
- Balance: Kernel developer vs. security developer (speed vs. security/tracing)
- Challenge: Unify requirements of security projects and minimal impact on Linux kernel
- Generic
	- Applicable for the normal user
	- Loading a different module is possible
- Conceptual simple
- Minimally invasive
- Efficient
- POSIX support
- Support Loadable Kernel Modules (LKMs)

#### LSM Reference Monitor
- Goal:
	- Enforce mandatory access control
	- Ensure *reference monitor concept*
- Policy defined by module

##### Complete mediation
- Add *security hook* into syscalls
- Security hook (security check function)
	- Inside syscall (wrap security-sensitive operation)
	- Execute hook before accessing sensible kernel module or similar
	- Hook creates *authorization queries* to module (invoke function defined in module)
	- Authorization query components:
		- Subject
		- Object (sensitive data type **???**)
		- Operation
	- Security module overwrites function
		- Hook default is restrictive
		- Function is pointer (to LSM module function)
		- Function pointer is stored in `security->obs` table
	- Examples
		- Object types: packet, superblock, process, shared memory, etc.
		- Finer-grained Operations: ioctl, create, getattr, setattr, lock, append, unlink
- Sensitive data types
	- Used for security labels (see labeling state)
	- Opaque Security Fields
		- Purpose: LSM associates security information with kernel objects (i.e., labels of objects)
		- Implemented as `void*` pointer (anything can be the value, void pointer has no type, Module should define target)
- Problem: How to handle object creations before security module was loaded?
- Problem: *LSM unknown whether it implements complete mediation*

##### Tamperproof
- Goal: Prevent attackers from modifying code/data of LSM/reference monitor (i.e., protection system)
- Linux: Add function to register/unregister LSMs
- LSM defines code
- LSM function pointer points to hooks
	- Problem: Could be changed
- Idea: Require compiled-in LSM (pointers can't be changed)

##### Verification
- Static analysis
	- Tool: CQUAL
	- Object states: checked/unchecked
	- Time-of-compute-to-time-of-use vulnerability
- Dynamic analysis

#### Impact on Linux
- Changes in kernel
	- *Opaque security fields* added
	- Security hook function calls inserted 
	- Generic security system call added
	- Register/unregister functions for LSMs
	- Capabilities logic moved into security modules
- Difference from previous DAC
	- Add object types
	- Added authorization for finer-grained operations
	- System labeling: Independent from user
	- Authorization defined by module
	- Policy defined by module

#### API

![](images/lsm-api.png)
#### Analysis
- Zhang et al.
- Static analysis using CQUAL
	- Two states for objects: Checked / unchecked
	- Idea: All objects in *security-sensitive operations* must be checked
- Result: TOCTTOU vulnerability
	- Time-of-Check-to-Time-of-Use-Problem
	- Attack: Exploit time between *check* and *use*
	- Example: Check file for permissions/change file/use file
- Overhead (worst case): 5 %


### SELinux
- Reference monitor to enforce mandatory access control
- Components
	- Authorization module (build authorization queries)
	- Policy store
- Fine-grained control of system resources
- Philosophy: *‌Inevitability of Failure*
	- Security management in application-space is insufficient
- History:
	- 1980s: Mach microkernel retrofitting
	- 2000: Start of SELinux
	- Motivated by the security kernel design philosophy
- Design of the MPS
	- Problem: Classical integrity un-achievable (due to too many exceptions)
	- Confine root processes (tamperproof)
	- Least privilege (verifiability)
- Problem: Tens of thousands rules necessary for standard Linux (significant effor)
- Problem: Get SELinux policy working/usable

![](images/selinux.png)
#### Essentials
- *Type*
	- Group of objects (files/directories)
	- Based on *security sameness*
	- e.g., `passwd_exec_t`, `etc_t`
- *Domain*
	- Process runs in a domain
	- Domain is assigned types it can access
	- e.g., `initrc_t`
- *Role*
	- Define domains and types a user/process can access
	- e.g., `user_r`, `admin_r`
	- User/process can transition between roles
	- Transition rules defined in SELinux policy
- *Identity*
	- Identity is applied to user account
	- Usually, does not change
	- e.g., `alice`
	- Identities are assigned roles
- *Security Context*
	- Comparable to label (assigned to each object/process)
	- `identity:role:domain`
	- `identity:role:type`
- *Type Enforcement (TE)*
	- Principle of Least Privilege
	- Control access to system calls/domains/types
- *Role-based Access Control (RBAC)*
	- Users are assigned to roles
	- Roles are assigned to domains/types
- *SELinux Policy*
	- TE + RBAC = SELinux Security Model
	- Define rules
	- Policy expresses an MPS

#### Protection State
- Syntax: `<access_vector> <subject_t> <object_t>:<object_class> <permission_set>`
- **Default**: Access denied
- Access Vector (`access_vector`):
	- `allow` (explicitly grant access)
	- `neverallow`
		- Explicitly disallow access
		- Invariants
		- If violated, policy does not compule
	- `auditallow` (log when granted)
	- `dontaudit` (do not log deny (eliminate expected denies))
- Types (`subject_t`, `object_t`):
	- `*`: All types
	- `self`: Same source
	- `~`: Complement set
	- `{}`: Multiple (set)
- Class (`object_class`):
	- `{}, *, ~` allowed
	- e.g., `file`
- Permissions (`permission_set`):
	- Operations/permissions on that type
	- `{}, *, ~` allowed
	- `execute_trans`: Execution allowed with transition
- Examples
	- `allow user_t passwd_t:file execute`: Allow role `user_r` to `execute` all `file`s from the `passwd_t` type
	- `neverallow ~{user_t} passwd_t:* *`: Prohibit every access to `passwd_t` type except `user_t` 

#### Labeling State
- Syntax: `type_transition source_type target_type : class default_type;`
- Must be allowed by TE policy
- Default: Same state as creator
- Class: `file-related`
	- New object type
	- Process from `source` creates new file-related object in directory of `target`
	- Object has `default` label
- Example:
	- `type_transition passwd_t tmp_t:{file lnk_file} passwd_tmp_t`: File/link created by `passwd_t` in `tmp`-dir gets type `passwd_tmp_t`


#### Transition State
- Syntax: `type_transition source_type target_type : class default_type;`
- Must be allowed by TE policy
- Class: `process`
	- Domain transition
	- Process from `source` executing `target` transitions to `default`
- Must be allowed by TE policy
- Examples:
	- `type_transition user_t passwd_exec_t:process passwd_t`: User executing password program transitions to `passwd_t`

#### Example: `setuid`
- Normal user should run privileged process (e.g., `passwd`)
- Protection state:
	- `allow user_t passwd_exec_t:file execute`
	- `allow user_t passwd_t:process transition`
	- `allow passwd_t shadow_t:file {read write}`
- Transition state:
	- `type_transition user_t passwd_exec_t:process passwd_t`

#### Deployment
- Install policy in kernel
- Make services aware
- Maintain policy
	- System is dynamic
	- Adapt to changes
	- Reconfigure policy
- User-space services
	- Authentication
	- Access control
	- Configuration

##### Authentication
- Example: `sshd` (network)
- Services must create a *SELinux subject context* for a user login
- Problem: Services must work with SELinux
- Solution: Pluggable Authentication Module (PAM)
	- API for central authentication
	- Comparable to GITZ (?)

##### Access control
- Example: Databases, Browsers
- Problem:
	- PostgreSQL accesses server
	- Server may leak user information
- Client-side software implements SELinux user-space library
- Use Access Vector Cache for faster access control

##### Configuration
- Example: Policy change/recompile
- Goal: Prevent attacker from controlling system policy at load
- Use Policy Management System
- **How does this work???**