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.

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.

share|improve this question
    
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 3:28
    
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
    

2 Answers 2

up vote 29 down vote accepted

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.

share|improve this answer
    
Good points, but that last one can be (somewhat) mitigated by not allowing password-based logins. –  Terry Chia Dec 24 '13 at 3:27
5  
@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 3: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 3:30
    
Defeating traceability is as easy as sudo bash and shopt -u -o history. –  ntrrgc May 21 at 9:48

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.

share|improve this answer

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.