51

Playing devil's advocate,

Let's assume I purchase a Linux server from a hosting provider. I am given a password for the root user and am told I may login using SSH. The only purpose this server has is to host one or more websites, possibly with SSL properly configured and enabled.

My initial login will be to install (via a well-reviewed and widely used package management system) and configure (by editing files in /etc) a web server, a database, some software that does not access the Internet, and a web-application server (PHP-FPM, Unicorn, that sort of thing). The package management was smart enough to set up unprivileged users to run the servers, a configuration I maintain. Next I put some website files (PHP, Ruby, Python, etc) in /var/www, and chown all the those files to be owned by the same unprivileged user that runs runs as the web server process (ie. www-data).

In the future, only I will login, and only to update the web site files and to perform some read-only operations like reviewing logs.

In the scenario above, is there any security-related reason, why I should create a non-root user account to use rather than the root user? After all, almost every command would be run with sudo had I logged in with a non-root user.

Please Note: I understand there are many universally compelling security and non-security reasons to use non-root user(s). I am not asking about the necessity for non-root user accounts. My question is strictly limited to the limited setup I describe above. I think this is relevant because even though my example is limited, it is very common.

Volker Siegel
  • 119
  • 8
  • 4
    Ideally, your scripts should be owned by a different user than the `www-data` user used by the webserver (and `chmod 600`). This way, if your webserver (`nginx`, `apache`, etc.) is successfully attacked, the attacker cannot edit or view the contents of your application code. This alone seems like a worthwhile precaution. – Stephen Touset Dec 24 '13 at 03:28
  • 3
    It's not a security reason, but the best reason is to minimize damage from mistakes. An accidental 'rm -rf foo *' by a user is a lot less damaging than one performed by root. It's System Administration Best Practices - assume you'll shoot yourself in the foot now and then, carry the smallest gun necessary. – gowenfawr Dec 24 '13 at 13:54
  • 1
    Similar question on [unix.se]: [Is there any point in using `sudo` when you are the sole user of your machine?](http://unix.stackexchange.com/questions/106558/is-there-any-point-in-using-sudo-when-you-are-the-sole-user-of-your-machine) – Gilles 'SO- stop being evil' Dec 25 '13 at 22:50
  • 1
    Somewhat related: http://superuser.com/questions/662739/using-the-root-account-on-a-single-user-system/662764 – Joó Ádám Apr 30 '16 at 21:48
  • 1
    @StephenTouset The web server must still be able to *read* what it is supposed to *serve* to the user, right? So with something like PHP, for example, which must *parse* and *interpret* the application files, `644` is all you can get. This prevents `www-data` from *writing* to the files, at least. – caw Feb 07 '18 at 06:03
  • God only knows what I was thinking in 2013, but I believe I was referring to the executable application code itself (and not static web assets), which (if served by a language-specific application server) wouldn't need to be readable or writable by the webserver user. That said, `chmod u+w` isn't really appropriate because the application server shouldn't be able to write to the files either. Ideally, static web assets would be `chown ${DEPLOYER}:${WEB_SERVER}`, application code `chown ${DEPLOYER}:${APP_SERVER}`, and the files all `chown 0644` or `chown 0640` (with `+x` for directories). – Stephen Touset Feb 07 '18 at 23:13

4 Answers4

43

There are a few reasons:

  • traceabilty: Commands run with sudo are logged. Commands run with bash are sometimes logged, but with less detail and using a mechanism that is easy to block.

  • privilege separation: almost every command is not the same as every command. There's still plenty which doesn't require root

  • file editing: the web files are owned by a non-root user and run by a non-root user... so why would you edit them with root?

  • attack mitigation: Consider the following totally-not-even-hypothetical scenario: Your workstation gets some malware on it which filches your FTP/SCP/SFTP/SSH login out of the stored authentication database from the appropriate client and transmits it to the attacker. The attacker logs on to your device to do some mischief. Now, can they cover their tracks, or will what they do be visible to you? I talk to someone new more than once every week to whom this has recently happened.

  • automated attack mitigation: A hacked server in Brazil is scanning your network and pulls up a listening SSH server. What username does the attacker use for his automated attack? Maybe webuser, or test, or www or admin -- but more than any other: root.

There are certainly many more reasons, but these are the first ones to come to my head.

smokris
  • 199
  • 1
  • 2
  • 5
tylerl
  • 82,225
  • 25
  • 148
  • 226
  • Good points, but that last one can be (somewhat) mitigated by not allowing password-based logins. –  Dec 24 '13 at 03:27
  • 11
    @TerryChia all of them can be *mitigated*. In fact, the danger in driving on the wrong side of the road can be *mitigated* by wearing a seat belt. That doesn't make it suddenly a good idea, though. – tylerl Dec 24 '13 at 03:30
  • You're right, @TerryChia but defense in depth is important. Sometimes you accidentally push a faulty SSH configuration. Sometimes someone who doesn't know better turns on password logins. Sometimes there's a bug in the software, and the configuration is ignored. – Stephen Touset Dec 24 '13 at 03:30
  • 3
    Defeating traceability is as easy as `sudo bash` and `shopt -u -o history`. – Alicia May 21 '14 at 09:48
  • You may want to add that privilege separation also helps to protect bugs in software, in a way that an attacker that entered through a bug like shellshock cannot alter files not belonging to the server account – Ferrybig Dec 23 '15 at 14:45
  • I stopped using sudo long ago as it provides no defense for malice. It worked well when it was novel but not anymore ... I now require su to root. – Joshua Mar 27 '17 at 15:58
  • 1
    @Joshua I stopped using su long ago as it provides no defense for malice. It worked well when it was novel but not anymore. I now require logging in directly with agetty. (Seriously though, a compromised user can compromise root if you use su on it). – forest Jan 23 '18 at 02:44
22

Just seen this, a bit late, but...

No - a simple web server can be administerd by root and still be basically secure.

It is true that there are some benefits to admining as non-root, but these are minor and vastly overstated by most security advice. It's much more important to secure your network facing services. Keep the web server patched and check for application-layer flaws in your web app.

To respond to tylerl's points:

  • traceability - this might be valid if you had multiple admins, but if it's just you, then you are fully traceable working as root.

  • privilege separation - I expect in practice you would do so little as non-root that this makes no difference.

  • file editing - See above

  • attack mitigation - If you have malware on your workstation, all bets are off. If you use password-less sudo, the attack he mentions still works. If you use su then the malware can get your password using a keylogger.

  • automated attack mitigation - If you follow standard advice of using strong passwords (or use SSH keys instead) then a brute forcer won't get in anyway.

paj28
  • 32,736
  • 8
  • 92
  • 130
0

The best reason to use a non-root user for daily activities is to build good habits and knowledge for such a time as you are doing something for-real on a *nix system. Without it you will never have to give a thought to file access permissions, groups, etc.

I would add that another related question is whether root should have a password of its own. It is good practice to get into the habit of supplying the root password to use sudo. A good reminder that what you are doing affects the integrity of the OS configuration. Even system administrators like knowing that not just any random user can tank the whole system with a sudo rm -R / command. *nix will just do it without saying another word back to you.

It also comes down to culture. If you are just playing around to see what it looks like in there, that's one thing - do it in a virtualbox and abuse it to your heart's content. (I particularly like doing the rm -R / thing and then watching with htop to see what stops working when. But that gets old quickly once you know that it always leads to one of two results: Restore from a backup or reinstall.)

If you ever have a business purpose for using a *nix machine, I submit that it is good to fit into the culture of others who are using that same system, even if you are the administrator.

SDsolar
  • 977
  • 1
  • 6
  • 25
-1

Using root privileges throughout your system is similar to leaving your house keys near the window, even though it's shut.

If you have experience breaking through web applications (or any other entry points) using weaknesses, then you will understand that defense-in-depth is very important. Why? Because applications always have vulnerabilities, they just haven't been discovered yet (and some are discovered every year).

Every internet exposed port, application, protocol can possibly be hacked into. Subsequently you gain access to non-internet-facing devices, software, servers, networks etc.

So in the window analogy above, if the hacker figures out to jiggle and open the window, now he just reaches in and finds all the keys to your house, even your safe. Otherwise he might just grope about and grab some small items and run off - but he now "owns the entire house", thanks to you.

So tighten down ports, privileges, passwords, permissions. I agree it can be a hassle, and at the very least you should have a security (and hacker) oriented mindset as an admin so that you can judge for yourself how valuable the contents of the server are and how thoroughly you want to lock your server down.

a20
  • 198
  • 7
  • 1
    I don't think the OP is suggesting that all services be run as root, but asking about creating a non-root admin account that will only end up sudo'ing constantly (mentions `chown'ing` to www-data, etc.) – schroeder Dec 17 '16 at 08:38