Adding and Using suEXEC | Maximum Mac OS X Security

A different approach to Web development security is to allow CGIs to run as a specific user , rather than with the permissions of the server process. This is typically performed with suEXEC, an addition to Apache that must be compiled into the daemon.

On a trusted server with trusted developers, suEXEC can be a godsend ”no more setting special file or folder ownerships. On a system with inexperienced Web developers, however, it can open up an entirely different class of security issues. For example, rather than needing to be aware of the permissions for a single user (www in the case of Mac OS X), an administrator must be certain that anyone using suEXEC isn't opening up his or her account to attack. Files can be written and read from anywhere the suEXEC user or group has permissions.

Using suEXEC requires a complete recompile of Apache to install the necessary components . The compilation and installation process is detailed in Chapter 15, "Web Server Security," so only the configuration process is discussed here. To add suEXEC support to Apache, use the following options with the ./configure command:

--suexec-docroot=/Library/WebServer/Documents . The document root for Apache.
--suexec-userdir=Sites . The directory that individual user accounts use to serve Web documents.
--suexec-safepath=/usr/local/bin . The directories from which suEXEC will allow commands to be run. You may wish to add /usr/bin and /bin to this. Separate multiple paths with the : character.
--suexec-uidmin=500 . The minimum user ID that suEXEC will assume.
--suexec-gidmin=20 . The minimum group ID that suEXEC will assume (20 is the Staff group).
--suexec-caller=www . The user that will be executing the suEXEC process (www on Mac OS X).
--suexec-umask=077 . Sets the file creation mask suEXEC will use.
--suexec-logfile=/var/log/suexec_log . Logs suEXEC executions.

After installing, you should have a new binary: /usr/sbin/suexec . Removing this file disables suEXEC ”there is no need to change anything directly within the /etc/httpd/httpd.conf file or enable or disable support.

Using suEXEC

Configuring suEXEC is simple: User accounts that have ExecCGI access enabled will automatically take advantage of suEXEC; virtual hosts can specify a username and password by using the User and Group directives. The User directive can be given either a username or a # character followed by a user ID to set the user under which suEXEC CGIs will run ”such as User jray or User #501 . Likewise, the Group directive should be used to set the group name or ID for CGI execution.

For the most part, suEXEC is "install and forget." Target CGIs that are executed through Apache will be "wrapped" by suEXEC and invoked with the permissions of the user account if accessed through a "~" user site, or the user and group set within a Virtual Host. CGIs will not be executed the unless following criteria are met:

The user executing the wrapper is a valid user of the system.
The executing user is the Apache user (that is, www ).
The program being executed is within an Apache-accessible directory and does not contain / or .. in its name.
The CGI target user and groups are valid on the system.
The minimum user and group ID requirements have been met.
The target user and group are not the superuser or superuser group, respectively.
The target program isn't writable, nor setuid or setgid.
The owner of the target program is the same as the target user.
The environment can successfully be cleaned with a known safe PATH .

Additional information on suEXEC is available from http://httpd.apache.org/docs/suexec.html. suEXEC should not be considered a solution to Web server security problems, but a tool to help enable developers to effectively create CGIs that operate outside the normal constraints of the www user.

NOTE

An alternative (albeit less integrated, but more customizable) solution is the CGIWrap utility. For more information, visit http:// sourceforge .net/projects/cgiwrap.

Top