mod_privileges
Support for Solaris privileges and for running virtual hosts under different user IDs.
Experimental
privileges_module
Available in Apache 2.3 and up, on Solaris 10 and OpenSolaris platforms

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 perchild MPM. It also offers other security enhancements.

Unlike perchild, mod_privileges is not itself an MPM. It works within a processing model to set privileges and User/Group per request in a running process. It is therefore not compatible with a threaded MPM, and will refuse to run under one.

mod_privileges raises security issues similar to those of suexec. But unlike suexec, it applies not only to CGI programs but to the entire request processing cycle, including in-process applications and subprocesses. It is ideally suited to running PHP applications under mod_php, which is also incompatible with threaded MPMs. It is also well-suited to other in-process scripting applications such as mod_perl, mod_python, and mod_ruby, and to applications implemented in C as apache modules where privilege separation is an issue.

# Security Considerations

There are three principal security concerns with mod_privileges:

- Running as a system user introduces the same security issues as mod_suexec, and near-equivalents such as cgiwrap and suphp.
- A privileges-aware malicious user extension (module or script) could escalate its privileges to anything available to the httpd process in any virtual host.
- A privileges-aware malicious user extension (module or script) could escalate privileges to set its user ID to another system user (and/or group).

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:

- within the base system (e.g. mod_privileges itself if statically linked).
- Loaded at startup using a LoadModule or LoadFile directive.
- Loaded at startup indirectly by an application module such as mod_php.
- Loaded at runtime by an application module or script.

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

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?

## 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.
VHostUser unix-userid
Inherits the userid specified in User
virtual host
Available on Solaris 10 and OpenSolaris with non-threaded MPMs (prefork or custom MPM).

The VHostUser directive sets the Unix userid under which the server will process requests to a virtualhost. The userid is set before the request is processed and reset afterwards using Solaris Privileges. Since the setting applies to the process, this is not compatible with threaded MPMs.

Unix-userid is one of:

A username
  Refers to the given user by name.
`#` followed by a user number.
  Refers to a user by its number.

# Security

This directive cannot be used to run apache as root! Nevertheless, it opens potential security issues similar to those discussed in the suexec documentation.

User
SuexecUserGroup
VHostGroup
Sets the Group ID under which a virtual host runs.
VHostGroup unix-groupid
Inherits the group id specified in Group
virtual host
Available on Solaris 10 and OpenSolaris with non-threaded MPMs (prefork or custom MPM).

The VHostGroup directive sets the Unix group under which the server will process requests to a virtualhost. The group is set before the request is processed and reset afterwards using Solaris Privileges. Since the setting applies to the process, this is not compatible with threaded MPMs.

Unix-group is one of:

A group name
  Refers to the given group by name.
`#` followed by a group number.
  Refers to a group by its number.

# Security

This directive cannot be used to run apache as root! Nevertheless, it opens potential security issues similar to those discussed in the suexec documentation.

Group
SuexecUserGroup
VHostSecure
Determines whether the server runs with enhanced security for the virtualhost.
VHostSecure On|Off
VHostSecure On
virtual host
Available on Solaris 10 and OpenSolaris with non-threaded MPMs (prefork or custom MPM).

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.

# Note

If VHostSecure prevents an application running, this may be a warning sign that the application should be reviewed for security.

VHostCGIMode
Determines whether the virtualhost can run subprocesses, and the privileges available to subprocesses.
VHostCGIMode On|Off|Secure
VHostCGIMode On
virtual host
Available on Solaris 10 and OpenSolaris with non-threaded MPMs (prefork or custom MPM).

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 mod_cgi, nor similar external programs such as those created by mod_ext_filter or RewriteMap prog. Note that it does not prevent CGI programs running under alternative process and security models such as mod_fcgid, which is a recommended solution in Solaris.

If set to On or Secure, the virtual host is permitted to run external programs and scripts as above. Setting VHostCGIMode Secure has the effect of denying privileges to the subprocesses, as described for VHostSecure.

DTracePrivileges
Determines whether the privileges required by dtrace are enabled.
DTracePrivileges On|Off
DTracePrivileges Off
server config
Available on Solaris 10 and OpenSolaris with non-threaded MPMs (prefork or custom MPM).

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.

VHostPrivs
Assign arbitrary privileges to a virtual host.
VHostPrivs [+-]?privilege-name [[+-]?privilege-name] ...
None
virtual host
Available on Solaris 10 and OpenSolaris with non-threaded MPMs (prefork or custom MPM). and when mod_privileges is compiled with the BIG_SECURITY_HOLE compile-time option.

VHostPrivs can be used to assign arbitrary privileges to a virtual host. Each privilege-name is the name of a Solaris privilege, such as file_setid or sys_nfs.

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.

# Security

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!

VHostCGIPrivs
Assign arbitrary privileges to subprocesses created by a virtual host.
VHostPrivs [+-]?privilege-name [[+-]?privilege-name] ...
None
virtual host
Available on Solaris 10 and OpenSolaris with non-threaded MPMs (prefork or custom MPM) and when mod_privileges is compiled with the BIG_SECURITY_HOLE compile-time option.

VHostCGIPrivs can be used to assign arbitrary privileges to subprocesses created by a virtual host, as discussed under VHostCGIMode. Each privilege-name is the name of a Solaris privilege, such as file_setid or sys_nfs.

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.

# Security

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!