Secure Operating System Mandatory Protection Systems Problem of

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 Labeling State file 1 Transition State file 2 … secret unclassified trusted R, W R R unclassified R, W R R, W trusted W R, W W untrusted R, W R R, W secret Process 1 Process 2 Protection State untrusted

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 – Problem 1: 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. 1 e capability system as an optional security model • Two popular LSMs: App. Armor 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”

Step 2: Retrieve SELinux Policy Entry for the access request • Example policy statement: allow <subject_type> <object_type>: <object_class> <operation_set> allow user_t allow passwd_t passwd_exec_t: file shadow_t: file execute {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: s 0 /etc/*. * system_u: object_r: etc_t: s 0

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