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

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

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.