Fedora Core 3 SELinux FAQ

Karsten Wade

Legal Notice

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. The original authors of this document, and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
For guidelines on the permitted uses of the Fedora trademarks, refer to https://fedoraproject.org/wiki/Legal:Trademark_guidelines.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
All other trademarks are the property of their respective owners.

1. SELinux Notes and FAQ

The information in this FAQ is valuable for those who are new to SELinux. It is also valuable if you are new to the latest SELinux implementation in Fedora Core, since some of the behavior may be different than you have experienced.

[Note]This FAQ is specific to Fedora Core 3

If you are looking for the FAQ for Fedora Core 2, refer to http://fedora.redhat.com/docs/selinux-faq-fc2/.

For more information about how SELinux works, how to use SELinux for general and specific Linux distributions, and how to write policy, these resources are useful:

External Link List

[Tip]Making changes/additions to the Fedora SELinux FAQ

This FAQ is available at http://fedora.redhat.com/docs/selinux-faq-fc3/.

For changes or additions to the Fedora SELinux FAQ, use this bugzilla template, which pre-fills most of the bug report. Patches should be a diff -u against the XML, which is available from CVS (refer to http://fedora.redhat.com/projects/docs/ for details on obtaining the fedora-docs/selinux-faq module from anonymous CVS; you can get just the fedors-docs/selinux-faq module if you don't want the entire fedora-dcs tree.) Otherwise, plain text showing before and after is sufficient.

For a list of all bug reports filed against this FAQ, refer to https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=118757.

1.1. Understanding SELinux
Q: What is SELinux?
Q: What is SELinux policy?
Q: What is the SELinux targeted policy?
Q: What daemons are protected by the targeted policy?
Q: Which daemons will you add to the targeted policy? How about Sendmail, Postfix, MySQL, or PostgreSQL?
Q: What about the strict policy? Does it even work?
Q: What are file contexts?
Q: How do I view the security context of a file, user, or process?
Q: What is the difference between a domain and a type?
1.2. Controlling SELinux
Q: How do I install/not install SELinux?
Q: How do I switch the policy I'm currently using?
Q: How can I back up files from an SELinux file system?
Q: How can I install the strict policy by default with kickstart?
Q: How do I enable/disable SELinux protection on specific daemons under the targeted policy?
Q: How do I make a user public_html directory work under SELinux?
Q: How do I turn SELinux off at boot?
Q: How do I turn enforcing on/off at boot?
Q: How do I temporarily turn off enforcing mode without having to reboot?
Q: How do I turn system-call auditing on/off at boot?
Q: How do I temporarily turn off system-call auditing without having to reboot?
Q: How do I get status info about my SELinux installation?
1.3. Resolving Problems
Q: My application isn't working as expected and I am seeing avc: denied messages, how do I fix this?
Q: I installed Fedora Core on a system with an existing /home partition, and now I can't log in.
Q: After relabeling my /home using setfiles or fixfiles, will I still be able to read /home with a non-SELinux-enabled system?
Q: How do I share directories using NFS between Fedora Core and non-SELinux systems?
Q: How can I create a new Linux user account with the user's home directory having the proper context?
Q: All of the other SELinux documentation states that the su command will only change Linux identity not security role.
Q: I'm having troubles with avc errors filling my logs for a particular program. How do I choose not to audit the access for it?
Q: Even running in permissive mode, I'm getting a large number of avc denied messages.
Q: I get a specific permission denial only when SELinux is in enforcing mode, but I don't see any audit messages in /var/log/messages. How can I identify the cause of these silent denials?
Q: Why do I not see the output when I run certain daemons in debug or interactive mode?
Q: When I do an upgrade of the policy package (for example, using yum), what happens with the policy; is it updated automatically?
Q: If the policy shipping with an application package changes in a way that requires relabeling, will RPM handle relabeling the files the package owns?
Q: What is the relationship between policy and policy source packages?
Q: Why do the files /etc/selinux/policyname/policy/policy.<version> and /etc/selinux/policyname/src/policy/policy.<version> have different (sizes, md5sums, dates)?
Q: Will new policy packages disable my system?
Q: How can I help write policy?
Q: My console is being flooded with messages, how do I turn them off?
Q: Can I test the default policy without installing the policy source?
Q: I am having trouble getting KDE applications to work under SELinux.
Q: Why does SELINUX=disabled not work for me?
1.4. Deploying SELinux
Q: What file systems can I use for SELinux?
Q: How does SELinux impact system performance?
Q: What types of deployments/applications/systems, etc. should I first look to leverage SELinux in?
Q: How does SELinux affect third-party applications?

1.1. Understanding SELinux

Q: What is SELinux?
Q: What is SELinux policy?
Q: What is the SELinux targeted policy?
Q: What daemons are protected by the targeted policy?
Q: Which daemons will you add to the targeted policy? How about Sendmail, Postfix, MySQL, or PostgreSQL?
Q: What about the strict policy? Does it even work?
Q: What are file contexts?
Q: How do I view the security context of a file, user, or process?
Q: What is the difference between a domain and a type?
Q:

What is SELinux?

A:

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.

  • Discretionary access control (DAC) — this 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) — 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 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.

Q:

What is SELinux policy?

A:

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:

  • selinux-policy-strict-<version-arch>.rpm and selinux-policy-strict-sources-<version-arch>.rpm

  • selinux-policy-targeted-<version-arch>.rpm and selinux-policy-targeted-sources-<version-arch>.rpm

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.

Q:

What is the SELinux targeted policy?

A:

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.

Q:

What daemons are protected by the targeted policy?

A:

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.

Q:

Which daemons will you add to the targeted policy? How about Sendmail, Postfix, MySQL, or PostgreSQL?

A:

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.

Q:

What about the strict policy? Does it even work?

A:

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.

Q:

What are file contexts?

A:

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.

Q:

How do I view the security context of a file, user, or process?

A:

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
Q:

What is the difference between a domain and a type?

A:

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.

1.2. Controlling SELinux

Q: How do I install/not install SELinux?
Q: How do I switch the policy I'm currently using?
Q: How can I back up files from an SELinux file system?
Q: How can I install the strict policy by default with kickstart?
Q: How do I enable/disable SELinux protection on specific daemons under the targeted policy?
Q: How do I make a user public_html directory work under SELinux?
Q: How do I turn SELinux off at boot?
Q: How do I turn enforcing on/off at boot?
Q: How do I temporarily turn off enforcing mode without having to reboot?
Q: How do I turn system-call auditing on/off at boot?
Q: How do I temporarily turn off system-call auditing without having to reboot?
Q: How do I get status info about my SELinux installation?
Q:

How do I install/not install SELinux?

A:

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.

Q:

How do I switch the policy I'm currently using?

A:
[Caution]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:

  1. Edit /etc/selinux/config and change the type of policy to SELINUXTYPE=policyname.

  2. To ensure that you can return from a reboot, set the mode to SELINUX=permissive. This way SELinux will be running under the correct policy, but will let you login if there is a problem such as incorrect file context labeling.

  3. Tell the init scripts to relabel the system on reboot with the command touch /.autorelabel.

  4. Reboot the system. A clean restart under the new policy allows all system processes to be started in the proper context, and reveals any problems in the policy change.

  5. Confirm your changes took effect with the command sestatus -v. With the new system running in permissive mode, check /var/log/messages for avc: denied messages. These may indicate a problem that needs to be solved for the system to run without trouble under the new policy.

  6. When you are satisfied that the system runs stable under the new policy, enable enforcing by changing SELINUX=enforcing. You can either reboot or run setenforce 1 to turn enforcing on in real time.

Q:

How can I back up files from an SELinux file system?

A:

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*
[Caution]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.

Q:

How can I install the strict policy by default with kickstart?

A:
  1. Under the %packages section, add selinux-policy-strict.

  2. Under the %post section, add the following:

    lokkit -q --selinuxtype=strict
    touch /.autorelabel
    
Q:

How do I enable/disable SELinux protection on specific daemons under the targeted policy?

A:

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.

Q:

How do I make a user public_html directory work under SELinux?

A:

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/.

  1. If you do not already have one, you will need to create the public_html directory and populate it with the files and folders to be served.

    cd ~
    mkdir public_html
    cp /path/to/content ~/public_html
    
  2. At this point, httpd is configured to serve the contents, but you will still receive a 403 forbidden error. This is because httpd is not allowed to read the security type for the directory and files as they are created in the user's home directory. To solve this, change the security context of the folder and its contents recursively using the -R option:

    ls -Z -d public_html/
    drwxrwxr-x  auser    auser    user_u:object_r:user_home_t      public_html
    chcon -R -t httpd_user_content_t public_html/
    ls -Z -d public_html/
    drwxrwxr-x  auser    auser    user_u:object_r:httpd_user_content_t public_html/
    ls -Z public_html/
    -rw-rw-r--  auser    auser    user_u:object_r:httpd_user_content_t bar.html
    -rw-rw-r--  auser    auser    user_u:object_r:httpd_user_content_t baz.html
    -rw-rw-r--  auser    auser    user_u:object_r:httpd_user_content_t foo.html
    

    You may notice at a later date that the user field, set here to user_u, is changed to system_u. This does not affect how the targeted policy works; the field that matters is the type field.

  3. You should now be able to serve the static webpages. If you continue to have errors, check to see that the Boolean that enables user home directories is enabled. This can be set using system-config-securitylevel, under the SELinux tab within the Modify SELinux Policy area, enabling Allow HTTPD to read home directories. The changes take effect immediately.

Q:

How do I turn SELinux off at boot?

A:

Add selinux=0 to your kernel command line.

[Caution]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.

Q:

How do I turn enforcing on/off at boot?

A:

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.

Q:

How do I temporarily turn off enforcing mode without having to reboot?

A:

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.

[Note]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.

Q:

How do I turn system-call auditing on/off at boot?

A:

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.

Q:

How do I temporarily turn off system-call auditing without having to reboot?

A:

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

Q:

How do I get status info about my SELinux installation?

A:

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

1.3. Resolving Problems

Q: My application isn't working as expected and I am seeing avc: denied messages, how do I fix this?
Q: I installed Fedora Core on a system with an existing /home partition, and now I can't log in.
Q: After relabeling my /home using setfiles or fixfiles, will I still be able to read /home with a non-SELinux-enabled system?
Q: How do I share directories using NFS between Fedora Core and non-SELinux systems?
Q: How can I create a new Linux user account with the user's home directory having the proper context?
Q: All of the other SELinux documentation states that the su command will only change Linux identity not security role.
Q: I'm having troubles with avc errors filling my logs for a particular program. How do I choose not to audit the access for it?
Q: Even running in permissive mode, I'm getting a large number of avc denied messages.
Q: I get a specific permission denial only when SELinux is in enforcing mode, but I don't see any audit messages in /var/log/messages. How can I identify the cause of these silent denials?
Q: Why do I not see the output when I run certain daemons in debug or interactive mode?
Q: When I do an upgrade of the policy package (for example, using yum), what happens with the policy; is it updated automatically?
Q: If the policy shipping with an application package changes in a way that requires relabeling, will RPM handle relabeling the files the package owns?
Q: What is the relationship between policy and policy source packages?
Q: Why do the files /etc/selinux/policyname/policy/policy.<version> and /etc/selinux/policyname/src/policy/policy.<version> have different (sizes, md5sums, dates)?
Q: Will new policy packages disable my system?
Q: How can I help write policy?
Q: My console is being flooded with messages, how do I turn them off?
Q: Can I test the default policy without installing the policy source?
Q: I am having trouble getting KDE applications to work under SELinux.
Q: Why does SELINUX=disabled not work for me?
Q:

My application isn't working as expected and I am seeing avc: denied messages, how do I fix this?

A:

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.

Q:

I installed Fedora Core on a system with an existing /home partition, and now I can't log in.

A:

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.

Q:

After relabeling my /home using setfiles or fixfiles, will I still be able to read /home with a non-SELinux-enabled system?

A:

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.

Q:

How do I share directories using NFS between Fedora Core and non-SELinux systems?

A:

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.

Q:

How can I create a new Linux user account with the user's home directory having the proper context?

A:

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.)

Q:

All of the other SELinux documentation states that the su command will only change Linux identity not security role.

A:

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.

Q:

I'm having troubles with avc errors filling my logs for a particular program. How do I choose not to audit the access for it?

A:

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).

Q:

Even running in permissive mode, I'm getting a large number of avc denied messages.

A:

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.

Q:

I get a specific permission denial only when SELinux is in enforcing mode, but I don't see any audit messages in /var/log/messages. How can I identify the cause of these silent denials?

A:

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
[Caution]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
Q:

Why do I not see the output when I run certain daemons in debug or interactive mode?

A:

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.

Q:

When I do an upgrade of the policy package (for example, using yum), what happens with the policy; is it updated automatically?

A:

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
Q:

If the policy shipping with an application package changes in a way that requires relabeling, will RPM handle relabeling the files the package owns?

A:

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.

Q:

What is the relationship between policy and policy source packages?

A:

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.

Q:

Why do the files /etc/selinux/policyname/policy/policy.<version> and /etc/selinux/policyname/src/policy/policy.<version> have different (sizes, md5sums, dates)?

A:

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.

Q:

Will new policy packages disable my system?

A:

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.

Q:

How can I help write policy?

A:

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.

Q:

My console is being flooded with messages, how do I turn them off?

A:

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

Q:

Can I test the default policy without installing the policy source?

A:

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.

Q:

I am having trouble getting KDE applications to work under SELinux.

A:

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.

Q:

Why does SELINUX=disabled not work for me?

A:

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

1.4. Deploying SELinux

Q: What file systems can I use for SELinux?
Q: How does SELinux impact system performance?
Q: What types of deployments/applications/systems, etc. should I first look to leverage SELinux in?
Q: How does SELinux affect third-party applications?
Q:

What file systems can I use for SELinux?

A:

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.

Q:

How does SELinux impact system performance?

A:

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.

Q:

What types of deployments/applications/systems, etc. should I first look to leverage SELinux in?

A:

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.

Q:

How does SELinux affect third-party applications?

A:

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.