Assigning web content types

For standard web server configurations (without SELinux), access rights on resources for a web server are purely based on the ownership of the files (and the access mask applied to it). With SELinux, the resources can be labeled more specifically towards their functional meaning.

Web applications have content that should be read-only and content that should be read-write, but there are also specific types for resources such as .htaccess files. In this recipe, we'll look at the various web server content types and apply them to the right resources.

How to do it…

Execute the following steps to assign specific web content types to the right resources:

1. Take a look at the available content types for web servers by asking SELinux to show us all types that have the httpdcontent attribute set:

   ~$ seinfo –ahttpdcontent –x
    httpdcontent
    httpd_sys_content_t
    httpd_user_ra_content_t
    httpd_user_rw_content_t
    httpd_nagios_content_t
   …
   

2. Query the existing policy for known context assignations (as those can give us pointers to what is still lacking):

   ~$ semanage fcontext –l | grep httpd_nagios
   

3. Now, assign the right context to those resources that aren't labeled correctly yet. The paths used here are an example for a Nagios installation:

   ~# semanage fcontext –a –t httpd_nagios_content_t /var/www/html/nagios(/.*)?
   ~# semanage fcontext –a –t httpd_nagios_script_exec_t /usr/local/lib/nagios/cgi-bin/.*
   ~# restorecon –R /var/www/html/nagios /usr/local/lib/nagios
   

How it works

The web server policy supports functional content types for web applications. These types are used for the following content types:

• Read-only content of the web application
• Writable content of the web application (for which a distinction is made between full writable content and content that can only be appended to, such as logfiles)
• Executable scripts (for CGI scripts and similar content)

The advantage is not so much that there is the distinction of read-only versus read-write, but that this is supported on a per-application basis, with types that are specific to one application. In the example, we looked at the content for the Nagios monitoring application.

This allows administrators to provide access to these resources towards specific applications or users. Even though all content in /var/www/html/ might be owned by the Apache Linux user, we can still grant users (and applications) access to application-specific resources without needing to grant those users or applications full privileges on all Apache resources.

For the read-only content, there is the regular web application content (httpd_nagios_content_t) and the special .htaccess content (httpd_nagios_htaccess_t). The distinction is made primarily because access to the regular content is given more broadly (and depending on some SELinux Booleans, this can also become writable content), whereas the .htaccess content remains read-only.

To query the available web server content, we used the httpdcontent attribute. This attribute is assigned to all content, allowing administrators to create policies that govern all web content. The httpdcontent attribute is given to all these types, but there are also attributes called httpd_rw_content, httpd_ra_content, httpd_htaccess_type, and httpd_script_exec_type to allow for manipulation of those specific resources.

There's more...

We covered Nagios as an example web application, which has a set of web application related resources. Many other web applications or applications with web content have already been identified policy-wise.

On Linux distributions that have all known policies loaded by default, this overview will already be visible through the seinfo command as per our preceding example. If that isn't the case, we can always search through the SELinux policies to find out which modules call the apache_content_template—the interface that automatically generates the right web application content types:

~$ grep apache_content_template ${POLICY_LOCATION}/policy/modules/*/*.te

When different types become more troublesome than helpful, it is possible to ask the SELinux policy to see all those different types as just one common web content type and be done with it. This is supported through the httpd_unified Boolean. When this Boolean is enabled, the web server policy will treat all various web server resource types as one, unifying all the types. And, if the Booleans, httpd_enable_cgi and httpd_builtin_scripting, are enabled as well, then the web server domain has the privilege to execute that content as well.

Needless to say, unifying the web server resource contexts might make management simpler; it also increases the privileges of the web server domain towards various web resources, making it potentially less secure.