Download Slides - CSE

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
R,W
R
R
unclassified
R,W
R
R,W
trusted
W
R,W
W
untrusted
R,W
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
– 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
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: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
– 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