From: Nick Kew <niq@apache.org>
Date: Wed, 10 Dec 2008 02:26:48 +0000 (+0000)
Subject: Add security section to mod_privileges docs
X-Git-Tag: 2.3.1~150
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=33623e85487eba7a48a0c87684ea690051d72bd7;p=thirdparty%2Fapache%2Fhttpd.git

Add security section to mod_privileges docs


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@724959 13f79535-47bb-0310-9956-ffa450edef68
---

diff --git a/docs/manual/mod/mod_privileges.xml b/docs/manual/mod/mod_privileges.xml
index b6d141d30d0..f63fb075738 100644
--- a/docs/manual/mod/mod_privileges.xml
+++ b/docs/manual/mod/mod_privileges.xml
@@ -58,6 +58,92 @@ separation is an issue.</p>
 
 </summary>
 
+<section id="security"><title>Security Considerations</title>
+<p>There are three principal security concerns with mod_privileges:</p>
+<ul><li>Running as a system user introduces the same security issues
+    as mod_suexec, and near-equivalents such as cgiwrap and suphp.</li>
+<li>A privileges-aware malicious user extension (module or script)
+    could escalate its privileges to anything available to the
+    httpd process in any virtual host.</li>
+<li>A privileges-aware malicious user extension (module or script)
+    could escalate privileges to set its user ID to another
+    system user (and/or group).</li>
+</ul>
+
+<p>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.
+</p>
+
+<p>There are several ways privileges-aware code could be loaded into Apache:</p>
+<ul>
+<li>within the base system (e.g. mod_privileges itself if statically linked).</li>
+<li>Loaded at startup using a LoadModule or LoadFile directive.</li>
+<li>Loaded at startup indirectly by an application module such as mod_php.</li>
+<li>Loaded at runtime by an application module or script.</li>
+</ul>
+
+<p>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.</p>
+
+<section><title>Security with mod_php</title>
+
+<p>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.</p>
+
+<p>To prevent scripts loading privileges-aware code, PHP's dl() function
+should be disabled.  This is automatic in safe mode.</p>
+
+</section>
+
+<section><title>Security with mod_perl</title>
+
+<p>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.</p>
+
+<p>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.</p>
+</section>
+
+<section><title>Security with mod_python</title>
+
+<p>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_ruby installation.</p>
+
+<p>*** What are the issues of Python loading a shared object?</p>
+</section>
+
+<section><title>Security with mod_ruby</title>
+
+<p>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.</p>
+
+<p>*** What are the issues of Ruby loading a shared object?</p>
+</section>
+
+<section><title>Security with Lua/mod_wombat</title>
+
+<p>???</p>
+</section>
+<section><title>Security with scripts</title>
+<p>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.</p>
+</section>
+</section>
 <directivesynopsis>
 <name>VHostUser</name>
 <description>Sets the User ID under which a virtual host runs.</description>