[Fedora-packaging] SELinux testing

[James Morris]

Many packages are not being tested with SELinux enabled before release,
which is increasing the number of software defects being shipped, and
causing users to disable SELinux.  It is well documented that the cost of
fixing software defects rises dramatically the further from the source
they are experienced, and the worst possible case is after the software is
shipped and deployed.  For Fedora, these costs can be thought of in terms
of cost to the project's goodwill and cost of everyone's time dealing with
usually trivially addressable SELinux policy issues.

Given that SELinux is a core security feature of the OS, enabled by 
default, I'd like to propose that the Fedora project establishes a simple 
guideline for package maintainers in relation to SELinux testing.

This guideline would request that developers test their package with 
SELinux enabled (and by this I mean in enforcing mode) and follow a simple 
procedure:

1. Ensure they have the latest SELiunx policy installed.
2. Boot with selinux=1 and in enforcing mode.
3. Perform the normal testing of their application.
4. Check syslog (or /var/log/audit/audit.log if audit is enabled) for AVC 
   messages related to their package.

If there are any bugs or AVC messages:

5. Obtain support from the SELinux team.  The best way to do this I
believe is to file a bugzilla against the selinux-policy package.  They
should note that they are a Fedora packager (and expect a high priority
response).  If SELinux is running all or most of the time, issues will be
caught and fixed eariler in their dev cycle.

6. Don't release the package until the SELinux issue is resolved.

7. If for some reason, #2 is not possible, and the release of the package 
is important enough to warrant disabling a core security feature of the 
OS:

7a. Make a note of the bugzilla # from (1) in the rpm info, cvs commit and
release notes, with an explanation.  Also include a standardized
disclaimer in the rpm info which advises the user of the security risks
arising from disabling SELinux.  This should only happen in truly
exceptional cases.  I'm not sure how we can reliably notify users that
SELinux can be re-enabled again, and whether they'll tolerate the entire
fs being relabeled on reboot.  Really, this just should not happen.

Perhaps we can establish some kind of approval scheme for releasing a
package which requires SELinux to be disabled (or for that matter, any
security feature).



Thoughts?




-- 
James Morris
<jmorris at redhat.com>