Fedora Core 3 SELinux FAQ

SELinux (Security-Enhanced Linux) in Fedora Core 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.

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 just the permissions it needs to do 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 (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 can provide extremely granular control for actors in a Linux system.

The SELinux policy describes the access permissions for all subjects and objects, i.e., the entire system of users, programs, and processes and the files and devices they act upon. Fedora Core policy is delivered in a package, with an associated source package. Current shipping policy packages are:

Policy source resides in /etc/selinux/policyname/src/policy, when it is installed, and the binary policy file is in /etc/selinux/policyname/policy. Policy source is not required for ultra-minimal installations. The policy for the types and domains is configured separately from security context for the subjects and objects.

Initially, when SELinux was included in Fedora Core, the NSA strict policy was enforced. For testing purposes, this helped to find hundreds of problems in the strict policy. In addition, it became obvious that applying a single strict policy to the many environments of Fedora users was not feasible. Managing a single strict policy for anything other than default installation was going to require local expertise.

At this point, the SELinux developers reviewed their choices, and decided to try a different strategy. It was decided to create a policy that focuses on locking down specific daemons, especially ones vulnerable to attack or to devastating a system if broken or compromised. The rest of the system is allowed to run as if under standard Linux security, i.e., run the same if SELinux is enabled or not.

Under targeted policy, most processes run in the unconfined_t domain. As the name implies, these processes are mostly not being confined by the SELinux policy. They are still governed by standard Linux/UNIX security, however.

Specific network daemons have policy written for them, and the unconfined_t policy transitions to those policies when the application starts. For example, on system boot, init runs under the unconfined_t policy, but when named starts, it is transitioned to the named_t domain and is locked down by the appropriate policy.

For more information on enabling or disabling targeted policy on each of the specific daemons, refer to How to use system-config-securitylevel.

Currently, the list of daemons is dhcpd, httpd (apache.te), named, nscd, ntpd, portmap, snmpd, squid, and syslogd. The policy files for these daemons are found in /etc/selinux/targeted/src/policy/domains/program.

In the future, more daemons will be added to the targeted policy protection.

SELinux developers would like to add ftp and mail agents to targeted policy eventually. For example, vsftpd could work similar to login: after log-in, a new process is executed under the user's context (real user or an anonymous context).

One problem with mail agents is that they often need to manipulate files in user home directories. One objective of the targeted policy is to avoid labeling problems in the user home directories. This is still being worked on.

The strict policy does work on Fedora Core. It is challenged by the unique environments of different users. For it to work in your environment, you may need to tweak both the policy and your systems.

To help make it easier to use the strict policy, SELinux developers have worked on making the change from one policy to the other easier. For example, system-config-securitylevel builds a relabel into the startup scripts.

File contexts are used by the setfiles command to make the persistent labels which describe the security context for a file or directory.

Fedora Core ships with the script fixfiles which supports three options: check, restore, and relabel. This 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.

The new option -Z is the short method for displaying the context of a subject or object:

ls -alZ file.foo 
id -Z 
ps -eZ

There is no difference between a domain and a type, although domain is sometimes used to refer to the type of a process. The use of domain in this way stems from traditional TE models, where domains and types are separate.

The installer handles this based on the choice you make in the Firewall Configuration screen. The default running policy is the targeted policy, and it is on by default.

	Switching policy is not an act to be taken lightly.
	Other than trying out a new policy on a test machine for research purposes, you should seriously consider your situation before switching to a different policy on a production system. The act of switching is straightforward. This is a fairly safe method, but should be tried first on a test system.

One method is to use system-config-securitylevel to change the policy and set the file system to relabel.

Following is the manual procedure:

You can use the star utility, which supports the extended attributes that store the security context labels. Specify the -xattr and exustar format when creating archives.

ls -Z /var/log/maillog
-rw-------  root   root    system_u:object_r:var_log_t   /var/log/maillog
cd /var/log
star -xattr -H=exustar -c -f maillog.star ./maillog*

Absolute paths can overwrite existing data

If you use an absolute path, such as /var/log/maillog, when you unpack the archive with star -c -f, the files will be restored on the same path they were archived with. The maillog file will attempt to write to /var/log/maillog. You should received a warning from star if the files about to be overwritten have a later date, but you cannot count on this behavior. Consider carefully how you construct your archiving argument.

Use system-config-securitylevel to control the Boolean values of specific daemons. For example, if you find that you need to disable SELinux for Apache to run correctly in your environment, you can disable the value in system-config-securitylevel. This turns off the transition to the policy defined in apache.te, letting httpd remain under regular Linux security.

This process presumes that you have enabled user public HTML directories in Apache HTTP configuration (/etc/httpd/conf/httpd.conf). This process only covers serving static Web content. For more information about Apache HTTP and SELinux, refer to http://fedora.redhat.com/docs/selinux-apache-fc3/.

Add selinux=0 to your kernel command line.

Be careful when disabling SELinux

Be very careful using this option. If you boot with selinux=0, any files you create while SELinux is disabled will not have SELinux context information. At the least you may need to relabel the file system, and it's possible you will be unable to boot with selinux=1, requiring a boot to single-user mode for recovery. As an alternative to selinux=0, try using SELINUX=disabled in /etc/selinux/config.

You can specify the SELinux mode using the configuration file /etc/sysconfig/selinux.

# 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= type of policy in use. Possible values are:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.
SELINUXTYPE=targeted

Setting the value to enforcing is the same as adding enforcing=1 to your command line when booting the kernel to turn enforcing on, while setting the value to permissive is the same as adding enforcing=0 to turn enforcing off. Note that the command line kernel parameter overrides the configuration file.

However, setting the value to disabled is not the same as the selinux=0 kernel boot parameter. Rather than fully disabling SELinux in the kernel, the disabled setting instead turns enforcing off and skips loading a policy.

This situation usually arises when you can't perform an action that is being prevented by policy. Run the command setenforce 0 to turn off enforcing mode in real time. When you are finished, run setenforce 1 to turn enforcing back on.

	sysadm_r role required
	You must issue the setenforce command with the sysadm_r role; to do so, use the newrole command. Alternately, if you switch to root using su -, you gain the sysadm_r role automatically.

Add audit=1 to your kernel command line to turn system-call auditing on. Add audit=0 to your kernel command line to turn system-call auditing off.

System-call auditing is off by default. When on, it provides information about the system-call that was executing when SELinux generated a denied message. This may be helpful when debugging policy.

This is not supported at this time. In the future, a utility will be provided to tune auditing.

As root, execute the command /usr/sbin/sestatus -v. For more information, refer to the sestatus(8) manual page.

This message means that the current SELinux policy is not allowing the application to do something. There are a number of reasons this could happen.

First, one of the files the application is trying to access could be mislabeled. If the AVC message refers to a specific file, inspect its current label with ls -alZ /path/to/file. If it seems wrong, you could try using restorecon -v /path/to/file. If you have a large number of denials related to files, you may want to use fixfiles relabel, or run restorecon with the -R option to recursively relabel a directory path.

Other times, denials may be due to a configuration change in the program not being allowed by the policy. For example, if you change Apache to also listen on port 8800, this will require a change in the security policy, apache.te. See External Link List for more information about writing policy.

If you are having trouble getting a specific application like Apache to work, see How to use system-config-securitylevel for how to disable enforcement just for that application.

Your /home partition is not labeled correctly. You can easily fix this two different ways.

If you just want to relabel /home recursively:

/sbin/restorecon -v -R /home

If you want to be sure there are no other files incorrectly labeled, you can relabel the entire file system:

/sbin/fixfiles relabel

You will need to have the policycoreutils package installed to use fixfiles.

You can read the files from a non-SELinux distribution, or one with SELinux disabled. However, files created by the non-SELinux using systems will not have a security context, nor will any files you remove and recreate. This could be a challenge with files such as ~/.bashrc. You may have to relabel your /home when you return to Fedora Core.

Just as NFS transparently supports many file system types, it can be used to share directories between SELinux and non-SELinux systems.

When mounting a non-SELinux file system via NFS, by default SELinux will treat all the files in the share as having a context of nfs_t. You can override the default context by setting it manually using the context= option. For example, this would make the files in the NFS mounted directory appear to have a context of system_u:object_r:tmp_t to SELinux:

mount -t nfs -o context=system_u:object_r:tmp_t server:/shared/foo /mnt/foo

When SELinux exports a file system via NFS, files created will have the context of the directory they were created in. In other words, the presence of SELinux on the remote mounting system has no effect on the local security contexts.

You can create your new user with the standard useradd command. First you must become root; under the strict policy you will need to change role to sysadm_r. This context switch has been incorporated into the su command and occurs automatically. For the targeted policy, you will not need to switch roles, staying in unconfined_t:

su - root
id -Z
root:system_r:unconfined_t
useradd auser
ls -Z /home
drwx------  auser   auser   root:object_r:user_home_dir_t /home/auser  

The initial context for a new user directory has an identity of root. Subsequent relabeling of the file system will change the identity to system_u. These are functionally the same since the role and type are identical (object_r:user_home_dir_t.)

The Fedora Core development team has taken a slightly different direction than existing SELinux practice. Security context transitions are now integrated into su via pam_selinux. This greatly simplifies using the system.

In practice, this is like combining the traditional su with the SELinux newrole, as one step instead of two.

Other forms of Linux/UNIX® identity change, for example setuid(2), do not cause an SELinux identity change.

For example, if you wanted to not audit dmesg, you would put this in your /etc/selinux/targeted/src/policy/dmesg.te file:

dontaudit dmesg_t userdomain:fd { use };

This eliminates the error output to the terminal for all userdomains (user, staff and sysadm).

In a non-enforcing mode, you should actually get more messages than in enforcing mode. This occurs because the kernel is logging each access denial as if you were in an enforcing mode. Since you are not being restricted, you can perform more actions, which results in more denials being logged.

For example, if an application running under an enforcing mode was denied trying to read a number of files in a directory, it would be stopped once at the beginning of the action. In a non-enforcing mode, the application is not stopped from traversing the directory tree, and would receive a denial message for each file read in the directory.

The most common reason for a silent denial is when the policy contains an explicit dontaudit rule to suppress audit messages. The dontaudit rule is often used this way when a benign denial is filling the audit logs.

To look for your particular denial, you will need to enable auditing of all dontaudit rules:

cd /etc/selinux/targeted/src/policy 
make enableaudit
make load

	Enabled dontaudit output is verbose
	Enabling auditing of all dontaudit rules will likely produce a large amount of audit information, most of which is irrelevant to your denial. Use this technique only if you are specifically looking for an audit message for a denial that seems to occur silently. You will likely want to re-enable dontaudit rules as soon as possible.

To re-enable dontaudit rules, do the following:

cd /etc/selinux/targeted/src/policy
make clean 
make load

SELinux intentionally disables access to the tty devices to stop daemons from communicating back with the controlling terminal. This communication is a potential security hole because such daemons could insert commands into the controlling terminal. A broken or compromised program could cause serious problems with this.

There are a few ways you can capture STDOUT from daemons. One method is to pipe the output to the cat command.

snmpd -v | cat

When debugging a daemon, you may want to turn of the transitioning of the daemon to its specific domain. You can do this using system-config-securitylevel or setsebool on the command line.

A final option is to turn off enforcing mode while debugging. You can do this with setenforce 0, using setenforce 1 to re-enable SELinux when you are finished debugging.

Policy reloads itself when the package is updated. This replaces the manual make load.

In certain situations, it may be necessary to relabel the file system. This might occur as part of an SELinux bug fix where file contexts become invalid, or when the policy update makes changes to file_contexts.

After relabeling the file system, a reboot is not required but is useful in ensuring every process and program is running in the proper domain. This is highly dependent on the changes in the updated policy.

If you have installed the policy source packages, e.g. selinux-policy-strict, you can execute these commands to relabel the file system.

cd /etc/selinux/targeted/src/policy
make
make relabel
reboot

If you aren't using policy sources, another approach is to use the fixfiles command or take advantage of the /.autorelabel mechanism:

fixfiles relabel
reboot

touch /.autorelabel
reboot

Yes. The security contexts for the files owned by the package are stored in the header data for the package. The file contexts are set directly after the cpio copy, as the package files are being put on the disk.

A policy package such as selinux-policy-targeted is a requirement for a working SELinux installation, while a policy source package such as selinux-policy-targeted-sources is required if you want to customize the default policy.

The policy package has the minimum files necessary for defining the SELinux security policy. It is kept trimmed down in size to support a minimal install footprint.

The policy sources packages contain the source definitions in /etc/selinux/policyname/src/policy that are required to create the files /etc/selinux/policyname/contexts/* and /etc/selinux/policyname/policy/policy.version. version is the version number of the policy.

Choosing which packages to install is based on the type of installation. If you are going to use only the default security policy defined by the Fedora Core developers, you only need the policy package. If you want to customize your security policy in any way, or otherwise want to run setools, you need to install the policy source.

Installing or updating the policy package loads the new policy after it installs the files. Similarly, installing or updating the policy source package rebuilds the policy.version file as well as the file_contexts file, then loads them as the currently effective policy.

When you install a policy package, pre-compiled binary policy files are put directly into /etc/selinux. When a policy source package is installed or updated, binary policy files are built in /etc/selinux/policyname/src/policy, then moved to /etc/selinux/policyname/policy/. The different build environments will make target files that have different sizes, md5sums, and dates.

There is a possibility that changes in the policy package or in the policy shipping with an application package can cause errors, more denials, or other unknown behaviors. To troubleshoot, you can discover which package caused the breakage by reverting policy and application packages one at a time. If you don't want to return to the previous package, the older version of the configuration files will be saved with a label of .rpmsave. Be sure to use the mailing lists, bugzilla, and IRC to help you work through your problem. If you are able, write or fix policy to resolve your problem.

Your help is definitely appreciated. You can start by joining the SELinux mailing list, fedora-selinux-list@redhat.com; you can subscribe and read the archives at http://www.redhat.com/mailman/listinfo/fedora-selinux-list. The UnOfficial FAQ has some generic policy writing HOWTO information (http://sourceforge.net/docman/display_doc.php?docid=14882&group_id=21266#BSP.1). Another new resource is the Writing SE Linux policy HOWTO (https://sourceforge.net/docman/display_doc.php?docid=21959&group_id=21266).

Your best bet is to look at the policy files in /etc/selinux/policyname/src/policy/ and try experiments. Watch the avc denied messages in /var/log/messages for clues.

A useful tool for the policy writer is /usr/bin/audit2allow, which translates avc messages from /var/log/messages into rules that can be used by SELinux. These rules will likely need to be cleaned up.

The command audit2allow can receive input via three methods. Default is from standard input (STDIN). Using the -i option reads input from /var/log/messages, and the -d option reads input from dmesg output.

To regain useful control, turn off kernel messages to the console using dmesg -n 1.

You can test SELinux default policy by installing just the selinux-policy-policyname and policycoreutils packages. Without the policy source installed, the fixfiles command automates the file system relabeling.

The command fixfiles relabel is the equivalent of make relabel. During the relabeling, it will delete all of the files in /tmp, cleaning up files which may have old file context labels.

Other commands are fixfiles check, which checks for mislabeled files, and fixfiles restore, which fixes the mislabeled files but will not delete the files in /tmp. fixfiles does not take a list of directories as an argument, as its purpose is to relabel the entire file system. If you need to relabel a specific directory path, use restorecon.

KDE executables always appear as kdeinit, which limits what can be done with SELinux policy. This is because every KDE application runs in the domain for kdeinit.

Problems often arise when installing SELinux because it is not possible to relabel /tmp and /var/tmp. There is no good method of determining which file should have which context.

The solution is to fully log out of KDE and remove all KDE temporary files:

rm -rf	/var/tmp/kdecache-<username>
rm -rf /var/tmp/<other_kde_files>

At your next login, your problem should be fixed.

Be careful of white space in the file /etc/sysconfig/selinux. The code is very sensitive to white space, even trailing space.

The file system must support xattr labels in the right security.* namespace. In addition to ext2/ext3, XFS has recently added support for the necessary labels.

This is a variable that is hard to measure, and is heavily dependent on the size of the system SELinux is running on. When performance was last measured, the impact was around 7% for completely untuned code. Changes since then are likely to have made that worse in some cases, such as networking. SELinux performance tuning will be a priority of the development team.

Initially, SELinux will serve on Internet facing servers that are performing few, specialized functions, where it is critical to keep extremely tight security. Such a box would typically be stripped of all extra software and services, and run a very focused service or set of services, such as a Web server or mail server.

In these edge servers, you can lock down the policy very tightly. This is made easier by the smaller number of interactions with other components. Similarly, a dedicated box running a specialized third-party application would be a good candidate.

For the future, SELinux is targeted at all environments. In order to get there, the community and ISVs (independent software vendors) will need to work with the SELinux developers to produce the necessary policy. So far, a very restrictive strict policy has been written, as well as a targeted policy that focuses on specific, vulnerable daemons.

One goal of implementing a targeted SELinux policy in Fedora Core is to allow third-party applications to work without modification. This works because the targeted policy is transparent to those applications it is not trying to control that it essentially falls back on standard Linux security. These applications will not be running in an extra-secure manner. Policy needs to be written to get these applications to be protected by MAC.

There are so many variations of third-party applications that it's impossible to predict how they might behave with SELinux, even running the targeted policy. Issues that arise can sometimes be fixed in policy. You may find that SELinux shows you security issues with your application that you were not aware of, requiring the application to be modified to work under SELinux.

One important value that Fedora Core testers and users bring to the community is extensive testing of third-party applications. With that in mind, please bring your experiences to the appropriate mailing list (fedora-selinux-list@redhat.com) for discussion.