| 59 |
</summary> |
</summary> |
| 60 |
|
|
| 61 |
<section id="security"><title>Security Considerations</title> |
<section id="security"><title>Security Considerations</title> |
| 62 |
<p>There are three principal security concerns with mod_privileges:</p> |
|
| 63 |
|
<p><module>mod_privileges</module> introduces new security concerns |
| 64 |
|
in situations where <strong>untrusted code</strong> may be run |
| 65 |
|
<strong>within the webserver process</strong>. This applies to |
| 66 |
|
untrusted modules, and scripts running under modules such as |
| 67 |
|
mod_php or mod_perl. Scripts running externally (e.g. as CGI |
| 68 |
|
or in an appserver behind mod_proxy or mod_jk) are NOT affected.</p> |
| 69 |
|
|
| 70 |
|
<p>The basic security concerns with mod_privileges are:</p> |
| 71 |
<ul><li>Running as a system user introduces the same security issues |
<ul><li>Running as a system user introduces the same security issues |
| 72 |
as mod_suexec, and near-equivalents such as cgiwrap and suphp.</li> |
as mod_suexec, and near-equivalents such as cgiwrap and suphp.</li> |
| 73 |
<li>A privileges-aware malicious user extension (module or script) |
<li>A privileges-aware malicious user extension (module or script) |
| 74 |
could escalate its privileges to anything available to the |
could escalate its privileges to anything available to the |
| 75 |
httpd process in any virtual host.</li> |
httpd process in any virtual host. This introduces new risks |
| 76 |
|
if (and only if) mod_privileges is compiled with the |
| 77 |
|
<var>BIG_SECURITY_HOLE</var> option.</li> |
| 78 |
<li>A privileges-aware malicious user extension (module or script) |
<li>A privileges-aware malicious user extension (module or script) |
| 79 |
could escalate privileges to set its user ID to another |
could escalate privileges to set its user ID to another system |
| 80 |
system user (and/or group).</li> |
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> |
|
| 81 |
</ul> |
</ul> |
| 82 |
|
|
| 83 |
<p>What gets loaded at startup is under the control of the sysop, and |
<p>The <directive>PrivilegesMode</directive> directive allows you to |
| 84 |
relatively easy to deal with. A tool will be provided to audit your |
select either <var>FAST</var> or <var>SECURE</var> mode. You can |
| 85 |
installation. That leaves code loaded in the course of processing a |
mix modes, using <var>FAST</var> mode for trusted users and |
| 86 |
request as the threat. There is unfortunately no generic way apache |
fully-audited code paths, while imposing SECURE mode where an |
| 87 |
can control what a script running under an application module can load, |
untrusted user has scope to introduce code.</p> |
| 88 |
so you should use the security provided by your scripting module |
<p>Before describing the modes, we should also introduce the target |
| 89 |
and language.</p> |
use cases: Benign vs Hostile. In a benign situation, you want to |
| 90 |
|
separate users for their convenience, and protect them and the server |
| 91 |
<section><title>Security with mod_php</title> |
against the risks posed by honest mistakes, but you trust your users |
| 92 |
|
are not deliberately subverting system security. In a hostile |
| 93 |
<p>There is no known PHP extension supporting Solaris privileges, so it |
situation - e.g. commercial hosting - you may have users deliberately |
| 94 |
is unlikely that a script could escalate privileges unless it can |
attacking the system or each other.</p> |
| 95 |
load external (non-PHP) privileges-aware code. However, you should |
<dl> |
| 96 |
nevertheless audit your mod_php installation.</p> |
<dt>FAST mode</dt> |
| 97 |
|
<dd>In <var>FAST</var> mode, requests are run in-process with the |
| 98 |
<p>To prevent scripts loading privileges-aware code, PHP's dl() function |
selected uid/gid and privileges, so the overhead is negligible. |
| 99 |
should be disabled. This is automatic in safe mode.</p> |
This is suitable for benign situations, but is not secure against an |
| 100 |
|
attacker escalating privileges with an in-process module or script.</dd> |
| 101 |
</section> |
<dt>SECURE mode</dt> |
| 102 |
|
<dd>A request in <var>SECURE</var> mode forks a subprocess, which |
| 103 |
<section><title>Security with mod_perl</title> |
then drops privileges. This is a very similar case to running CGI |
| 104 |
|
with suexec, but for the entire request cycle, and with the benefit |
| 105 |
<p>Perl has an extension Sun::Solaris::Privileges that exposes the privileges |
of fine-grained control of privileges.</dd> |
| 106 |
API to scripts. You should ensure this extension is NOT installed if you |
</dl> |
| 107 |
have untrusted users.</p> |
<p>You can select different <directive>PrivilegesMode</directive>s for |
| 108 |
|
each virtual host, and even in a directory context within a virtual |
| 109 |
<p>You will also need to ensure that your users cannot load shared objects |
host. <var>FAST</var> mode is appropriate where the user(s) are |
| 110 |
(including PerlXS) from their own user directories, or that if this is |
trusted and/or have no privilege to load in-process code. |
| 111 |
enabled, the entire user-space must be carefully audited.</p> |
<var>SECURE</var> mode is appropriate to cases where untrusted code |
| 112 |
</section> |
might be run in-process. However, even in <var>SECURE</var> mode, |
| 113 |
|
there is no protection against a malicious user who is able to |
| 114 |
<section><title>Security with mod_python</title> |
introduce privileges-aware code running <em>before the start of the |
| 115 |
|
request-processing cycle.</em></p> |
|
<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_python 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> |
|
| 116 |
|
|
|
<p>*** What are the issues of Ruby loading a shared object?</p> |
|
| 117 |
</section> |
</section> |
| 118 |
|
<directivesynopsis> |
| 119 |
|
<name>PrivilegesMode</name> |
| 120 |
|
<description>Trade off processing speed and efficiency vs security against |
| 121 |
|
malicious privileges-aware code.</description> |
| 122 |
|
<syntax>PrivilegesMode FAST|SECURE|SELECTIVE</syntax> |
| 123 |
|
<contextlist> |
| 124 |
|
<context>server config</context> |
| 125 |
|
<context>virtual host</context> |
| 126 |
|
<context>directory</context> |
| 127 |
|
</contextlist> |
| 128 |
|
<compatibility>Available on Solaris 10 and OpenSolaris with |
| 129 |
|
non-threaded MPMs (<module>prefork</module> or custom MPM).</compatibility> |
| 130 |
|
<usage><p>This directive trades off performance vs security against |
| 131 |
|
malicious, privileges-aware code. In <var>SECURE</var> mode, each request |
| 132 |
|
runs in a secure subprocess, incurring a substantial performance penalty. |
| 133 |
|
In <var>FAST</var> mode, the server is not protected against escalation |
| 134 |
|
of privileges as discussed above.</p> |
| 135 |
|
<p>This directive differs slightly between a <code><Directory></code> |
| 136 |
|
context (including equivalents such as Location/Files/If) and a |
| 137 |
|
top-level or <code><VirtualHost></code>.</p> |
| 138 |
|
<p>At top-level, it sets a default that will be inherited by virtualhosts. |
| 139 |
|
In a virtual host, FAST or SECURE mode acts on the entire |
| 140 |
|
HTTP request, and any settings in a <code><Directory></code> |
| 141 |
|
context will be <strong>ignored</strong>. A third pseudo-mode |
| 142 |
|
SELECTIVE defers the choice of FAST vs SECURE to directives in a |
| 143 |
|
<code><Directory></code> context.</p> |
| 144 |
|
<p>In a <code><Directory></code> context, it is applicable only |
| 145 |
|
where SELECTIVE mode was set for the VirtualHost. Only |
| 146 |
|
FAST or SECURE can be set in this context (SELECTIVE would be |
| 147 |
|
meaningless).</p> |
| 148 |
|
<note type="warning"><title>Warning</title> |
| 149 |
|
Where SELECTIVE mode is selected for a virtual host, the activation |
| 150 |
|
of privileges must be deferred until <em>after</em> the mapping |
| 151 |
|
phase of request processing has determined what |
| 152 |
|
<code><Directory></code> context applies to the request. |
| 153 |
|
This might give an attacker opportunities to introduce |
| 154 |
|
code through a <directive module="mod_rewrite">RewriteMap</directive> |
| 155 |
|
running at top-level or <code><VirtualHost></code> context |
| 156 |
|
<em>before</em> privileges have been dropped and userid/gid set. |
| 157 |
|
</note> |
| 158 |
|
</usage> |
| 159 |
|
</directivesynopsis> |
| 160 |
|
|
|
<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> |
|
| 161 |
<directivesynopsis> |
<directivesynopsis> |
| 162 |
<name>VHostUser</name> |
<name>VHostUser</name> |
| 163 |
<description>Sets the User ID under which a virtual host runs.</description> |
<description>Sets the User ID under which a virtual host runs.</description> |
Parent Directory
| 
Revision Log
| 
Patch