Fedora Core 2 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

[Important]Upgrade to Fedora Core 3

The Fedora SELinux development team recommends upgrading to Fedora Core 3. SELinux in Fedora Core 2 is nonfunctional due to kernel and policy incompatibilities.

The infrastructure and procedures in place for Fedora Core 3 should protect against the problems that occurred during kernel updates to Fedora Core 2. From a usability standpoint, the environmental changes currently in Fedora Core 3 make an upgrade the preferred SELinux solution.

SELinux in Fedora Core 2 represents the labor and lessons learned throughout the testing process. Version 2 features full support for SELinux, but the default installation behavior is disabled. To install SELinux, you need to pass the selinux option to the installer. For more information, continue reading the 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 SELinux implementation in Fedora Core, since some of the behavior may be different than you have experienced.

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:

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

This FAQ is version selinux-faq-1.2-12 (2005-01-20-T16:20-0800) and is available at http://fedora.redhat.com/docs/selinux-faq-fc2/.

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.) 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 the difference between a domain and a type?
Q: What is SELinux policy?
Q: What are file contexts?
Q: How do I view the security context of a file, user, or process?
1.2. Controlling SELinux
Q: Since Fedora Core 2 installs with SELinux disabled by default, how do I enable SELinux in the installer?
Q: How do I install SELinux on a running Fedora Core 2 that didn't have SELinux installed through Anaconda?
Q: How do I turn SELinux off?
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 select which policy I'm using?
Q: How do I get status info about my SELinux installation?
1.3. Resolving Problems
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: 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 the policy and policy-sources packages?
Q: Why do the files /etc/security/selinux/policy.<version> and /etc/security/selinux/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 policy-sources?
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 the difference between a domain and a type?
Q: What is SELinux policy?
Q: What are file contexts?
Q: How do I view the security context of a file, user, or process?
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.

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

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, processes, files, and devices. Fedora Core policy is delivered in policy-<version-arch>.rpm or policy-sources-<version-arch>.rpm.

Policy source resides in /etc/security/selinux/src/policy, when it is installed, and the binary policy file is in /etc/security/selinux. 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 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 a new script fixfiles which supports three options: check, restore, and relabel. This allows users to relabel the file system without having the policy-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

1.2. Controlling SELinux

Q: Since Fedora Core 2 installs with SELinux disabled by default, how do I enable SELinux in the installer?
Q: How do I install SELinux on a running Fedora Core 2 that didn't have SELinux installed through Anaconda?
Q: How do I turn SELinux off?
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 select which policy I'm using?
Q: How do I get status info about my SELinux installation?
Q:

Since Fedora Core 2 installs with SELinux disabled by default, how do I enable SELinux in the installer?

A:

The installer, Anaconda, takes the selinux option at the boot prompt. This installs Fedora Core with SELinux enabled.


boot: linux selinux

Q:

How do I install SELinux on a running Fedora Core 2 that didn't have SELinux installed through Anaconda?

A:

Since SELinux is now part of the kernel, installation is straightforward. You are enabling systems already in place.

  1. Install a policy and the policy utilities with with yum install policy policycoreutils.

  2. Create or edit /etc/sysconfig/selinux and set SELINUX=permissive in it. The file should have the standard permissions set with chmod 644 /etc/sysconfig/selinux.

  3. Relabel your file system with fixfiles relabel. This will take at least several minutes, as each file on the system is checked and labeled for the newly installed policy.

  4. Reboot your system. Check /var/log/messages for avc: denied messages. You may need to relabel the files again now that you are running fully under an SELinux policy domain. Resolve any issues while still in permissive mode, and once you can boot without avc denials, set SELINUX=enforcing in /etc/sysconfig/selinux.

    For resolving avc: denied messages, you will find http://fedora.redhat.com/mailman/listinfo/fedora-selinux-list to be a useful resource.

Q:

How do I turn SELinux off?

A:

Adding selinux=0 to your kernel command line disables SELinux at boot. Optionally, you can disable SELinux in run time in the latest Fedora Core 2 kernel by setting SELINUX=disabled in /etc/sysconfig/selinux.

[Warning]Warning

Be very careful using this option. 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.

The kernel that shipped with Fedora Core 2 had a different behavior when you set SELINUX=disabled in /etc/sysconfig/selinux. Instead of unregistering the SELinux hooks from the kernel, SELinux was actually loaded without a policy. This was changed in later kernels.

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 is a comment field in /etc/sysconfig/selinux
#
# Allowable values are:
#     enforcing  -  enables enforcing mode
#     permissive -  enables permissive mode
#     disabled   -  disables SELinux
SELINUX=<value>

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.

In the kernel that shipped with Fedora Core 2, setting the value to disabled was not the same as the selinux=0 kernel boot parameter. However, updated kernels act exactly the same if you disable in run time or at boot -- SELinux hooks and pseudo file system are unregistered entirely.

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

You must issue the setenforce command with the sysadm_r role; to do so, use the newrole command. Alternately, choose the appropriate role when doing su.

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 select which policy I'm using?

A:

Currently there are two methods for selecting the policy you are running under. You will be given the choice during installation, or you can edit /etc/security/selinux/src/policy/tunable.te.

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 setstatus(8) manual page.

1.3. Resolving Problems

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: 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 the policy and policy-sources packages?
Q: Why do the files /etc/security/selinux/policy.<version> and /etc/security/selinux/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 policy-sources?
Q: I am having trouble getting KDE applications to work under SELinux.
Q: Why does SELINUX=disabled not work for me?
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 fix this by relabeling /home:


/usr/sbin/setfiles /etc/security/selinux/file_contexts /home

Alternately, you can use the fixfiles utility to relabel /home; fixfiles is a script that runs setfiles with more user-friendly command line usage and options.

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

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, but first you must become root with a context of sysadm_r. This context switch has been incorporated into the su command:


su - root
 Your default context is root:sysadm_r:sysadm_t.
 Do you want to choose a different one? [n] n
useradd auser
ls -Z /home
drwxr-xr-x  auser     auser     root:object_r:user_home_dir_t          /home/auser

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/security/selinux/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/security/selinux/src/policy
make enableaudit
make load

[Caution]Caution

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/security/selinux/src/policy
make clean
make load

Q:

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

A:

Current policy reloads itself when the package is updated. This replaces the manual make load. Fedora Core developers are working on the RPM hooks to fully automate this process.

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-sources package, you can execute these commands to relabel the file system.


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

You can also use the fixfiles command:


fixfiles relabel
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 the policy and policy-sources packages?

A:

The policy package is a requirement for a working SELinux installation, while policy-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 package contains the source definitions in /etc/security/selinux/src that are required to create the files /etc/security/selinux/file_contexts and /etc/security/selinux/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 policy-sources.

Installing or updating the policy package loads the new policy after it installs the files. Similarly, installing or updating the policy-sources 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/security/selinux/policy.<version> and /etc/security/selinux/src/policy/policy.<version> have different (sizes, md5sums, dates)?

A:

When you install the policy package, a pre-compiled binary policy file is put directly at /etc/security/selinux. When the policy-source package is installed or updated, binary policy files are built in /etc/security/selinux/src/policy, then moved to /etc/security/selinux. 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/security/selinux/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.

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 policy-sources?

A:

You can test SELinux default policy by installing just the policy 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.

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 we cannot relabel /tmp and /var/tmp. There is no good method of determining which file should have each 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:

For the present, SELinux will serve you best 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.

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 so transparent 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.