Docs/Drafts/SELinux User Guide/SELinux Content Specification

From FedoraProject

Jump to: navigation, search

Contents

Content Specification

SELinux Introduction

On Linux operating systems, everything is represented as a file. For example, a hard disk can be represented as the /dev/hda file, and processes, such as Mozilla Firefox, are represented as files in the proc file system (/proc). These files are called objects. Linux operating systems use a Discretionary Access Control (DAC) system, that defines access to these objects. Users have access to change permissions for files and directories that they own. They could, for example, make their home directory world-readable, potentially allowing access to privileged information from other users, or giving processes, such as a Web server, access to serve these files.

Security-Enhanced Linux (SELinux) adds Mandatory Access Control (MAC) to the Linux kernel, and is enabled by default in Fedora. Stepping beyond traditional UNIX® permissions, MAC systems add fine-grained controls for defining a user's access to objects, such as files and directories. On systems running SELinux, all objects, and therefore everything on the system, are labeled with an SELinux context, that contains additional information, which is used to make access control decisions, for example, whether a subject (a process) has access to open an object (a file).

What SELinux Can Do

With SELinux, processes (subjects), such as the Apache HTTP server, run in a restricted domain. Files (objects) are labeled with a type. This type is used by Type Enforcement, which is used by MAC. SELinux policy defines the interaction subjects have with objects. This means that if the Apache HTTP server is compromised, the attacker only has access to files labeled with the correct type. Each file is labeled with an SELinux user identify, a role, and a type: selinux-user-identity:role:type.

SELinux offers:

Policy Overview

Examples

Processes being compromised, but not allowing an attacker to take over the whole system

Performance

Part of the SELinux LSM module is the security server. The security server contains policy rules, which define what access is allowed. Hooks in the Linux kernel communicate with the security server for access decisions, such as allowing or disallowing a process access to a file. An Access Vector Cache (AVC) caches decisions made by this server. This decreases how often rules in the security server need to be checked for, which increases performance.

When running SELinux in permissive mode, access rules are still checked; however, when a denial occurs, the denial is logged, and access is allowed. There is no performance decrease when SELinux is disabled, as the SELinux module is not registered with the kernel.

SELinux Contexts and Attributes

As previously mentioned, on Linux operating systems, everything is represented as a file. For example, a hard disk can be represented as the /dev/hda file, and processes, such as Mozilla Firefox, are represented as files in the proc file system (/proc). These files are called objects. Linux operating systems use a Discretionary Access Control (DAC) system, that defines access to these objects. Users have access to change permissions for files and directories that they own. They could, for example, make their home directory world-readable, potentially allowing access to privileged information from other users, or giving processes, such as a Web server, access to serve these files.

Security-Enhanced Linux (SELinux) provides a Mandatory Access Control (MAC) system for Linux operating systems. MAC restricts the control users have over the files and directories that they create. SELinux allows files, and therefore everything on a Linux system, to be labeled. This label is called an SELinux context.

For example, run the cd command to change into your home directory, and then run the touch file1 command. Use the ls -Z file1 command to view the SELinux label: 

ls -Z file1
-rw-rw-r--  username groupname user_u:object_r:user_home_t      file1

Type Enforcement (TE): fine-grained access control. MAC allow/disallow actions are checked after DAC permissions. All Files are labeled with a type. Access is only granted if it is specifically defined - the default action is to deny access. This prevents subjects (processes), such as Samba and FTP, from accessing files they should not have access to, for example, files in user home directories.

Categories: category enforcement for MCS, and security level enforcement for MLS. MCS always uses s0 - you must use MLS for other levels. MCS security level in targeted is at the discretion of the user. In MLS, the security level is mandatory.

<http://www.linuxjournal.com/article/9408>

The SELinux user and role do not effect access control for objects.

Subjects

On an SELinux system, processes, such as a user running the less command, or an Apache HTTP server, are called subjects. An executable file transitions to a process, and a process runs in a domain. When using targeted policy, domains run as the system_r role. Type Enforcement then separates each domain.

Targeted Policy Overview

...

Working with SELinux

SELinux Package Management

On Fedora 9, the SELinux packages are installed by default, unless they are manually excluded during installation. The following is a brief description of each package:

Installing SELinux on a non-SELinux System

Upgrading and Issues after Upgrades

Run the yum update command as the root user to update all packages, including the SELinux packages.

In Fedora 8, the SELinux user_u user used the system_r role, and the unconfined_t type. In Fedora 9, this user uses the user_r role, and the user_t type. Among other things, a Linux account that is mapped to the SELinux user_u account can not execute /bin/su or /usr/bin/sudo. Upgrading from Fedora 8 to 9 may have resulted in a user account that was unable to execute /bin/su or /usr/bin/sudo.

On systems prior to Fedora 9, the /usr/sbin/semanage login -l command produced the following output: 

Login Name                SELinux User              MLS/MCS Range            

__default__               user_u                    s0-s0:c0.c1023           
root                      root                      s0-s0:c0.c1023        
system_u                  system_u                  s0-s0:c0.c1023

On such systems, a Linux user account that is created without specifying an SELinux user, is mapped to the SELinux user_u user. This is defined by the __default__ entry. In Fedora 9, however, a Linux user account created without specifying an SELinux user is mapped to the SELinux unconfined_u user: 

Login Name                SELinux User              MLS/MCS Range            

__default__               unconfined_u              s0-s0:c0.c1023           
root                      unconfined_u              s0-s0:c0.c1023           
system_u                  system_u                  s0-s0:c0.c1023

To resolve this issue:

1. Run the /usr/sbin/semanage user -l command, and verify that an SELinux unconfined_u user exists: 

                Labeling   MLS/       MLS/                          
SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles

root            user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r unconfined_r
staff_u         user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r
sysadm_u        user       s0         s0-s0:c0.c1023                 sysadm_r
system_u        user       s0         s0-s0:c0.c1023                 system_r
unconfined_u    user       s0         s0-s0:c0.c1023                 system_r unconfined_r
user_u          user       s0         s0                             user_r

Note: the users listed may not be identical on all systems. If the SELinux unconfined_u user does not exist, run the following command as root to create it: 

/usr/sbin/semanage user -a -S targeted -P user -R "unconfined_r system_r" -r s0-s0:c0.c1023 unconfined_u

2. Run the following command as root to configure user accounts to be assigned to the SELinux unconfined_u user user, if one is not specified at account creation time: 

/usr/sbin/semanage login -m -S targeted  -s "unconfined_u" -r s0-s0:c0.c1023 __default__

3. Assign the root user to the SELinux unconfined_u user: 

/usr/sbin/semanage login -m -S targeted  -s "unconfined_u" -r s0-s0:c0.c1023 root

Configuration Files

The /etc/selinux/config file controls the SELinux mode and policy type. The following is an example /etc/selinux/config file: 

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these two values:
#       targeted - Targeted processes are protected,
#       mls - Multi Level Security protection.
SELINUXTYPE=targeted

Explain these options.

Files in /etc/selinux/targeted/*.

Enabling and Disabling SELinux

semanage

Booleans

Labeling Files

Adding Users

Translations

Managing and Maintaining SELinux Labels

Mounting File Systems

fscontext and defcontext options.

Managing Users

System Services

SELinux Log Files and Denials 

setroubleshoot: SELinux is preventing the httpd from using potentially mislabeled files (/var/www/html/file1). 
For complete SELinux messages. run sealert -l b66f4e5a-bd17-4324-add7-3216b1d1315e

If the audit and setroubleshoot packages are not installed, and auditd is not running, AVC denials are logged to /var/log/messages; however, if auditd is running, and the setroubleshoot packages are installed, an AVC denial and a system call audit message -- that contains more information -- is logged to /var/log/audit/audit.log. sealert is part of the setroubleshoot-server package. If installing for the first time, run the service auditd start and service setroubleshoot start commands as root to start each service.

Access Control

Describe the concepts of the following, using <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Deployment_Guide/selg-overview.html> as a guide:

SELinux rules are not checked if DAC rules deny access.

RBAC: Roles are associated with domain types, and domain types are associated with SELinux users. When not taking domain transition into account, roles do not restrict access between subjects and objects, but limit which SELinux users can exist and transition to which domains. For example, domain transition fails if the SELinux user and the new domain type are not allowed to exist in the security context that is created after a domain transition occurs. Roles are important when writing policies, but do not restrict access per se, and as such, are not discussed in detail in this guide.

Working with MCS and MLS

Retrieved from "https://fedoraproject.org/wiki/Docs/Drafts/SELinux_User_Guide/SELinux_Content_Specification"