Revision as of 20:46, 13 September 2010

Apache SELinux Support

Apache web servers are generally managed under SELinux by using the Apache policy modules from the Reference Policy, however an SELinux-aware shared library is available that will allow finer grained access control as described in this section. The additional Apache module is called mod_selinux.so and has a supporting policy module called mod_selinux.pp.

The mod_selinux.pp policy module also makes use of the typebounds statement that was introduced into version 24 of the policy (that requires a minimum kernel of 2.6.28). This was introduced to allow threads in a multi-threaded application (such as Apache) to be bound within a defined set of permissions (i.e. the child domain cannot have greater permissions than the parent domain).

These components are known as 'Apache / SELinux Plus' and are described in the sections that follow, however a full description including configuration details is available from the following web site:

The objective of these Apache add-on services is to achieve a fully SELinux-aware web stack (although not there yet). For example currently the LAPP[1] (Linux, Apache, PostgreSQL, PHP / Perl / Python) stack has the following support:

L

Linux has SELinux support.

A

Apache has partial SELinux support using the 'Apache SELinux Plus' module.

mod_selinux Overview

What the mod_selinux module achieves is to allow a web application (or a 'request handler') to be launched by Apache with a security context based on policy rather than that of the web server process itself, for example:

A user sends an HTTP request to Apache that requires the services of a web application (Apache may or may not apply HTTP authentication).

Apache receives the request and launches the web application instance to perform the task:

Without mod_selinux enabled the web applications security context is identical to the Apache web server process, it is therefore not possible to restrict it privileges.

With mod_selinux enabled the web application is launched with the security context defined in the mod_selinux.conf file (selinuxDomainVal <security_context> entry). It is therefore possible to restrict its privileges as described in the Bounds Overview section below.

The web application exits, handing control back to the web server that replies with the HTTP response.

Bounds Overview

Because multiple threads share the same memory segment, SELinux is unable to check the information flows between these different threads. This means that if a thread (the parent) should launch another thread (a child) with a different security context, SELinux cannot enforce the different permissions (this is why pre 2.6.28 kernels did not allow a different security context to be set on a thread).

To resolve this issue the typebound statement was introduced that stops a child thread (the 'bounded domain') having greater privileges than the parent thread (the 'bounding domain') i.e. the child thread must have equal or less permissions than the parent.

States that the parent domain (httpd_t) has file:{getattr read} permissions. However the child domain (httpd_child_t) has been given file:{read write}. This would not be allowed by the compiler because the parent does not have write permission, thus ensuring the child domain will always have equal or less privileges than the parent.

↑ This is similar to the LAMP (Linux, Apache, MySQL, PHP/Perl/Python) stack, however MySQL is not SELinux-aware.