2

A common recommendation as part of web server security is to run the server daemon as an unprivileged user (e.g.: nobody) so that exploits executing arbitrary code may have less unwanted effects. However, since port 80 is a "privileged port" the server must be started as an administrator (e.g.: root) and drop privileges in request serving children.

However, I haven't found any sources that discuss the security implications of having root involved at all when running an origin server on an unprivileged port that is behind a reverse proxy.

Since the port is not privileged the origin server doesn't need to be root to bind. Are there security reasons to start the origin server as root? Why not start the server as the unprivileged user to begin with?

Assume nearly identical configurations where the only difference is that in instance A the origin server is started as root and then drops privileges while instance B is started as the unprivileged user.

benrifkah
  • 201
  • 1
  • 6

2 Answers2

1

The primary reason to start a service as root (which then downgrades to an unprivileged user) is to increase the separation between the service itself and what the service does.

The classic example is opening a privileged port, but there are other similar operations as well. For example, you may want the service to load configuration files which can't be accessed by the "child" service once the service is in operation.

Also, only root can chroot() to a jailed directory or setuid() to another user.

tylerl
  • 83,435
  • 26
  • 152
  • 232
0

Instance B: The Child May Kill the Parent

Assume both instances have a vulnerability whereby a remote attacker may craft a request causing arbitrary code to run in a child process. Also, assume that instance A which starts as root drops privileges within the child before it serves requests. This leaves the parent process running as root.

With instance B an attacker could cause the child process to kill the parent and replace the entire origin server daemon with its own daemon.

However, with instance A the parent will not listen to signals from the child so an attacker would not be able to kill the parent in this way.

Instance A: The Parent May Hash the System

Now assume a vulnerability whereby a remote attacker may craft a request causing arbitrary code to run in the parent process.

With instance A an attacker gets the keys to the city because the parent is running as root and can run arbitrary code.

However, with instance B the attacker gets limited access to whatever the unprivileged user can do.

benrifkah
  • 201
  • 1
  • 6
  • Er, I'm pretty sure an unprivileged child process can't kill a root parent process. –  May 18 '13 at 03:21
  • 1
    @IsaacFreeman this answer doesn't suggest that an unprivileged child can kill a root parent in fact paragraph 3 says that it can't. – benrifkah Jun 17 '13 at 21:06