Security of user switching support in Passenger

First, let us take a look at the typical Apache setup, in which Apache is bound to port 80, and uses the prefork MPM. Binding to any port lower than 1024 requires root privileges, so Apache is typically run as root. This poses an unacceptable security risk, so Apache’s prefork MPM will, upon receiving an HTTP request, spawn a child process with the privileges of a normal user, typically www-data or nobody. See the documentation for the prefork MPM - in particular the “User” and “Group” directives - for details. The process which is responsible for spawning child processes (also called the control process) is run as root. This is also true for the worker MPM.

Since Passenger has access to the control process, in the typical Apache setup, Passenger can already launch Rails applications as a different user. But now we have to ask this question:

If the answer is yes, then we cannot use this method.

The advantage of this method is that setting up Apache to run as root is incredibly easy, and requires no new framework to be written. However, testing this method in automated unit tests will require running the unit test suite as root.

Apache’s suEXEC allows one to run CGI processes as different users. But it seems that suEXEC can only be used for CGI, and is not a general-purpose mechanism. The PHP-suEXEC software allows one to run PHP applications via suEXEC, but it requires patching suEXEC. If Passenger is to use suEXEC, then it is likely that we’ll have to patch suEXEC. The suEXEC website strongly discourages patching.

If we use this method, we must be extremely careful. It must not be possible for arbitrary processes to gain root privileges. We want Passenger, and only Passenger, to be able to gain root privileges.

There are multiple ways to implement this security. The first one is to use a password file, which only Apache and the wrapper can read, through the use of proper file permissions. The password file must never be world readable or writable.

It works as follows:

An obvious problem that arises is: how does the wrapper locate its own password file? We obviously do not want to be able to specify the password filename as an argument to the wrapper: that would defeat the point of the password file. The solution is that the filename is to be hardcoded into the binary during compile time.

Another way to implement security is to use a whitelist of users that are allowed to use the wrapper. The wrapper can then check whether the calling process’s user is in the whitelist.

Writing a wrapper is not too hard. Furthermore, unit tests do not have to be run as root, in contrast to the run-Apache-as-root method.

A setuid $X wrapper will work in a fashion similar to the setuid root wrapper, i.e. it will use a password file for authorization.

Passenger does not spawn Rails applications itself, but does so via the spawn server. This spawn server is also responsible for preloading the Rails framework and the Rails application code, in order to speed up the spawning of Rails applications. See the design document of the spawn server for details. The spawn server never calls exec(): doing so will make preloading useless. If Passenger is to use a setuid $X wrapper, then it must start the spawn server via the wrapper. The spawn server itself cannot use the wrapper.

However, doing so will make preloading less efficient. Passenger will be forced to run a spawn server for each user. The different spawn servers do not share memory with each other, so a lot of memory is wasted compared to the other methods.

Implementing this will also take more work. One has to create a different wrapper for each user, and to install it.

The standard Unix su tool asks for the root password. It’s a bad idea for Apache to know the root password, so using su is not a viable alternative.

It might be possible to use the sudo utility. sudo can be configured in such a way that the user Apache runs as can use sudo without having to enter a password.

However, Passenger uses an anonymous communication channel (an unnamed Unix socket) to communicate with the spawn server. sudo seems to close all file descriptors before executing an application, so Passenger will have to communicate with the spawn server via a non-anonymous channel, such as a named Unix socket. Because other processes can access this channel, it can introduce potential security problems. Note that passing information via program arguments is not secure: it is possible to view that information with tools like ps, or (on Linux) by reading the file /proc/$PID/cmdline.

So it seems sudo is not a viable alternative.

Whatever method Passenger will use, the following security principles must be honored:

It might also be worthy to look into suEXEC’s security model for inspiration.

Also, the following questions remain: