Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Commodore DOS wikipedia , lookup
Object storage wikipedia , lookup
Plan 9 from Bell Labs wikipedia , lookup
Process management (computing) wikipedia , lookup
Burroughs MCP wikipedia , lookup
Spring (operating system) wikipedia , lookup
File locking wikipedia , lookup
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