include("site.inc"); $template = new Page; $template->initCommon(); $template->displayHeader(); ?>
Copyright © 2004 Red Hat, Inc.
Beta document | |
---|---|
This is a beta document. Technical facts contained here have been checked, but may not work as expected on your system. The ideas contained here are accurate, as of this writing, but may suffer from a lack of clarity. If you discover a bug or wish to otherwise make a comment, please fill out this bug report, which has most of the fields prefilled. |
The Apache HTTP Server (httpd) is one of the most complex daemons shipped in Fedora Core or Red Hat Enterprise Linux. It has support for many kinds of shared extension libraries, embeddable programming languages, and has one of the most powerful and complex configuration file formats. It supports executing CGI scripts from potentially untrusted users, as well as allowing them control over access (.htaccess), and more.
When examining the SELinux security policy source for Apache HTTP for the first time, you will notice it also seems complex. Certainly it is the most complex and configurable of any of the SELinux policies. The truth is that it is software such as Apache that is complex - SELinux is just revealing that complexity.
However, SELinux is a flexible technology. You can use it to achieve very broad security goals such as keeping a compromised Apache from damaging the rest of the system, as well as much more fine grained goals such as preventing a compromise of a wiki CGI script from corrupting a blog installation owned by the same person.
This guide looks at the Apache HTTP SELinux policy shipped with Fedora Core 3, and demonstrates how to use SELinux to protect Apache HTTP in various scenarios.