Secure Operating System

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

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

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)

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

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

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

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

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

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

Secure Operating System Example: SELinux

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

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

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

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”

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}

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

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

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

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

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

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