What is SELinux?
SELinux (Security-Enhanced Linux) in Fedora is an implementation of mandatory access control in the Linux kernel using the Linux Security Modules (LSM) framework. Standard Linux security is a discretionary access control model.
- Discretionary access control (DAC)
DAC is standard Linux security, and it provides no protection from broken software or malware running as a normal user or root. Users can grant risky levels of access to files they own.
- Mandatory access control (MAC)
MAC provides full control over all interactions of software. Administratively defined policy closely controls user and process interactions with the system, and can provide protection from broken software or malware running as any user.
In a DAC model, file and resource decisions are based solely on user identity and ownership of the objects. Each user and program run by that user has complete discretion over the user's objects. Malicious or flawed software can do anything with the files and resources it controls through the user that started the process. If the user is the super-user or the application is setuid or setgid to root, the process can have root level control over the entire file system.
A MAC system does not suffer from these problems. First, you can administratively define a security policy over all processes and objects. Second, you control all processes and objects, in the case of SELinux through the kernel. Third, decisions are based on all the security relevant information available, and not just authenticated user identity.
MAC under SELinux allows you to provide granular permissions for all subjects (users, programs, processes) and objects (files, devices). In practice, think of subjects as processes, and objects as the target of a process operation. You can safely grant a process only the permissions it needs to perform its function, and no more.
The SELinux implementation uses role-based access control (RBAC), which provides abstracted user-level control based on roles, and Type Enforcement® (TE). TE uses a table, or matrix to handle access controls, enforcing policy rules based on the types of processes and objects. Process types are called domains, and a cross-reference on the matrix of the process's domain and the object's type defines their interaction. This system provides extremely granular control for actors in a Linux system.
What is a SELinux policy?
The SELinux policy describes the access permissions for all subjects and objects, that is, the entire system of users, programs, and processes and the files and devices they act upon. Fedora policy is delivered in a package, with an associated source package. Current shipping policy packages are:
selinux-policy-<version>.noarch.rpm
This package is common to all types of policy and contains config files/man pages. This includes the interface files for the development environment. This replaces the -sources package from the past. This package contains the interface files used in Reference Policy along with a Makefile and a small tool called policygentool used to generate a policy template file. The interface files reside in /usr/share/selinux/devel/include directory. If you want to see all of the policy files used to build the Reference Policy you need to install the src.rpm.
selinux-policy-strict-<version>.noarch.rpm, selinux-policy-targeted-<version>.noarch.rpm, selinux-policy-mls-<version>.noarch.rpm
Installed policy and supporting files are found in subdirectories of /etc/selinux/policyname/. The subdirectories include
- policy - binary policy that is loaded into the kernel
- contexts - context/labeling policy used for making labeling decisions by programs like restorecon and fixfiles
- modules - store for policy modules that are combined to make the binary kernel policy. Note that this should note be edited by hand, as it is a private resource of libsemanage.
More information on the different policies available in SELinux can be found at http://fedoraproject.org/wiki/SELinux/Policies.
What is the SELinux targeted policy?
When SELinux was initially introduced in Fedora, it enforced the NSA strict policy. For testing purposes, this effectively exposed hundreds of problems in the strict policy. In addition, it demonstrated that applying a single strict policy to the many environments of Fedora users was not feasible. To manage a single strict policy for anything other than default installation would require local expertise.
At this point, the SELinux developers reviewed their choices, and decided to try a different strategy. They decided to create a targeted policy that locks down specific daemons, especially those vulnerable to attack or which could devastate a system if broken or compromised. The rest of the system runs exactly as it would under standard Linux DAC security.
Under the targeted policy, most processes run in the unconfined_t domain. As the name implies, these processes are mostly unconfined by the SELinux policy. They are still governed by standard Linux DAC security, however.
Those network daemons which are addressed in the targeted policy make a transition to the targeted policy when the application starts. For example, at system boot, init runs under the unconfined_t policy. When named starts, it makes a transition to the named_t domain and is locked down by the appropriate policy.
More information on the different policies available in SELinux can be found at http://fedoraproject.org/wiki/SELinux/Policies.
What programs are protected by the targeted policy?
Currently, the list of programs is approximately:
accton, amanda, httpd (apache), arpwatch, pam, automount, avahi, named, bluez, lilo, grub, canna, comsat, cpucontrol, cpuspeed, cups, cvs, cyrus, dbskkd, dbus, dhcpd, dictd, dmidecode, dovecot, fetchmail, fingerd, ftpd (vsftpd, proftpd, and muddleftpd), gpm, hald, hotplug, howl, innd, kerberos, ktalkd, openldap, auditd, syslog, logwatch, lpd, lvm, mailman, module-init-tools, mount, mysql, NetworkManager, NIS, nscd, ntp, pegasus, portmap, postfix, postgresql, pppd, pptp, privoxy, procmail, radiusd, radvd, rlogin, nfs, rsync, samba, saslauthd, snmpd, spamd, squid, stunnel, dhcpc, ifconfig, sysstat, tcp wrappers, telnetd, tftpd, updfstab, user management (passwd, useradd, etc.), crack, uucpd, vpnc, webalizer, xend, xfs, zebra
What is the mls policy? Who is it for?
The mls policy is similar to the strict policy, but adds an additional field to security contexts for separating levels. SELinux can use these levels to separate data in an environment that calls for strict hierarchical separation. A typical example is a military setting, where data is classified at a certain level. This policy is geared toward this sort of environment, and is probably not useful to you unless you fall into this category.
More information on the different policies available in SELinux can be found at http://fedoraproject.org/wiki/SELinux/Policies.
What is the Reference Policy?
The Reference Policy is a new project maintained by Tresys Technology (http://www.tresys.com/) designed to rewrite the entire SELinux policy in a way that is easier to use and understand. To do this, it uses the concepts of modularity, abstraction, and well-defined interfaces. Refer to http://oss.tresys.com/projects for more information on the Reference Policy.
Note that Reference Policy is not a new type of policy, like targeted or strict. Rather, it is a new base that policies can be built from. Targeted, strict, and mls policies can all be built from Reference Policy. In fact, one of the design goals of Reference Policy is to have a single unified source tree for the different policy variants.
Fedora policies at version 1.x are based on the traditional example policy. Version 2.x policies (as used in Fedora 5) are based on the Reference Policy.
What are file contexts?
File contexts are used by the setfiles command to generate persistent labels which describe the security context for a file or directory.
Fedora ships with the fixfiles script, which supports three options: check, restore, and relabel. This script allows users to relabel the file system without having the selinux-policy-targeted-sources package installed. The command line usage is more friendly than the standard setfiles command.
| Introduction | Table of Contents | Next Page - Software |