Security of user switching support in Passenger

A straightforward implementation of Passenger will spawn Rails applications in the same user context as Apache itself. On server machines which host multiple websites for multiple users, this may not be desired. All Rails applications spawned by Passenger will be able to read and write to all directories that the web server can. So for example, Joe's Rails applications could read Jane's Rails application's database.yml or delete her application files. This is also a problem that typically plagues PHP web hosts.

There are multiple ways to solve this problem. The goal of this document is to inform the reader about the solutions have we have analyzed, so that Passenger's security may be peer reviewed.

It seems that the only way to solve this problem on Unix, is to run each Rails application server as its owner's user and group. Passenger can make use of one of the following methods to implement this:

Let us take a look at each method in detail.

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 suit 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:

Running Apache as root and writing a setuid root wrapper are the main contestants. The former is preferred, because it's easier to implement.

We have had some conversations with people on the IRC channel #rubyonrails. Among those people, nobody has ever run Apache as non-root. Because of this we have chosen to implement the Running Apache as root solution, until a significant number of users request us to implement the setuid root wrapper solution.

Please read the Ruby API documentation — in particular that of the ApplicationSpawner class — for implementation details. But to make a long story short: it will switch to the owner of the file config/environment.rb. User whitelisting/blacklisting is currently not implemented. We rely on the system administrator to set the correct owner on that file.

We have also not implemented suEXEC's security model. suEXEC's model is quite paranoid, and although paranoia is good to a certain extend, it can be in the way of usability while proving little extra security. We are not entirely convinced that implementing suEXEC's full security model will provide significant benefits, but if you have good reasons to think otherwise, please feel free to discuss it with us.