SELinux

The need for secure OS Increasing risk to valuable information Dependence on OS protection mechanisms Inadequacy of mainstream operating systems Key missing features: Mandatory Access Control (MAC) – Administratively set security policy – Control over all subjects and objects in system – Decisions based on all security-relevant information

Why is DAC inadequate? Decisions are only based on user identity and ownership No protection against malicious software Each user has complete discretion over his objects Only two major categories of users: superuser and other Many system services and privileged programs must run with coarse-grained privileges if not as superuser

What can MAC offer? Strong separation of security domains System and data integrity Ability to limit program privileges Authorization limits for legitimate users

MAC implementation issues Must overcome limitations of traditional implementations – More than Multilevel Security – Address integrity, least privilege, separation of duty issues Policy flexibility required – Ability to change the model of security – Ability to express different policies within given model – Separation of policy from enforcement Maximize security transparency

Toward a new form of MAC Research by NSA Generalized from prior Type Enforcement work Provide flexible support for security policies Cleanly separate policy from enforcement Address limitations of traditional MAC DTMach, DTOS, Flask

The Flask security Architecture Cleanly separates policy from enforcement Well-defined policy interfaces Support for policy changes Allow users to express policies naturally Fine-grained controls over kernel services. Caching to minimize performance overhead Transparent to applications and users

The Flask Security Architecture

Security Context The SELinux example security server defines a security context as containing a user identity, a role, a type, and optionally a MLS level or range. Roles are only relevant for processes, so file security contexts have a generic object-r role. The individual attributes of the security context are not manipulated by the object managers.

Policy Decisions Labeling Decisions – Obtaining a label for a new subject or object Access Decisions – Determining whether a service on an object should be granted to a subject Polyinstantiation Decisions – Determining where to redirect a process when accessing a polyinstantiated object.

Labeling Decisions For program execution, the Flask process manager obtains the label for the transformed process based on the current label of the process and the label of the program executable. For file creation, the Flask file system object manager obtains the label for the new file based on the label of the creating process, the label of the parent directory, and the kind of file being created.

Policy Changes Interfaces to AVC for policy changes Callbacks to Object Managers for retained permissions – When the AVC receives a policy change notification, it updates its own state and then invokes callback functions registered by the object managers to update any permissions retained in the state of the object managers. Revalidation of permissions on use

Controlled Services Permissions are defined on objects and grouped together into object classes Examples – Processes: code execution, entrypoints, signals, wait, etc. – File: accesses to files, directories, filesystems – System V IPC: access to semaphores, message queues, shared memory – Security: access to security server services

Example security server Implements combination of Role-Based Access Control, Type Enforcement, optional Multi- Level security.

Type Enforcement Implementing TE, gives priority to MAC over DAC. – Access clearance is first given to a subject (e.g. process) accessing objects (e.g. files, records, messages) based on rules defined in an attached security context. – A security context in a domain is defined by a domain security policy. – In the Linux security module (LSM) in SELinux, the security context is an extended attribute. Type enforcement implementation is a prerequisite for MAC, and a first step before MLS. It is a complement of RBAC.

TE from wikipedia Type enforcement implies fine grained control over the operating system, not only to have control over process execution, but also over “domain transition” or authorization scheme. This is why it is best implemented as a kernel module, as is the case with SELinux. Using type enforcement is a way to implement the FLASK architecture.

TE Concepts Domains for processes, types for objects Specifies allowable accesses by domains to types Specifies allowable interactions among domains Specifies allowable and automatic domain transitions Specifies entrypoint and code execution restrictions for domains

Type Enforcement: Domains

Type Enforcement:Types

Sample TE Rules allow sendmail_t smtp_port_t: tcp_socket name_bind; – sendmail_t domain can use the network and can bind to the SMTP port type_transition getty_t login_exec_t:process local_login_t; – The getty_t domain transitions to local_login_t domain when it executes the login program – Only getty_t domain can transition to this domain – The login_exec_t type is the type of the entry point executable for this domain

Example Policy Configuration: RBAC Concepts Roles for processes Specifies domains that can be entered by each role Specifies roles that are authorized for each user Initial domain associated with each user role Role transitions are typically explicit: e.g., login or newrole

Role-Based Access Control: Roles

Meeting Security Objectives Limiting Raw Access to Data Protecting Kernel Integrity Protecting System File Integrity Confining Privileged Processes Separating Processes Protecting the Administrator Domain

Limiting Raw Access to Data

Description The klogd_t domain can only be entered by executing a program labeled with the klogd exec_t type. The klogd_t domain can read character special files with the memory_device_t type. The rc scripts can transition to the klogd _t domain when the daemon is executed.

Protecting Kernel Integrity

Description The first statement allows the rc scripts to modify the /boot directory. The individual controls over each file ensure that this does not allow the rc scripts to remove or rename the existing files in /boot in order to replace them. The second statement allows the scripts to create or delete a file with the boot_runtime_t type. The last statement causes files created in /boot by the scripts to automatically default to the boot_runtime_t type.

Protecting System File Integrity

Description write access to this /etc is strictly limited. Since the /etc/aliases and /etc/aliases.db files and the /etc/mail directory must be modified by the sendmail program, separate types are defined for this file and directory, and the sendmail t domain is granted write access to these types.

Protecting System File Integrity

Description An example of protecting the integrity of system log files is the wtmp file, which stores login records. The policy configuration defines a wtmp_t type for this file. Separate domains are defined for programs (e.g. login, utempter, gnome-pty-helper) which must update this file, and write access is only granted for these domains.

Confining Privileged Processes

Description The first statement allows sendmail to bind to the SMTP port. The next two statements allow sendmail to manage the mail spool directory. The last two statements allow sendmail to manage the mail queue directory. Even if a flaw in sendmail is exploited, the set of accesses granted to the attacker is strictly limited to what is specified in the configuration.

Confining Privileged Processes

Description The first statement allows ftpd to append to the wtmp file. The second statement allows ftpd to append to /var/log/xferlog. – For even better protection, a separate type could be defined for this particular log file, e.g. xferlog_t, to strictly limit the daemon to that file. The last statement allows ftpd to execute the ls program. As with the sendmail example, an attacker who subverts ftpd can only perform the actions authorized by the configuration.

Separating Processes

The /proc entries for each process are labeled with the domain of the process. These two statements grant the sysadm_t domain permission to access the /proc entries for all domains. Most domains are only allowed to access the entries for processes in the same domain.

Separating Processes

Description To protect processes in one domain from interference by processes in another domain, the example policy configuration restricts process interactions. The ability to trace other processes or send signals to other processes is typically limited to processes in the same domain, except for sending SIGCHLD to notify the parent of the completion of the child.

Description The first statement allows an ordinary user to send arbitrary signals to his netscape process. The second statement allows the netscape process to send SIGCHLD to the ordinary user process so that it can be reaped when it exits. Since there are no statements allowing an ordinary user process to send signals to an administrator process or to system processes, an ordinary user cannot interfere with these other processes. Likewise, since there are no statements allowing the user’s browser to send any signal other than SIGCHLD to other user processes, malicious mobile code executed by the browser cannot kill the user’s other processes.

Separating Processes

Description The first statement authorizes the ordinary user domain to create and unlink files in the /tmp directory. The individual controls over each file ensure that the domain cannot unlink files created by other domains, e.g. the administrator domain. The second statement allows the ordinary user domain to create and access files with the user tmp_t type. The last statement causes files created by the ordinary user domain in /tmp to be automatically labeled with this type. Similar statements are defined for the administrator domain and for other domains that use temporary files, with a separate type defined for each such domain. This ensures that ordinary users cannot create and use their own temporary files but does not allow them to access the temporary files of other domains.

Protecting the Administrator Domain

Description Since the administrator domain is highly privileged, the policy configuration must ensure that this domain can only be entered in a secure fashion. The example configuration only allows entry via domains for the login program and the newrole program. The login program is run in a separate domain for local logins than for remote logins so that the configuration can prohibit entry on remote logins, since such logins may bypass authentication via.rhosts files. However, users who are remotely logged in may still use the newrole program after login in order to enter this domain.

Description The first statement causes the login program to run in the local login_t domain when it is executed by getty. A separate statement that is not shown causes the login program to run in a separate remote login_t domain when it is executed by rlogind. The next statement allows the local_login_t domain to transition to the administrator domain. The last statement allows the newrole program to transition to the administrator domain.