Security Considerations

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:

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

DTracePrivileges Directive

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.

PrivilegesMode Directive

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).

VHostCGIMode Directive

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.

VHostCGIPrivs Directive

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.

VHostGroup Directive

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.

See also

• Group
• SuexecUserGroup

VHostPrivs Directive

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.

VHostSecure Directive

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.

VHostUser Directive

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.

See also

• User
• SuexecUserGroup