Difference between revisions of "NB Apache"

From SELinux Wiki
Jump to: navigation, search
Line 1: Line 1:
 
= Apache SELinux Support =
 
= 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>.
+
Apache web servers are supported by SELinux using the Apache policy modules from the Reference Policy (<tt>httpd</tt> modules), however there is no specific Apache object manger. There is though an SELinux-aware shared library and policy that will allow finer grained access control when using Apache with threads. 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).
+
The <tt>mod_selinux</tt> policy module makes use of the [[KernelPolicyLanguage#typebounds | typebounds statement]] that was introduced into version 24 of the policy (requires a minimum kernel of 2.6.28). <tt>mod_selinux</tt> allows threads in a multi-threaded application (such as Apache) to be bound within a defined set of permissions in that 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:
+
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:
: [http://code.google.com/p/sepgsql/wiki/Apache_SELinux-plus http://code.google.com/p/sepgsql/wiki/Apache_SELinux-plus]
+
: [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="ftn29">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:
  
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"
 
{| border="1"
Line 23: Line 24:
 
|-
 
|-
 
| <center>'''P'''</center>
 
| <center>'''P'''</center>
| PHP / Perl / Python is not currently SELinux-aware.
+
| PHP / Perl / Python are not currently SELinux-aware, however PHP and Python do have support for libselinux functions in packages: PHP - with the <tt>php-pecl-selinux</tt> package, Python - with the <tt>libselinux-python</tt> package.
  
 
|}
 
|}
Line 32: Line 33:
 
== mod_selinux Overview ==
 
== 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:
 
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><nowiki>selinuxDomainVal <security_context></nowiki></tt> entry). It is also possible to restrict its privileges as described in the [[#Bounds Overview | Bounds Overview]] section.
  
* A user sends an HTTP request to Apache that requires the services of a web application (Apache may or may not apply HTTP authentication).
+
# The web application exits, handing control back to the web server that replies with the HTTP response.
* 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 was unable to check the information flows between these different threads when using <tt>'''setcon'''(3)</tt> in pre 2.6.28 kernels. This meant that if a thread (the parent) should launch another thread (a child) with a different security context, SELinux could not enforce the different permissions.
  
=== Bounds Overview ===
+
To resolve this issue the <tt>typebounds</tt> statement was introduced with kernel support in 2.6.28 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.  
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:
 
For example the following <tt>typebounds</tt> statement and <tt>allow</tt> rules:
 
<pre>
 
<pre>
#          parent   | child
+
#          parent | child
#          domain   | domain
+
#          domain | domain
typebounds httpd_t   httpd_child_t;
+
typebounds httpd_t httpd_child_t;
  
 
allow httpd_t etc_t : file { getattr read };
 
allow httpd_t etc_t : file { getattr read };
Line 55: Line 55:
 
</pre>
 
</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.
+
State 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>. At run-time, this would not be allowed by the kernel 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.
  
 +
When <tt>'''setcon'''(3)</tt> is used to set a different context on a new thread without an associated <tt>typebounds</tt> policy statement, then the call will return 'Operation not permitted' and an <tt>SELINUX_ERR</tt> entry will be added to the audit log stating '<tt>op=security_bounded_transition result=denied</tt>' with the old and new context strings.
  
 +
Should there be a valid <tt>typebounds</tt> policy statement and the child domain exercises a privilege greater that that of the parent domain, the operation will be denied and an <tt>SELINUX_ERR</tt> entry will be added to the audit log stating '<tt>op=security_compute_av reason=bounds</tt>' with the context strings and the denied class and permissions.
 +
 +
=== Notebook Examples ===
 +
The Notebook source tarball contains two demonstrations using <tt>'''setcon'''(3)</tt> with threads and how the <tt>typebounds</tt> statement is used to allow a thread to be executed. These are located in the <tt>libselinux/examples</tt> directory and are:
 +
 +
* <tt>setcon_thread1_example.c</tt> - this example calls <tt>'''setcon'''</tt> in the main process loop but also starts a thread. If the <tt>setcon_example.conf</tt> policy module has been been loaded and a context of <tt>"unconfined_u:unconfined_r:user_t:s0</tt>" selected, then an error message should be displayed as follows:
 +
<pre>
 +
setcon_raw - ERROR: Operation not permitted
 +
</pre>
 +
This is because the <tt>'''setcon'''</tt> function cannot be run in a threaded environment without a <tt>typebounds</tt> statement. Now load the <tt>setcon_thread_example.conf</tt> policy module and then re-run the example, it should now complete without error.
 +
* <tt>setcon_thread2_example.c</tt> - this functions as example 1, however it calls <tt>'''setcon'''</tt> from a thread.
 +
 +
 +
{| style="width: 100%;" border="0"
 +
|-
 +
| [[NB_SQL_9.3 | '''Previous''']]
 +
| <center>[[NewUsers | '''Home''']]</center>
 +
| <center>[[ConfigurationFiles | '''Next''']]</center>
 +
|}
  
  
 
----
 
----
 
<references/>
 
<references/>
 +
 
[[Category:Notebook]]
 
[[Category:Notebook]]

Revision as of 13:31, 8 December 2014

Apache SELinux Support

Apache web servers are supported by SELinux using the Apache policy modules from the Reference Policy (httpd modules), however there is no specific Apache object manger. There is though an SELinux-aware shared library and policy that will allow finer grained access control when using Apache with threads. The additional Apache module is called mod_selinux.so and has a supporting policy module called mod_selinux.pp.

The mod_selinux policy module makes use of the typebounds statement that was introduced into version 24 of the policy (requires a minimum kernel of 2.6.28). mod_selinux allows threads in a multi-threaded application (such as Apache) to be bound within a defined set of permissions in that 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:

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[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.
P
PostgreSQL has SELinux support using SE-PostgreSQL.
P
PHP / Perl / Python are not currently SELinux-aware, however PHP and Python do have support for libselinux functions in packages: PHP - with the php-pecl-selinux package, Python - with the libselinux-python package.


The "A secure web application platform powered by SELinux" document gives a good overview of the LAPP architecture.

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:

  1. A user sends an HTTP request to Apache that requires the services of a web application (Apache may or may not apply HTTP authentication).
  2. Apache receives the request and launches the web application instance to perform the task:
  3. 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.
  4. 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 also possible to restrict its privileges as described in the Bounds Overview section.
  1. 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 was unable to check the information flows between these different threads when using setcon(3) in pre 2.6.28 kernels. This meant that if a thread (the parent) should launch another thread (a child) with a different security context, SELinux could not enforce the different permissions.

To resolve this issue the typebounds statement was introduced with kernel support in 2.6.28 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 typebounds statement and allow rules:

#          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 };

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

When setcon(3) is used to set a different context on a new thread without an associated typebounds policy statement, then the call will return 'Operation not permitted' and an SELINUX_ERR entry will be added to the audit log stating 'op=security_bounded_transition result=denied' with the old and new context strings.

Should there be a valid typebounds policy statement and the child domain exercises a privilege greater that that of the parent domain, the operation will be denied and an SELINUX_ERR entry will be added to the audit log stating 'op=security_compute_av reason=bounds' with the context strings and the denied class and permissions.

Notebook Examples

The Notebook source tarball contains two demonstrations using setcon(3) with threads and how the typebounds statement is used to allow a thread to be executed. These are located in the libselinux/examples directory and are:

  • setcon_thread1_example.c - this example calls setcon in the main process loop but also starts a thread. If the setcon_example.conf policy module has been been loaded and a context of "unconfined_u:unconfined_r:user_t:s0" selected, then an error message should be displayed as follows:
setcon_raw - ERROR: Operation not permitted

This is because the setcon function cannot be run in a threaded environment without a typebounds statement. Now load the setcon_thread_example.conf policy module and then re-run the example, it should now complete without error.

  • setcon_thread2_example.c - this functions as example 1, however it calls setcon from a thread.


Previous
Home
Next



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