<-
Apache > HTTP Server > Documentation > Modules

Apache Module mod_privileges 3og2w

Available Languages:  fr 

Description: for Solaris privileges and for running virtual hosts under different IDs.
Status: Experimental
Module Identifier: privileges_module
Source File: mod_privileges.c
Compatibility: Available in Apache 2.3 and up, on Solaris 10 and OpenSolaris platforms

Summary 6m2os

This module enables different Virtual Hosts to run with different Unix 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 /Group per request in a running process. It is therefore not compatible with a threaded MPM, and will refuse to run under one.

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.

 Apache!

Topics 2c136y

Directives 1a4l6m

Bugfix checklist 4i2533

See also 27136x

top

Security Considerations 636c3h

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 PrivilegesMode directive allows you to select either FAST or SECURE mode. You can mix modes, using FAST mode for trusted s and fully-audited code paths, while imposing SECURE mode where an untrusted 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 s for their convenience, and protect them and the server against the risks posed by honest mistakes, but you trust your s are not deliberately subverting system security. In a hostile situation - e.g. commercial hosting - you may have s 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 (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 who is able to introduce privileges-aware code running before the start of the request-processing cycle.

top

DTracePrivileges Directive 6x2t2d

Description: Determines whether the privileges required by dtrace are enabled.
Syntax: DTracePrivileges On|Off
Default: DTracePrivileges Off
Context: server config
Status: Experimental
Module: mod_privileges
Compatibility: 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.

top

PrivilegesMode Directive 2122g

Description: Trade off processing speed and efficiency vs security against malicious privileges-aware code.
Syntax: PrivilegesMode FAST|SECURE|SELECTIVE
Default: PrivilegesMode FAST
Context: server config, virtual host, directory
Status: Experimental
Module: mod_privileges
Compatibility: 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 6h505h

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 id/gid set.
top

VHostCGIMode Directive 175v62

Description: Determines whether the virtualhost can run subprocesses, and the privileges available to subprocesses.
Syntax: VHostCGIMode On|Off|Secure
Default: VHostCGIMode On
Context: virtual host
Status: Experimental
Module: mod_privileges
Compatibility: 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 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.

top

VHostCGIPrivs Directive 3w2g2u

Description: Assign arbitrary privileges to subprocesses created by a virtual host.
Syntax: VHostCGIPrivs [+-]?privilege-name [[+-]?privilege-name] ...
Default: None
Context: virtual host
Status: Experimental
Module: mod_privileges
Compatibility: Available on Solaris 10 and OpenSolaris with non-threaded MPMs (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 3oj6g

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!

top

VHostGroup Directive 1l556v

Description: Sets the Group ID under which a virtual host runs.
Syntax: VHostGroup unix-groupid
Default: Inherits the group id specified in Group
Context: virtual host
Status: Experimental
Module: mod_privileges
Compatibility: 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 3oj6g

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

See also 27136x

top

VHostPrivs Directive 1u1133

Description: Assign arbitrary privileges to a virtual host.
Syntax: VHostPrivs [+-]?privilege-name [[+-]?privilege-name] ...
Default: None
Context: virtual host
Status: Experimental
Module: mod_privileges
Compatibility: Available on Solaris 10 and OpenSolaris with non-threaded MPMs (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 3oj6g

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!

top

VHostSecure Directive 12323o

Description: Determines whether the server runs with enhanced security for the virtualhost.
Syntax: VHostSecure On|Off
Default: VHostSecure On
Context: virtual host
Status: Experimental
Module: mod_privileges
Compatibility: 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 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 196q6v

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

top

VHost Directive 494s2b

Description: Sets the ID under which a virtual host runs.
Syntax: VHost unix-id
Default: Inherits the id specified in
Context: virtual host
Status: Experimental
Module: mod_privileges
Compatibility: Available on Solaris 10 and OpenSolaris with non-threaded MPMs (prefork or custom MPM).

The VHost directive sets the Unix id under which the server will process requests to a virtualhost. The id 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-id is one of:

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

Security 3oj6g

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

See also 27136x

Available Languages:  fr 

top

Comments 2p1l6j

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our s if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.