Building Apache the Way You Want It - Building Apache with suExec support (Page 10 of 13 )
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. |
Next: Configuring Apache 2 for Cross-Platform Builds >>
More Apache Articles
More By Apress Publishing
|
 This article is from chapter three of the book Pro Apache third edition, written by Peter Wainwright (Apress, 2004; ISBN: 1590593006). Check it out at your favorite bookstore. Buy this book now.
|
|
