implications of httpd_unified

[Dominick Grift]

On Tue, 2009-03-17 at 15:33 +1000, Scott Radvan wrote:

> "This Boolean is off by default, turning it on will allow all httpd
> executables to have full access to all content labeled with a http file
> context. Leaving it off makes sure that one httpd service can not
> interfere with another."

The httpd SELinux policy allows one to confine specific http content to
specific domains or sandboxes

If configured properly for example, a user cgi script gets run in a
domain specific to user scripts. That domain specific to user content
can only manage user content.

For example a user labels his cgi script with the type
httpd_user_script_exec_t. Now when apache runs this script, it will
domain transition to the httpd_user_script_t domain. This domain can
only access content with the httpd user type, for example
httpd_user_content_t.

When a sysadm labels a system cgi script with type
httpd_sys_script_exec_t, then apache will domain transition to the
httpd_sys_script_t domain specific to system scripts. This
httpd_sys_script_t domain can only access content with the sys type, for
example httpd_sys_content_t.

The httpd SELinux policy allows the operator to define more of these
specific domains. It facilitates this with the apache_content_template
for example.

So if you have a cgi webapp called myscript, Then you can run this
script in its own apache domain. You would for example create a module
and call apache_content_template(myscript)

This will create types that you can use to confine you script.
httpd_myscript_script_exec_t, httpd_myscript_content_t etc.

Now if you label your script with type httpd_myscript_script_exec_t,
apache will domain transition to httpd_myscript_script_exec_t. This
domain only has access to files with type httpd_myscript_content_t.

The idea of this model is that the different domains cannot interfere
with each other. (escalate their privilege)

If one cgi script is compromised it will not be able to affect another
script if that script is running in another domain.

Now about httpd_unified:

All httpd content is assigned an attribute: httpdcontent.
So httpd_myscript_content_t is httpdcontent but also
httpd_user_content_t is httpdcontent.

httpd_unified allows the processes to escalate to each others content.

instead of a rule like this for example:

allow httpd_myscript_script_t httpd_myscript_content_t:file read;

theres a rule:

allow httpd_myscript_script_t httpdcontent:file read;

Which says:

allow the httpd_myscript_script_t domain to read all files that have the
httpdcontent attribute assigned to them.

Which is all httpd content.

So by default you can isolate the different apache content. But if you
enable httpd_unified then that isolation is gone. (then everything will
just be httpdcontent)

It may be best to just try it.

create two simple hello world web scripts. and create a new domain for
each. Then run the scripts in their domain.

later edit the scripts to read some content that is not in their domain.
for example let them try to read a file with type httpd_sys_content_t.
This should be denied if httpd_unified is disabled.

Then enable httpd_unified and your scripts should be able to read the
file with the httpd_sys_content_t type.

Disclaimer: I might have this all wrong. Use this at your own risk.

> 
> Specifically I am interested in what is meant by a service that can not
> "interfere with another" in the case of http_unified, but any comments
> which may help me refine the description are more than welcome.

privilege escalation.

apache script a cannot access apache script b's files.

> 
> Thank you,
> 
> 

hth, Dominick