Building Apache with suExec support - Apache

suExec is a security wrapper for Unix systems that runs CGI scripts under a different user and group identity than the main server. It works by inserting itself between Apache and the external script and changing the user and group of the external process to a user and group configured for the server or virtual host. This allows you to have each virtual host run scripts under its privileges and thus partition them from each other. Before you build suExec, it’s worth considering that Apache 2 provides a different solution to the same problem in the shape of the perchild multiprocessing module, which allows you to define a user and group identity per virtual host.

To get suExec support, you must tell Apache to use it at build time with the --enable-suexec option:

$ ./configure --enable-suexec

On its own, this is rare enough, however. For suExec to actually work, it also needs to have various configuration options set. None of these are configurable from Apache’s configuration to keep the suExec wrapper secure from tampering, so if you need to set them, you must define them at build time. Some of the defaults are also slightly odd and aren’t governed by selecting an Apache layout, so if you use a different layout, you’ll probably need to set some of them.

NOTE suExec is built so that it can only be run by the user and group of the main server as configured at build time. If you want to have suExec run by any User other than the default, then it’s not enough to change the settings of the User and Group directives in the server-level configuration—they must also be defined at build time so that suExec recognizes them.

Of particular note are the minimum values of the user and group ID and the document root. The user and group IDs are lower limits that are compared to Apache’s User and Group settings. They constrain the user and group under that suExec will allow itself to be run. This prevents the root user being configured, for example. If you want to use your own user and group with suExec, then you have to ensure that the correct settings are established up front; if you change them later to something below the allowed minimum values, then you must rebuild suExec or it’ll detect that it’s being run by the wrong user or group and refuse to cooperate.

The document root setting is slightly misnamed; it determines where suExec will permit executables to be run from. For a single Web site, it should be the document root, but for virtual hosts, it should be a parent directory that’s sufficiently broad enough to include all the virtual host document root directories somewhere beneath it. For example, if you have all your virtual hosts under /home/www/ virtualhostname, then the document root for suExec should be /home/www.

Table 3-6 lists all the configure options that control suExec.

Table 3-6. suExec Configure Script Options

Option	Description
[1.3] --server-uid=UID	Sets the user ID that Apache will run under, and that
[2.0] --with-server-uid=UID	suExec will allow execution by. The default is nobody.
[1.3] --server-gid=GID	Sets the group ID that Apache will run under and that
[2.0] --with--server-gid=GID	suExec will allow execution by. The default is nobody
	under Apache 1.3 and #-1 under Apache 2.
[1.3] --suexec-caller=NAME	Sets the name of the user that’s allowed to call suExec.
[2.0] --with-suexec-caller=NAME	This should be set to the name of the User directive in
	httpd.conf. The default is www.
[1.3] --suexec-docroot=DIR	Sets the root directory of documents governed by
[2.0] --with-suexec-docroot=DIR	suExec. This affects the user directory processing of
	suExec. The default is PREFIX/htdocs.
[1.3] --suexec-logfile=FILE	Determines the location of suExec’s log file. By default
[2.0] --with-suexec-logfile=FILE	this is the master server log directory.
[1.3] --suexec-userdir=DIR	Specifies the name of the subdirectory as inserted into
[2.0] --with-suexec-userdir=DIR	URLs by mod_userdir. If user directories are in use
	and implemented by mod_userdir (as opposed to
	mod_rewrite, say), suExec needs to know what the
	substituted path is to operate correctly. The default is
	public_html, which is also the default of the UserDir
	directive in mod_userdir.
[1.3] --suexec-uidmin=UID	Specifies the minimum allowed value of the User
[2.0] --with-suexec-uidmin=UID	directive when evaluated as a numeric user ID. The
	default is 100, restricting access to special accounts,
	which are usually under 100 on Unix systems.
[1.3] --suexec-gidmin=UID	Specifies the minimum allowed value of the Group
[2.0] --with-suexec-gidmin=UID	directive when evaluated as a numeric group ID. The
	default is 100, restricting access to special accounts,
	which are usually under 100 on Unix systems.
[1.3] --suexec-safepath=PATH	Defines the value of the PATH environment variable
[2.0] --with-suexec-safepath=PATH	passed to CGI scripts. This should only include
	directories that are guaranteed to contain safe
	executables. The default is /usr/local/bin:/usr/
	bin:/bin. Paranoid administrators may want to
	redefine this list to remove /usr/local/bin, or
	redefine it to nothing.
[1.3] --suexec-umask=UMASK	Specifies the maximum permissions allowed in the
[2.0] --with-suexec-umask=UMASK	user file-creation mask of the suExec executable as an
	octal number. By default the server’s umask is used,
	usually 022 (no group or other execute permission).
	This is also the hard limit, and suExec will refuse to
	even compile with a more generous setting. You can
	make the event more restrictive, however. To have
	suExec refuse to execute anything that’s group-
	writable, world-writable, or world-readable, use a
	umask of 026 (new in Apache 1.3.10).

This requirement of forcing suExec to be configured at compile time rather than runtime may seem more than a little inconvenient, but this deliberate inflexibility has more than a little to do with the fact that Apache has a very good reputation for security. If you compare this to the almost continual litany of exploits for some less popular proprietary Web servers that emphasize convenience over security, it becomes easier to put up with this relatively minor sort of inconvenience for the greater security it gives you.

To find out what settings an existing suExec binary has been compiled with, you can use the -V option, for example:

$ /usr/local/apache/bin/suexec -V
 -D AP_DOC_ROOT="/home/sites"
 -D AP_GID_MIN=100
 -D AP_HTTPD_USER="httpd"
 -D AP_LOG_EXEC="/usr/local/apache/logs/cgi.log"
 -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
 -D AP_UID_MIN=100
 -D AP_USERDIR_SUFFIX="public_html"

suExec is installed into the bin directory (it moved here from the sbin directory since Apache 1.3.12; if these are set to the same place, the distinction is moot). Also, Apache 2 abstracts support for suExec within Apache itself into the new mod_suexec module and installs this into the configured libexec directory. This is potentially very handy because it allows you to disable suExec support by removing the module and add it later if you need it. Apache 1.3 doesn’t allow you this freedom as it integrates suExec support into the core.

NOTE In this chapter I’ll cover building and installing of suExec. I’ll cover the configuration and set up of suExec in Chapter 6.

Configuring Apache’s Supporting Files and Scripts

As well as configuring the build process for Apache itself, configure also sets up the various supporting scripts and applications that come as standard with Apache. These range from shell scripts such as apachectl through Perl scripts such as dbmmanage and apxs to compiled binaries.

After the Apache executable has been built, the configuration process carries out some additional stages to clean it of unnecessary symbol information (useful for debugging but useless baggage for a production environment) and to substitute your configuration information into Apache’s supporting configuration files and scripts.

As with everything else, you can impose some control over this as well. Table 3-7 shows the options that control which of these stages are carried out by configure.

Table 3-7. Apache 1.3 Configure Options for Supporting Files and Scripts

Option	Description			Compatibility
--with-perl=FILE		The location of the local Perl interpreter. This is		Apache 1.3 only
required by several of Apache’s support scripts,
including apxs and dbmmanage. Normally, configure
works out the location automatically, but if Perl is
installed somewhere obscure or there’s more than
one interpreter, this option tells configure which
of the scripts to use.
--without-support			Tells configure not to set up, compile, or install	Apache 1.3 only
any of the supporting applications.
--without-confadjust Tells configure not to substitute information				Apache 1.3 only
derived at the configuration stage into the
installed Apache configuration files.

In Apache 2, you can also choose whether those supporting tools that are built from source are linked statically or dynamically, in much the same way as you can choose the static or dynamic status of modules. All of these tools are built dynamically by default, but you can make some or all of them into statically linked executables with one of the options in Table 3-8. 

Table 3-8. Apache 2 Configure Options for Statically Linking Support Files and Scripts

Option	Description
--enable-static-support	All support executables are built statically.
--enable-static-ab	The Apache benchmarking tool ab is built statically.
--enable-static-checkgid	The group ID checking tool checkgid is built statically.
--enable-static-htdbm	The DBM-based basic authentication password tool htdbm is
	built statically.
--enable-static-htdigest	The file-based digest authentication password tool htdigest
	is built statically.
--enable-static-htpasswd	The file-based basic authentication password tool htpasswd
	is built statically.
--enable-static-logresolve	The IP to hostname DNS resolver logresolve is built
	statically.
--enable-static-rotatelogs	The log rotation tool rotatelogs is built statically.

>>> More Apache Articles          >>> More By Apress Publishing

blog comments powered by Disqus