Jaxelson at 20:46, 13 September 2010

2010-09-13T20:46:25Z

←Older revision		Revision as of 20:46, 13 September 2010
Line 62:		Line 62:
	----		----
	<references/>		<references/>
		+	[[Category:Notebook]]

RichardHaines: New page: = 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 a...

2010-05-18T15:51:08Z

New page: = 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 a...

New page

= 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 <tt>mod_selinux.so</tt> and has a supporting policy module called <tt>mod_selinux.pp</tt>.

The <tt>mod_selinux.pp</tt> policy module also makes use of the [[TypeRules#typebounds_Statement | 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:
: [http://code.google.com/p/sepgsql/wiki/Apache_SELinux-plus http://code.google.com/p/sepgsql/wiki/Apache_SELinux-plus]

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<ref name="ftn35">This is similar to the LAMP (Linux, Apache, MySQL, PHP/Perl/Python) stack, however MySQL is not SELinux-aware.</ref> (Linux, Apache, PostgreSQL, PHP / Perl / Python) stack has the following support:

{| border="1"
| <center>'''L'''</center>
| Linux has SELinux support.

|-
| <center>'''A'''</center>
| Apache has partial SELinux support using the 'Apache SELinux Plus' module.

|-
| <center>'''P'''</center>
| PostgreSQL has SELinux support using SE-PostgreSQL.

|-
| <center>'''P'''</center>
| PHP / Perl / Python is not currently SELinux-aware.

|}

The "[http://sepgsql.googlecode.com/files/LCA20090120-lapp-selinux.pdf A secure web application platform powered by SELinux]" document gives a good overview of the LAPP architecture.

== mod_selinux Overview ==
What the <tt>mod_selinux</tt> 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 <tt>mod_selinux</tt> enabled the web applications security context is identical to the Apache web server process, it is therefore not possible to restrict it privileges.
** With <tt>mod_selinux</tt> enabled the web application is launched with the security context defined in the <tt>mod_selinux.conf</tt> file (<tt>selinuxDomainVal <security_context></tt> 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 <tt>typebound</tt> 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.

For example the following <tt>typebounds</tt> statement and <tt>allow</tt> rules:
<pre>
# parent | child
# domain | domain
typebounds httpd_t httpd_child_t;

allow httpd_t etc_t : file { getattr read };
allow httpd_child_t etc_t : file { read write };
</pre>

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

----
<references/>

NB Apache - Revision history

Jaxelson at 20:46, 13 September 2010

RichardHaines: New page: = 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 a...