From: Nick Kew Date: Tue, 5 May 2009 14:08:31 +0000 (+0000) Subject: Documentation update for mod_privileges changes in r771144/771145. X-Git-Tag: 2.3.3~654 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=3775c02540f2ca8376194bd44498547e494bb8d7;p=thirdparty%2Fapache%2Fhttpd.git Documentation update for mod_privileges changes in r771144/771145. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@771733 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_privileges.xml b/docs/manual/mod/mod_privileges.xml index 3054a89a6e5..d9873dbb95e 100644 --- a/docs/manual/mod/mod_privileges.xml +++ b/docs/manual/mod/mod_privileges.xml @@ -59,91 +59,105 @@ separation is an issue.

Security Considerations -

There are three principal security concerns with mod_privileges:

+ +

mod_privileges introduces new security concerns +in situations where untrusted code may be run +within the webserver process. This applies to +untrusted modules, and scripts running under modules such as +mod_php or mod_perl. Scripts running externally (e.g. as CGI +or in an appserver behind mod_proxy or mod_jk) are NOT affected.

+ +

The basic security concerns with mod_privileges are:

- -

The first is amply discussed in the suexec page and elsewhere, and -doesn't need repeating here. The second and third boil down to one -principle: ensure no untrusted privileges-aware code can be loaded. -

- -

There are several ways privileges-aware code could be loaded into Apache:

- -

What gets loaded at startup is under the control of the sysop, and -relatively easy to deal with. A tool will be provided to audit your -installation. That leaves code loaded in the course of processing a -request as the threat. There is unfortunately no generic way apache -can control what a script running under an application module can load, -so you should use the security provided by your scripting module -and language.

- -
Security with mod_php - -

There is no known PHP extension supporting Solaris privileges, so it -is unlikely that a script could escalate privileges unless it can -load external (non-PHP) privileges-aware code. However, you should -nevertheless audit your mod_php installation.

- -

To prevent scripts loading privileges-aware code, PHP's dl() function -should be disabled. This is automatic in safe mode.

- -
- -
Security with mod_perl - -

Perl has an extension Sun::Solaris::Privileges that exposes the privileges -API to scripts. You should ensure this extension is NOT installed if you -have untrusted users.

- -

You will also need to ensure that your users cannot load shared objects -(including PerlXS) from their own user directories, or that if this is -enabled, the entire user-space must be carefully audited.

-
- -
Security with mod_python +

The PrivilegesMode directive allows you to +select either FAST or SECURE mode. You can +mix modes, using FAST mode for trusted users and +fully-audited code paths, while imposing SECURE mode where an +untrusted user has scope to introduce code.

+

Before describing the modes, we should also introduce the target +use cases: Benign vs Hostile. In a benign situation, you want to +separate users for their convenience, and protect them and the server +against the risks posed by honest mistakes, but you trust your users +are not deliberately subverting system security. In a hostile +situation - e.g. commercial hosting - you may have users deliberately +attacking the system or each other.

+
+
FAST mode
+
In FAST mode, requests are run in-process with the +selected uid/gid and privileges, so the overhead is negligible. +This is suitable for benign situations, but is not secure against an +attacker escalating privileges with an in-process module or script.
+
SECURE mode
+
A request in SECURE mode forks a subprocess, which +then drops privileges. This is a very similar case to running CGI +with suexec, but for the entire request cycle, and with the benefit +of fine-grained control of privileges.
+
+

You can select different PrivilegesModes for +each virtual host, and even in a directory context within a virtual +host. FAST mode is appropriate where the user(s) are +trusted and/or have no privilege to load in-process code. +SECURE mode is appropriate to cases where untrusted code +might be run in-process. However, even in SECURE mode, +there is no protection against a malicious user who is able to +introduce privileges-aware code running before the start of the +request-processing cycle.

-

There is no known Python extension supporting Solaris privileges, so it -is unlikely that a script could escalate privileges unless it can -load external (non-Python) privileges-aware code. However, you should -nevertheless audit your mod_python installation.

- -

*** What are the issues of Python loading a shared object?

+ +PrivilegesMode +Trade off processing speed and efficiency vs security against +malicious privileges-aware code. +PrivilegesMode FAST|SECURE|SELECTIVE + + server config + virtual host + directory + +Available on Solaris 10 and OpenSolaris with +non-threaded MPMs (prefork or custom MPM). +

This directive trades off performance vs security against +malicious, privileges-aware code. In SECURE mode, each request +runs in a secure subprocess, incurring a substantial performance penalty. +In FAST mode, the server is not protected against escalation +of privileges as discussed above.

+

This directive differs slightly between a <Directory> + context (including equivalents such as Location/Files/If) and a + top-level or <VirtualHost>.

+

At top-level, it sets a default that will be inherited by virtualhosts. + In a virtual host, FAST or SECURE mode acts on the entire + HTTP request, and any settings in a <Directory> + context will be ignored. A third pseudo-mode + SELECTIVE defers the choice of FAST vs SECURE to directives in a + <Directory> context.

+

In a <Directory> context, it is applicable only + where SELECTIVE mode was set for the VirtualHost. Only + FAST or SECURE can be set in this context (SELECTIVE would be +meaningless).

+Warning + Where SELECTIVE mode is selected for a virtual host, the activation + of privileges must be deferred until after the mapping + phase of request processing has determined what + <Directory> context applies to the request. + This might give an attacker opportunities to introduce + code through a RewriteMap + running at top-level or <VirtualHost> context + before privileges have been dropped and userid/gid set. + + + -
Security with mod_ruby - -

There is no known Ruby extension supporting Solaris privileges, so it -is unlikely that a script could escalate privileges unless it can -load external (non-Ruby) privileges-aware code. However, you should -nevertheless audit your mod_ruby installation.

- -

*** What are the issues of Ruby loading a shared object?

-
- -
Security with Lua/mod_wombat - -

???

-
-
Security with scripts -

The security issues of mod_privileges do not affect scripts such as -traditional CGI, which run in a separate process. That includes -PHP, Perl, Python, Ruby, etc, run out-of-process.

-
-
VHostUser Sets the User ID under which a virtual host runs.