3

I am a long time technical professional but 100% of my work has been within a Windows environment. I have a pretty good level of understanding of many of the technical issues such as user account management, security and software development.

While trying to setup a VPS, running debian (this is for a personal project) I've found plenty of instructional documents that have helped me setup my system, download source and compile it.

What confuses me is that you are always discouraged to run any software as root. It seems that root should be used only to setup user accounts and permissions. However, if an account needs access to, well, nearly everything the system has to offer, the account is given root access.

If an account is given root access, isn't that account essentially root? If that's true, why can't I keep things simple (because this is a simple project) and just run everything from the VPS root account?

I assume there has to be a good answer to this and I'm just missing it. It seems counter-intuitive for it to be an important, established truth to never run software as root, yet suggest that important accounts be given root access. IMHO, this would seem like an even greater security issue because instead of there being only one root account, there are now two (or more!) accounts which could be breached.

Of course, there is another possibility-- much of the docs that I've found (through google) are wrong. If that's the case, there is an an unfortunately large amount of poor information that is provided on very professional (and often articulate) web sites. This is a shame and a bit discouraging.

RLH
  • 199
  • 10
  • 3
    Some programs start as root (say, they require a port binding < 1024) and subsequently drop privileges to another user once the needed access is done. Other than that you'd need to provide an example where you think that there is software out there that is 'frequently recommended to be ran as root'. – Matthew Ife May 05 '13 at 16:19

3 Answers3

3

I have no idea what you really mean with "giving root access" but the usual method to give someone or something administrative control over certain aspects of a system only is to use the sudo mechanism which you can fine tune to allow only the things that the user needs.

In case of deamons/services, other methods exist like dropping root privileges after starting or spawning childs running as other users.

Furthermore, there are other methods allowing even better control but they are usually much more complicated and error-prone to use (think SELinux). A general term for this approach is Role Based Access Control.

Sven
  • 98,649
  • 14
  • 180
  • 226
  • What I mean, is I've found multiple references that have talked about editing a sudo file, an adding a file permission like `user ALL=(ALL) ALL` for the user that runs a specific daemon. Maybe I'm misinterpreting this action, but it looks like it's giving the account the same level of permission that `root` has. This just seems a bit counter-intuitive (i.e. I now have 2 accounts that could be hacked, as opposed to one) because these accounts both have the right to do everything in the system. Am I wrong? – RLH May 05 '13 at 18:06
  • The idea behind this concept is something quite similar to the UAC in Windows Vista and beyond (both MS and Apple got this concept from the Unix platform) - give a user admin privileges but don't let him use them all the time so that he is normally executing programs with just user privileges and has to be actively aware that he is doing something dangerous or out of the ordinary when he as to use `sudo` to perform a task. – Sven May 05 '13 at 18:27
  • +1 for referencing the UAC-- that's something I understand. I think this is starting to make since. Not part of my initial question, but if I give an account root-level access, but it doesn't behave as root by default, how do I elevate it's behavior, when I need to perform root-level actions? – RLH May 05 '13 at 18:47
  • 1
    Two notes on the first comment: first, I know I've seen instructions where a regular user account that needs root access will have a `user ALL=(ALL) ALL` line, but I've never heard of doing that for a system account (like `www-data`, `mail`, etc.). Second, an attacker would have to either guess the root password, or guess both the admin's username and password. Either of these routes can be mitigated with a tool like [fail2ban](http://packages.debian.org/fail2ban) to slow down dictionary attacks. On the third comment, the admin user would run the elevated command through sudo, such as: – Mike Renfro May 05 '13 at 22:13
  • `sudo apt-get update` as a regular user (which prompts for a password), instead of `apt-get update` as root. – Mike Renfro May 05 '13 at 22:14
0

I think you are confused on the differences between running a user as "sudo" and using root. the program "sudo" offers users on the machine to execute superuser commands. Now even within sudo you are not running the user's account with full root access, there are still limitations within su or sudo. Also I wouldn't recommend making statements about Debian security practices, especially when asking a question like this.

user172495
  • 11
0

A lot of processes that initially require root use setuid[1] to drop privileges[2] after performing initial setup tasks that require elevated privileges. This approach has the advantage of allowing the daemon/service to perform actions which require elevated permissions at the onset and drop into a unprivileged user later on so that there is less exposure if the process malfunctions or is compromised etc.

Eg. Apache needs to bind to port 80 on the system. Port 80 is a privileged port (it's under 1024) and requires root access. So this is solved by running apache initially as root, binding the port and any other necessary setup, then using setuid to make the process run as the webserver user (www-data on ubuntu).

[1] http://en.wikipedia.org/wiki/Setuid

[2] http://en.wikipedia.org/wiki/Privilege_separation

Voltageek
  • 1