Secure Operating System Example: SELinux
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
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
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