Docs/Drafts/SELinux User Guide/SELinux Content Specification
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:
- 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.
- Fine-grained access control: Type Enforcement allows for fine-grained access control. For example, the Apache HTTP server can only access files that are labeled with the
httpd_sys_content_ttype, and not files that are labeled with the
user_home_ttype, which is the type used for files in user home directories.
- Preventation against privilege escalation: subjects run in restricted domains. For a process, the type attribute defines which domain the process runs in. By default, a subject running in one domain can not access another domain. If a Web server is running in a protected domain, and that Web server is compromised, an attacker can only access files that the Web server has access to. SELinux also provides confined user types. Depending on the type selected, this can prevent: the use of X windows, executing files in home directories, network access, executing binaries that have the set user ID bit set, and so on.
- Role Based Access Control (RBAC): every object (files, sockets, and so on) and subject (processes) is labeled with an SELinux user identity, a role, and a type. For a subject, the type defines the restricted domain the process runs in. The role attribute defines which SELinux user identities can access which domains.
- Brief overview of SELinux Policy: <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Deployment_Guide/rhlcommon-chapter-0001.html>
- Hook in the kernel, SELinux enforces the policy.
Processes being compromised, but not allowing an attacker to take over the whole system
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
selinux_user_identity: the SELinux user account associated with an object (files) or subject (process).
selinux_user_identitydefines the owner for an object, and the user a process runs as for subjects. SELinux has a database that maps between SELinux user identities and Linux user identities (
semanage login -l).
role: attribute for Role Based Access Control. Defines which domains a process can access. RBAC controls domain transitions, such as which SELinux users can exist in which domains.
type: defines a type for objects, and a domain for subjects (processes). SELinux policy rules define how domains access types. Default deny: access is only granted if the policy specifically permits it.
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.
The SELinux user and role do not effect access control for objects.
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
- Introduction to targeted policy: <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Deployment_Guide/sec-sel-policy-targeted-oview.html>.
- Confined and unconfined processes. Explain unconfined.
- Other domains accessing unconfined_t: <http://www.nsa.gov/seLinux/list-archive/0610/17941.cfm> - when/if this is acceptable.
- Confined System Domains:
- httpd - apache man httpd_selinux
- samba man samba_selinux
- ftp man ftpd_selinux
- rsync man rsync_selinux
- kerberos man kerberos_selinux
- named man named_selinux
- nfs man nfs_selinux
- nis man nis_selinux
- ypbind man ypbind_selinux
- Confined user domains:
- Minimal login user - guest_t
- Minimal X-Windows Login User -xguest_t
- Standard User Account - user_t
- Admin User Account - staff_t
- Unconfined User - Unconfined_t
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:
policycoreutils: provides utilities to operate and manage an SELinux system. These includes but are not limited to:
semanage, for managing users, SELinux policy, translations, and permissions,
restorecon, for relabeling files with their default SELinux contexts, and
load_policy, for loading SELinux policies into the Linux kernel.
selinux-policy: provides the SELinux reference policy. The SELinux reference policy is a complete SELinux policy, and is used as a basis for other policies, such as the SELinux targeted policy. Refer to the SELinux Reference Policy project page for further information about the SELinux reference policy.
selinux-policy-[policy]: provides policies. To use targeted policy, replace [policy] with
targeted. To use MLS, replace [policy] with
mls. MCS is not mandatory when using targeted policy; however, categories are mandatory when using MLS. Strict policy has been merged in Fedora 9, allowing confined and unconfined users to co-exist on the same system.
libselinux: from the libselinux RPM package description, "libselinux provides an API for SELinux applications to get and set process and file security contexts and to obtain security policy decisions. Required for any applications that use the SELinux API."
selinux-policy-devel: provides development tools, such as a Makefile,
/usr/share/selinux/devel/policyhelptools, as well as example files.
xguest: provides an xguest user (that can log in with no password) for kiosk-style machines.
mcstrans. Not installed by default on Fedora.
Installing SELinux on a non-SELinux System
Upgrading and Issues after Upgrades
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
/usr/bin/sudo. Upgrading from Fedora 8 to 9 may have resulted in a user account that was unable to execute
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
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
/usr/sbin/semanage login -m -S targeted -s "unconfined_u" -r s0-s0:c0.c1023 root
/etc/selinux/config file controls the SELinux mode and policy type. The following is an example
# 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.
Enabling and Disabling SELinux
- Linux kernel boot options.
- What a boolean is, how to list them, how to set them, common ones people are interested in changing.
- How to label files.
- How to add users.
- How to add translations.
Managing and Maintaining SELinux Labels
- Viewing labels.
- Problems caused by running in permissive mode (allows files to be incorrectly labeled).
- Dealing with mislabeled files, relabeling a file system.
Mounting File Systems
- How to override contexts: mount -t vfat -o context=system_u:object_r:removable_t /dev/sdb /test
- When a new file is created on such a mount point, label changes are not written to disk, and are dependent upon the
mountcommand. For example, a file system could be mounted with the
httpd_sys_content_ttype, unmounted, and then mounted as the
removable_ttype. Changes to the
contextoption are not persistent across mounting and unmounting, and are for a one-time use only.
contextoption overrides the SELinux context for file systems that have already been labeled; however, the inodes for these files are not updated with the new labels -- that are specified by the
contextoption -- leaving their original SELinux contexts in tact when the file system is unmounted.
- Linux and SELinux user account mappings.
- SELinux users: xguest_u, guest_u, user_u, staff_u, etc.
- Adding a confined user.
- Adding an unconfined user.
- Modifying existing users.
- Basic transition examples (httpd and passwd)
- Apache: contexts; sharing files with other services; booleans to set to allow this.
- ISC BIND (reading and writing to zone files, log files, etc.)
SELinux Log Files and Denials
- auditd: sends a detailed denial to
- setroubleshoot translates
avc: denieddenials into a detailed description that sealert uses. (setroubleshoot and setroubleshoot-server - do these use rsyslog?) writes a denial such as the following to
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
- Search log files:
ausearch -c | -hn | -if | --input-logs |
ausearch -m avc -ts today,
ausearch -m avc | audit2allow
- Interpreting AVC denials (
sealert -l \*and setroubleshootd
- What to check for after a Denial (is DAC denying access?)
- Controlling where log files are written to?
audit2why. What these are; how to use them. Only generate Type Enforcement rules.
- Log files in permissive and enforcing mode.
- Asking for help (information needed for someone to troubleshoot problems).
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
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.
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:
- Discretionary Access Control (DAC)
- Mandatory Access Control (MAC)
- Multi-Level Security (MLS)
- Mutli-Category Security (MCS)
- Type Enforcement (TE)
- Role Based Access Control (RBAC)
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
- Overview: <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Deployment_Guide/sec-mcs-getstarted.html>, <http://www.linuxjournal.com/article/9408>
- refer to domg472 examples
- managing MCS and MLS translations