This module enables different Virtual Hosts to run with different
Unix™ User and Group IDs, and with different
Solaris Privileges. In particular, it offers a solution to the
problem of privilege separation between different Virtual Hosts, first
promised by the abandoned
Unlike
There are three principal security concerns with mod_privileges:
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.
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.
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.
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.
*** What are the issues of Python loading a shared object?
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?
???
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.
The
Unix-userid is one of:
# followed by a user number.This directive cannot be used to run apache as root! Nevertheless, it opens potential security issues similar to those discussed in the suexec documentation.
The
Unix-group is one of:
# followed by a group number.This directive cannot be used to run apache as root! Nevertheless, it opens potential security issues similar to those discussed in the suexec documentation.
Determines whether the virtual host processes requests with security enhanced by removal of Privileges that are rarely needed in a webserver, but which are available by default to a normal Unix user and may therefore be required by modules and applications. It is recommended that you retain the default (On) unless it prevents an application running. Since the setting applies to the process, this is not compatible with threaded MPMs.
If
Determines whether the virtual host is allowed to run fork and exec,
the privileges required to run subprocesses. If this is set to
Off the virtualhost is denied the privileges and will not
be able to run traditional CGI programs or scripts under the traditional
If set to On or Secure, the virtual host
is permitted to run external programs and scripts as above.
Setting
This server-wide directive determines whether Apache will run with the privileges required to run dtrace. Note that DTracePrivileges On will not in itself activate DTrace, but DTracePrivileges Off will prevent it working.
A privilege-name may optionally be prefixed by + or -, which will respectively allow or deny a privilege. If used with neither + nor -, all privileges otherwise assigned to the virtualhost will be denied. You can use this to override any of the default sets and construct your own privilege set.
This directive can open huge security holes in apache, up to and including running requests with root-level powers. Do not use it unless you fully understand what you are doing!
A privilege-name may optionally be prefixed by + or -, which will respectively allow or deny a privilege. If used with neither + nor -, all privileges otherwise assigned to the virtualhost will be denied. You can use this to override any of the default sets and construct your own privilege set.
This directive can open huge security holes in apache subprocesses, up to and including running them with root-level powers. Do not use it unless you fully understand what you are doing!