Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question

migrated from serverfault.com Jun 18 '13 at 19:28

This question came from our site for professional system and network administrators.

2 Answers 2

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.

share|improve this answer

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.

share|improve this answer
    
Er, I'm pretty sure an unprivileged child process can't kill a root parent process. –  Isaac Freeman May 18 '13 at 3: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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.