Purpose of creating non root user [closed]












5















I have been told it is common practice to create a new user with sudo privileges and disable the root user. What risks does this mitigate?










share|improve this question















closed as too broad by Pilot6, Emmet, Kulfy, Melebius, Eric Carvalho Mar 20 at 22:57


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.



















  • Possible duplicate of Why is it bad to log in as root?

    – wjandrea
    Mar 20 at 23:02











  • @wjandrea Isn't the questions fundamentally different?

    – Jonas Grønbek
    Mar 20 at 23:03











  • In what way? Aren't they both asking "Why shouldn't I log in as root?"

    – wjandrea
    Mar 20 at 23:06











  • @No, I do not think so. Neither are the answers the same, I believe the question has a lot of relevance for people confused over this specifically.

    – Jonas Grønbek
    Mar 20 at 23:11
















5















I have been told it is common practice to create a new user with sudo privileges and disable the root user. What risks does this mitigate?










share|improve this question















closed as too broad by Pilot6, Emmet, Kulfy, Melebius, Eric Carvalho Mar 20 at 22:57


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.



















  • Possible duplicate of Why is it bad to log in as root?

    – wjandrea
    Mar 20 at 23:02











  • @wjandrea Isn't the questions fundamentally different?

    – Jonas Grønbek
    Mar 20 at 23:03











  • In what way? Aren't they both asking "Why shouldn't I log in as root?"

    – wjandrea
    Mar 20 at 23:06











  • @No, I do not think so. Neither are the answers the same, I believe the question has a lot of relevance for people confused over this specifically.

    – Jonas Grønbek
    Mar 20 at 23:11














5












5








5


6






I have been told it is common practice to create a new user with sudo privileges and disable the root user. What risks does this mitigate?










share|improve this question
















I have been told it is common practice to create a new user with sudo privileges and disable the root user. What risks does this mitigate?







permissions sudo root






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 20 at 23:07









wjandrea

9,45042664




9,45042664










asked Mar 20 at 10:18









Jonas GrønbekJonas Grønbek

1487




1487




closed as too broad by Pilot6, Emmet, Kulfy, Melebius, Eric Carvalho Mar 20 at 22:57


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.









closed as too broad by Pilot6, Emmet, Kulfy, Melebius, Eric Carvalho Mar 20 at 22:57


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.















  • Possible duplicate of Why is it bad to log in as root?

    – wjandrea
    Mar 20 at 23:02











  • @wjandrea Isn't the questions fundamentally different?

    – Jonas Grønbek
    Mar 20 at 23:03











  • In what way? Aren't they both asking "Why shouldn't I log in as root?"

    – wjandrea
    Mar 20 at 23:06











  • @No, I do not think so. Neither are the answers the same, I believe the question has a lot of relevance for people confused over this specifically.

    – Jonas Grønbek
    Mar 20 at 23:11



















  • Possible duplicate of Why is it bad to log in as root?

    – wjandrea
    Mar 20 at 23:02











  • @wjandrea Isn't the questions fundamentally different?

    – Jonas Grønbek
    Mar 20 at 23:03











  • In what way? Aren't they both asking "Why shouldn't I log in as root?"

    – wjandrea
    Mar 20 at 23:06











  • @No, I do not think so. Neither are the answers the same, I believe the question has a lot of relevance for people confused over this specifically.

    – Jonas Grønbek
    Mar 20 at 23:11

















Possible duplicate of Why is it bad to log in as root?

– wjandrea
Mar 20 at 23:02





Possible duplicate of Why is it bad to log in as root?

– wjandrea
Mar 20 at 23:02













@wjandrea Isn't the questions fundamentally different?

– Jonas Grønbek
Mar 20 at 23:03





@wjandrea Isn't the questions fundamentally different?

– Jonas Grønbek
Mar 20 at 23:03













In what way? Aren't they both asking "Why shouldn't I log in as root?"

– wjandrea
Mar 20 at 23:06





In what way? Aren't they both asking "Why shouldn't I log in as root?"

– wjandrea
Mar 20 at 23:06













@No, I do not think so. Neither are the answers the same, I believe the question has a lot of relevance for people confused over this specifically.

– Jonas Grønbek
Mar 20 at 23:11





@No, I do not think so. Neither are the answers the same, I believe the question has a lot of relevance for people confused over this specifically.

– Jonas Grønbek
Mar 20 at 23:11










4 Answers
4






active

oldest

votes


















13














One security advantage of disabling root and creating a non root user who is able of using sudo is protecting your server against brute force attacks which are trying to guess your "root" password.



As Rinzwind stated that, which one do you think is more secure?




  • Root account + Hard to guess password

  • A custom username + Hard to guess password


The other and more important advantage is that when you have only one root user, everything you are running is being run with the power of "root" which has access to do everything so running a wrong command or making a simple mistake has the potential of destroying your server.



Simply by creating a non root user:




  • You aren't giving out your root password!

  • You are able to define who can do what!

  • You can audit who did what!

  • You are minimizing the possibility of running a wrong or dangerous command with root access.


And also remember that if somebody has physical access to the server, He or she is able to do almost whatever he/she wants to the server unless everything is encrypted on that server.






share|improve this answer





















  • 1





    If you can elaborate even more on the part where you explain about the security advantage of creating a non root, so I can mark as answer. :) Is it because root have more privileges than a sudo user?

    – Jonas Grønbek
    Mar 20 at 11:49






  • 3





    +1, but I'd like to add that a successful brute force attack on username and password of a sudoer account has the same effect as bruteforcing root's password, so the fact that the username is not known is no security advantage. In fact, relying on the username as part of the "password" can decrease security if an attacker is able to retrieve a list of usernames. Instead of choosing a hard-to-guess username, it's more secure to append it to the password and name the user "abc".

    – danzel
    Mar 20 at 13:25






  • 1





    @Ravexina there then :D

    – Rinzwind
    Mar 20 at 13:30






  • 3





    Everyone who has used Linux for long enough has had a time when they accidentally entered a command that, had they been root at the time, would have completely destroyed their system. My most recent was wanting to remove all the contents of my current directory and accidentally typing rm -rf . /* instead of rm -rf ./*.

    – David Schwartz
    Mar 20 at 14:02








  • 2





    Devil's advocate: On a server you shouldn't have passwords, just SSH keys... And with things like fail2ban brute force attacks will take ages So this leaves the safety of being protected against accidents by lack of privs, but many things you do require root privs (those that don't have been scripted...) so you still have plenty of occasions for mishaps. Backups, backups, and backups. And be ready to recreate the server from the ground up if it is compromised.

    – xenoid
    Mar 20 at 19:24





















3














In addition to the valid concerns mentioned in @Ravexina's answer, I think it's important to note:



SSHing into your server isn't the only way a malicious actor could perform actions



In fact, a successful brute-force attack on SSH is probably the least likely way a hacker would get into your server. SSH sleeps for 3 seconds when an invalid password is entered, so brute forcing a strong remote SSH password is practically impossible.*



What's more likely is they could find a remote code execution vulnerability and "get in" that way. If when they do, you want them to have as little permission as possible. You really don't want them to be root.



See, when you run a program, like Apache, PHP, or a PHP/Python/NodeJS script, or even your web browser: that "process" also must run as a user. For example: If you run a PHP script as root, then that PHP process can do anything root can do.



So let's say, for example, a malicious actor is able to carry out a "remote code execution" attack: they are able to run code on your server. If PHP runs that malicious code, and PHP is running as root, that means the hacker's code also runs as root. But if PHP is running as a less privileged user (ie: webapp), you significantly mitigate the amount of damage it can do. This applies when you run console scripts too, and not just to PHP: Every language can have this issue.



The tricky thing here is: the RCE vulnerability might not even be code you wrote: it could be buried deep in some 3rd party library/module that your code calls to: calculate dates, interact with a database, render HTML, etc... In other words: You might not even know it's there. And it might get silently added to your codebase when you update your dependencies/libraries. As we saw in the EventStream hack, it can be trivially easy to gain control of an upstream library repository, and use it to push malicious code to unsuspecting apps downstream. If that malicious code runs as root, it can take control of your entire server, and even cover its tracks to where you never know it happened.



So while having separate users for everything may not prevent an attack entirely, it will significantly mitigate damage that could come from a remote code execution attack if it does happen.



* Obviously if your password is abc123 this does not apply, because that's probably one of the first ones hackers will try when brute-forcing.






share|improve this answer


























  • Very nice addition! I myself might need a little more abstraction before grasping how a RCE works completely. It sparks a question: What decides which user a web-application is run with?

    – Jonas Grønbek
    Mar 20 at 20:21






  • 1





    Understanding "what decides which user a web-application is run with" is a huge subject that probably should be its own SE question. With Apache, you set the desired user/group in a configuration file. At launch, the main daemon process (running as root) spawns new child processes as whatever user you tell it in the configuration file. There are also other permissions models for Apache. more info.

    – Eric Seastrand
    Mar 21 at 12:47



















1














This actually depends on what you do on your server. In addition to the answer by @Ravexina (guess password attack): Do you e.g.




  • access some websites

  • read mail

  • view some pictures

  • read PDFs


All of these have been attack vectors in the past (browsers on a regular basis). If someone has used one of these vectors, he could




  • (non-root) access and remove all of your files, install software for the local user, etc

  • (root) do everything


While non-root exploits can be escalated (see https://superuser.com/questions/301646/linux-keylogger-without-root-or-sudo-is-it-real), this offers an additional layer of protection. It also protects against accidents as mentioned by @David Schwartz:




Everyone who has used Linux for long enough has had a time when they accidentally entered a command that, had they been root at the time, would have completely destroyed their system. My most recent was wanting to remove all the contents of my current directory and accidentally typing rm -rf . /* instead of rm -rf ./*.







share|improve this answer































    1














    I think the security advantage of creating a non root user is vastly overestimated. Still it costs you basically nothing and it does not create any security problems. So I would recommend that you do it.



    https://xkcd.com/1200/



    But don't neglect to secure what is really important.






    share|improve this answer
























    • That xkcd comic captures exactly what I have been thinking for a while now myself.

      – Sebastian
      Mar 20 at 20:52


















    4 Answers
    4






    active

    oldest

    votes








    4 Answers
    4






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    13














    One security advantage of disabling root and creating a non root user who is able of using sudo is protecting your server against brute force attacks which are trying to guess your "root" password.



    As Rinzwind stated that, which one do you think is more secure?




    • Root account + Hard to guess password

    • A custom username + Hard to guess password


    The other and more important advantage is that when you have only one root user, everything you are running is being run with the power of "root" which has access to do everything so running a wrong command or making a simple mistake has the potential of destroying your server.



    Simply by creating a non root user:




    • You aren't giving out your root password!

    • You are able to define who can do what!

    • You can audit who did what!

    • You are minimizing the possibility of running a wrong or dangerous command with root access.


    And also remember that if somebody has physical access to the server, He or she is able to do almost whatever he/she wants to the server unless everything is encrypted on that server.






    share|improve this answer





















    • 1





      If you can elaborate even more on the part where you explain about the security advantage of creating a non root, so I can mark as answer. :) Is it because root have more privileges than a sudo user?

      – Jonas Grønbek
      Mar 20 at 11:49






    • 3





      +1, but I'd like to add that a successful brute force attack on username and password of a sudoer account has the same effect as bruteforcing root's password, so the fact that the username is not known is no security advantage. In fact, relying on the username as part of the "password" can decrease security if an attacker is able to retrieve a list of usernames. Instead of choosing a hard-to-guess username, it's more secure to append it to the password and name the user "abc".

      – danzel
      Mar 20 at 13:25






    • 1





      @Ravexina there then :D

      – Rinzwind
      Mar 20 at 13:30






    • 3





      Everyone who has used Linux for long enough has had a time when they accidentally entered a command that, had they been root at the time, would have completely destroyed their system. My most recent was wanting to remove all the contents of my current directory and accidentally typing rm -rf . /* instead of rm -rf ./*.

      – David Schwartz
      Mar 20 at 14:02








    • 2





      Devil's advocate: On a server you shouldn't have passwords, just SSH keys... And with things like fail2ban brute force attacks will take ages So this leaves the safety of being protected against accidents by lack of privs, but many things you do require root privs (those that don't have been scripted...) so you still have plenty of occasions for mishaps. Backups, backups, and backups. And be ready to recreate the server from the ground up if it is compromised.

      – xenoid
      Mar 20 at 19:24


















    13














    One security advantage of disabling root and creating a non root user who is able of using sudo is protecting your server against brute force attacks which are trying to guess your "root" password.



    As Rinzwind stated that, which one do you think is more secure?




    • Root account + Hard to guess password

    • A custom username + Hard to guess password


    The other and more important advantage is that when you have only one root user, everything you are running is being run with the power of "root" which has access to do everything so running a wrong command or making a simple mistake has the potential of destroying your server.



    Simply by creating a non root user:




    • You aren't giving out your root password!

    • You are able to define who can do what!

    • You can audit who did what!

    • You are minimizing the possibility of running a wrong or dangerous command with root access.


    And also remember that if somebody has physical access to the server, He or she is able to do almost whatever he/she wants to the server unless everything is encrypted on that server.






    share|improve this answer





















    • 1





      If you can elaborate even more on the part where you explain about the security advantage of creating a non root, so I can mark as answer. :) Is it because root have more privileges than a sudo user?

      – Jonas Grønbek
      Mar 20 at 11:49






    • 3





      +1, but I'd like to add that a successful brute force attack on username and password of a sudoer account has the same effect as bruteforcing root's password, so the fact that the username is not known is no security advantage. In fact, relying on the username as part of the "password" can decrease security if an attacker is able to retrieve a list of usernames. Instead of choosing a hard-to-guess username, it's more secure to append it to the password and name the user "abc".

      – danzel
      Mar 20 at 13:25






    • 1





      @Ravexina there then :D

      – Rinzwind
      Mar 20 at 13:30






    • 3





      Everyone who has used Linux for long enough has had a time when they accidentally entered a command that, had they been root at the time, would have completely destroyed their system. My most recent was wanting to remove all the contents of my current directory and accidentally typing rm -rf . /* instead of rm -rf ./*.

      – David Schwartz
      Mar 20 at 14:02








    • 2





      Devil's advocate: On a server you shouldn't have passwords, just SSH keys... And with things like fail2ban brute force attacks will take ages So this leaves the safety of being protected against accidents by lack of privs, but many things you do require root privs (those that don't have been scripted...) so you still have plenty of occasions for mishaps. Backups, backups, and backups. And be ready to recreate the server from the ground up if it is compromised.

      – xenoid
      Mar 20 at 19:24
















    13












    13








    13







    One security advantage of disabling root and creating a non root user who is able of using sudo is protecting your server against brute force attacks which are trying to guess your "root" password.



    As Rinzwind stated that, which one do you think is more secure?




    • Root account + Hard to guess password

    • A custom username + Hard to guess password


    The other and more important advantage is that when you have only one root user, everything you are running is being run with the power of "root" which has access to do everything so running a wrong command or making a simple mistake has the potential of destroying your server.



    Simply by creating a non root user:




    • You aren't giving out your root password!

    • You are able to define who can do what!

    • You can audit who did what!

    • You are minimizing the possibility of running a wrong or dangerous command with root access.


    And also remember that if somebody has physical access to the server, He or she is able to do almost whatever he/she wants to the server unless everything is encrypted on that server.






    share|improve this answer















    One security advantage of disabling root and creating a non root user who is able of using sudo is protecting your server against brute force attacks which are trying to guess your "root" password.



    As Rinzwind stated that, which one do you think is more secure?




    • Root account + Hard to guess password

    • A custom username + Hard to guess password


    The other and more important advantage is that when you have only one root user, everything you are running is being run with the power of "root" which has access to do everything so running a wrong command or making a simple mistake has the potential of destroying your server.



    Simply by creating a non root user:




    • You aren't giving out your root password!

    • You are able to define who can do what!

    • You can audit who did what!

    • You are minimizing the possibility of running a wrong or dangerous command with root access.


    And also remember that if somebody has physical access to the server, He or she is able to do almost whatever he/she wants to the server unless everything is encrypted on that server.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Mar 20 at 19:11

























    answered Mar 20 at 10:38









    RavexinaRavexina

    33.2k1488116




    33.2k1488116








    • 1





      If you can elaborate even more on the part where you explain about the security advantage of creating a non root, so I can mark as answer. :) Is it because root have more privileges than a sudo user?

      – Jonas Grønbek
      Mar 20 at 11:49






    • 3





      +1, but I'd like to add that a successful brute force attack on username and password of a sudoer account has the same effect as bruteforcing root's password, so the fact that the username is not known is no security advantage. In fact, relying on the username as part of the "password" can decrease security if an attacker is able to retrieve a list of usernames. Instead of choosing a hard-to-guess username, it's more secure to append it to the password and name the user "abc".

      – danzel
      Mar 20 at 13:25






    • 1





      @Ravexina there then :D

      – Rinzwind
      Mar 20 at 13:30






    • 3





      Everyone who has used Linux for long enough has had a time when they accidentally entered a command that, had they been root at the time, would have completely destroyed their system. My most recent was wanting to remove all the contents of my current directory and accidentally typing rm -rf . /* instead of rm -rf ./*.

      – David Schwartz
      Mar 20 at 14:02








    • 2





      Devil's advocate: On a server you shouldn't have passwords, just SSH keys... And with things like fail2ban brute force attacks will take ages So this leaves the safety of being protected against accidents by lack of privs, but many things you do require root privs (those that don't have been scripted...) so you still have plenty of occasions for mishaps. Backups, backups, and backups. And be ready to recreate the server from the ground up if it is compromised.

      – xenoid
      Mar 20 at 19:24
















    • 1





      If you can elaborate even more on the part where you explain about the security advantage of creating a non root, so I can mark as answer. :) Is it because root have more privileges than a sudo user?

      – Jonas Grønbek
      Mar 20 at 11:49






    • 3





      +1, but I'd like to add that a successful brute force attack on username and password of a sudoer account has the same effect as bruteforcing root's password, so the fact that the username is not known is no security advantage. In fact, relying on the username as part of the "password" can decrease security if an attacker is able to retrieve a list of usernames. Instead of choosing a hard-to-guess username, it's more secure to append it to the password and name the user "abc".

      – danzel
      Mar 20 at 13:25






    • 1





      @Ravexina there then :D

      – Rinzwind
      Mar 20 at 13:30






    • 3





      Everyone who has used Linux for long enough has had a time when they accidentally entered a command that, had they been root at the time, would have completely destroyed their system. My most recent was wanting to remove all the contents of my current directory and accidentally typing rm -rf . /* instead of rm -rf ./*.

      – David Schwartz
      Mar 20 at 14:02








    • 2





      Devil's advocate: On a server you shouldn't have passwords, just SSH keys... And with things like fail2ban brute force attacks will take ages So this leaves the safety of being protected against accidents by lack of privs, but many things you do require root privs (those that don't have been scripted...) so you still have plenty of occasions for mishaps. Backups, backups, and backups. And be ready to recreate the server from the ground up if it is compromised.

      – xenoid
      Mar 20 at 19:24










    1




    1





    If you can elaborate even more on the part where you explain about the security advantage of creating a non root, so I can mark as answer. :) Is it because root have more privileges than a sudo user?

    – Jonas Grønbek
    Mar 20 at 11:49





    If you can elaborate even more on the part where you explain about the security advantage of creating a non root, so I can mark as answer. :) Is it because root have more privileges than a sudo user?

    – Jonas Grønbek
    Mar 20 at 11:49




    3




    3





    +1, but I'd like to add that a successful brute force attack on username and password of a sudoer account has the same effect as bruteforcing root's password, so the fact that the username is not known is no security advantage. In fact, relying on the username as part of the "password" can decrease security if an attacker is able to retrieve a list of usernames. Instead of choosing a hard-to-guess username, it's more secure to append it to the password and name the user "abc".

    – danzel
    Mar 20 at 13:25





    +1, but I'd like to add that a successful brute force attack on username and password of a sudoer account has the same effect as bruteforcing root's password, so the fact that the username is not known is no security advantage. In fact, relying on the username as part of the "password" can decrease security if an attacker is able to retrieve a list of usernames. Instead of choosing a hard-to-guess username, it's more secure to append it to the password and name the user "abc".

    – danzel
    Mar 20 at 13:25




    1




    1





    @Ravexina there then :D

    – Rinzwind
    Mar 20 at 13:30





    @Ravexina there then :D

    – Rinzwind
    Mar 20 at 13:30




    3




    3





    Everyone who has used Linux for long enough has had a time when they accidentally entered a command that, had they been root at the time, would have completely destroyed their system. My most recent was wanting to remove all the contents of my current directory and accidentally typing rm -rf . /* instead of rm -rf ./*.

    – David Schwartz
    Mar 20 at 14:02







    Everyone who has used Linux for long enough has had a time when they accidentally entered a command that, had they been root at the time, would have completely destroyed their system. My most recent was wanting to remove all the contents of my current directory and accidentally typing rm -rf . /* instead of rm -rf ./*.

    – David Schwartz
    Mar 20 at 14:02






    2




    2





    Devil's advocate: On a server you shouldn't have passwords, just SSH keys... And with things like fail2ban brute force attacks will take ages So this leaves the safety of being protected against accidents by lack of privs, but many things you do require root privs (those that don't have been scripted...) so you still have plenty of occasions for mishaps. Backups, backups, and backups. And be ready to recreate the server from the ground up if it is compromised.

    – xenoid
    Mar 20 at 19:24







    Devil's advocate: On a server you shouldn't have passwords, just SSH keys... And with things like fail2ban brute force attacks will take ages So this leaves the safety of being protected against accidents by lack of privs, but many things you do require root privs (those that don't have been scripted...) so you still have plenty of occasions for mishaps. Backups, backups, and backups. And be ready to recreate the server from the ground up if it is compromised.

    – xenoid
    Mar 20 at 19:24















    3














    In addition to the valid concerns mentioned in @Ravexina's answer, I think it's important to note:



    SSHing into your server isn't the only way a malicious actor could perform actions



    In fact, a successful brute-force attack on SSH is probably the least likely way a hacker would get into your server. SSH sleeps for 3 seconds when an invalid password is entered, so brute forcing a strong remote SSH password is practically impossible.*



    What's more likely is they could find a remote code execution vulnerability and "get in" that way. If when they do, you want them to have as little permission as possible. You really don't want them to be root.



    See, when you run a program, like Apache, PHP, or a PHP/Python/NodeJS script, or even your web browser: that "process" also must run as a user. For example: If you run a PHP script as root, then that PHP process can do anything root can do.



    So let's say, for example, a malicious actor is able to carry out a "remote code execution" attack: they are able to run code on your server. If PHP runs that malicious code, and PHP is running as root, that means the hacker's code also runs as root. But if PHP is running as a less privileged user (ie: webapp), you significantly mitigate the amount of damage it can do. This applies when you run console scripts too, and not just to PHP: Every language can have this issue.



    The tricky thing here is: the RCE vulnerability might not even be code you wrote: it could be buried deep in some 3rd party library/module that your code calls to: calculate dates, interact with a database, render HTML, etc... In other words: You might not even know it's there. And it might get silently added to your codebase when you update your dependencies/libraries. As we saw in the EventStream hack, it can be trivially easy to gain control of an upstream library repository, and use it to push malicious code to unsuspecting apps downstream. If that malicious code runs as root, it can take control of your entire server, and even cover its tracks to where you never know it happened.



    So while having separate users for everything may not prevent an attack entirely, it will significantly mitigate damage that could come from a remote code execution attack if it does happen.



    * Obviously if your password is abc123 this does not apply, because that's probably one of the first ones hackers will try when brute-forcing.






    share|improve this answer


























    • Very nice addition! I myself might need a little more abstraction before grasping how a RCE works completely. It sparks a question: What decides which user a web-application is run with?

      – Jonas Grønbek
      Mar 20 at 20:21






    • 1





      Understanding "what decides which user a web-application is run with" is a huge subject that probably should be its own SE question. With Apache, you set the desired user/group in a configuration file. At launch, the main daemon process (running as root) spawns new child processes as whatever user you tell it in the configuration file. There are also other permissions models for Apache. more info.

      – Eric Seastrand
      Mar 21 at 12:47
















    3














    In addition to the valid concerns mentioned in @Ravexina's answer, I think it's important to note:



    SSHing into your server isn't the only way a malicious actor could perform actions



    In fact, a successful brute-force attack on SSH is probably the least likely way a hacker would get into your server. SSH sleeps for 3 seconds when an invalid password is entered, so brute forcing a strong remote SSH password is practically impossible.*



    What's more likely is they could find a remote code execution vulnerability and "get in" that way. If when they do, you want them to have as little permission as possible. You really don't want them to be root.



    See, when you run a program, like Apache, PHP, or a PHP/Python/NodeJS script, or even your web browser: that "process" also must run as a user. For example: If you run a PHP script as root, then that PHP process can do anything root can do.



    So let's say, for example, a malicious actor is able to carry out a "remote code execution" attack: they are able to run code on your server. If PHP runs that malicious code, and PHP is running as root, that means the hacker's code also runs as root. But if PHP is running as a less privileged user (ie: webapp), you significantly mitigate the amount of damage it can do. This applies when you run console scripts too, and not just to PHP: Every language can have this issue.



    The tricky thing here is: the RCE vulnerability might not even be code you wrote: it could be buried deep in some 3rd party library/module that your code calls to: calculate dates, interact with a database, render HTML, etc... In other words: You might not even know it's there. And it might get silently added to your codebase when you update your dependencies/libraries. As we saw in the EventStream hack, it can be trivially easy to gain control of an upstream library repository, and use it to push malicious code to unsuspecting apps downstream. If that malicious code runs as root, it can take control of your entire server, and even cover its tracks to where you never know it happened.



    So while having separate users for everything may not prevent an attack entirely, it will significantly mitigate damage that could come from a remote code execution attack if it does happen.



    * Obviously if your password is abc123 this does not apply, because that's probably one of the first ones hackers will try when brute-forcing.






    share|improve this answer


























    • Very nice addition! I myself might need a little more abstraction before grasping how a RCE works completely. It sparks a question: What decides which user a web-application is run with?

      – Jonas Grønbek
      Mar 20 at 20:21






    • 1





      Understanding "what decides which user a web-application is run with" is a huge subject that probably should be its own SE question. With Apache, you set the desired user/group in a configuration file. At launch, the main daemon process (running as root) spawns new child processes as whatever user you tell it in the configuration file. There are also other permissions models for Apache. more info.

      – Eric Seastrand
      Mar 21 at 12:47














    3












    3








    3







    In addition to the valid concerns mentioned in @Ravexina's answer, I think it's important to note:



    SSHing into your server isn't the only way a malicious actor could perform actions



    In fact, a successful brute-force attack on SSH is probably the least likely way a hacker would get into your server. SSH sleeps for 3 seconds when an invalid password is entered, so brute forcing a strong remote SSH password is practically impossible.*



    What's more likely is they could find a remote code execution vulnerability and "get in" that way. If when they do, you want them to have as little permission as possible. You really don't want them to be root.



    See, when you run a program, like Apache, PHP, or a PHP/Python/NodeJS script, or even your web browser: that "process" also must run as a user. For example: If you run a PHP script as root, then that PHP process can do anything root can do.



    So let's say, for example, a malicious actor is able to carry out a "remote code execution" attack: they are able to run code on your server. If PHP runs that malicious code, and PHP is running as root, that means the hacker's code also runs as root. But if PHP is running as a less privileged user (ie: webapp), you significantly mitigate the amount of damage it can do. This applies when you run console scripts too, and not just to PHP: Every language can have this issue.



    The tricky thing here is: the RCE vulnerability might not even be code you wrote: it could be buried deep in some 3rd party library/module that your code calls to: calculate dates, interact with a database, render HTML, etc... In other words: You might not even know it's there. And it might get silently added to your codebase when you update your dependencies/libraries. As we saw in the EventStream hack, it can be trivially easy to gain control of an upstream library repository, and use it to push malicious code to unsuspecting apps downstream. If that malicious code runs as root, it can take control of your entire server, and even cover its tracks to where you never know it happened.



    So while having separate users for everything may not prevent an attack entirely, it will significantly mitigate damage that could come from a remote code execution attack if it does happen.



    * Obviously if your password is abc123 this does not apply, because that's probably one of the first ones hackers will try when brute-forcing.






    share|improve this answer















    In addition to the valid concerns mentioned in @Ravexina's answer, I think it's important to note:



    SSHing into your server isn't the only way a malicious actor could perform actions



    In fact, a successful brute-force attack on SSH is probably the least likely way a hacker would get into your server. SSH sleeps for 3 seconds when an invalid password is entered, so brute forcing a strong remote SSH password is practically impossible.*



    What's more likely is they could find a remote code execution vulnerability and "get in" that way. If when they do, you want them to have as little permission as possible. You really don't want them to be root.



    See, when you run a program, like Apache, PHP, or a PHP/Python/NodeJS script, or even your web browser: that "process" also must run as a user. For example: If you run a PHP script as root, then that PHP process can do anything root can do.



    So let's say, for example, a malicious actor is able to carry out a "remote code execution" attack: they are able to run code on your server. If PHP runs that malicious code, and PHP is running as root, that means the hacker's code also runs as root. But if PHP is running as a less privileged user (ie: webapp), you significantly mitigate the amount of damage it can do. This applies when you run console scripts too, and not just to PHP: Every language can have this issue.



    The tricky thing here is: the RCE vulnerability might not even be code you wrote: it could be buried deep in some 3rd party library/module that your code calls to: calculate dates, interact with a database, render HTML, etc... In other words: You might not even know it's there. And it might get silently added to your codebase when you update your dependencies/libraries. As we saw in the EventStream hack, it can be trivially easy to gain control of an upstream library repository, and use it to push malicious code to unsuspecting apps downstream. If that malicious code runs as root, it can take control of your entire server, and even cover its tracks to where you never know it happened.



    So while having separate users for everything may not prevent an attack entirely, it will significantly mitigate damage that could come from a remote code execution attack if it does happen.



    * Obviously if your password is abc123 this does not apply, because that's probably one of the first ones hackers will try when brute-forcing.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Mar 20 at 19:40

























    answered Mar 20 at 19:30









    Eric SeastrandEric Seastrand

    1315




    1315













    • Very nice addition! I myself might need a little more abstraction before grasping how a RCE works completely. It sparks a question: What decides which user a web-application is run with?

      – Jonas Grønbek
      Mar 20 at 20:21






    • 1





      Understanding "what decides which user a web-application is run with" is a huge subject that probably should be its own SE question. With Apache, you set the desired user/group in a configuration file. At launch, the main daemon process (running as root) spawns new child processes as whatever user you tell it in the configuration file. There are also other permissions models for Apache. more info.

      – Eric Seastrand
      Mar 21 at 12:47



















    • Very nice addition! I myself might need a little more abstraction before grasping how a RCE works completely. It sparks a question: What decides which user a web-application is run with?

      – Jonas Grønbek
      Mar 20 at 20:21






    • 1





      Understanding "what decides which user a web-application is run with" is a huge subject that probably should be its own SE question. With Apache, you set the desired user/group in a configuration file. At launch, the main daemon process (running as root) spawns new child processes as whatever user you tell it in the configuration file. There are also other permissions models for Apache. more info.

      – Eric Seastrand
      Mar 21 at 12:47

















    Very nice addition! I myself might need a little more abstraction before grasping how a RCE works completely. It sparks a question: What decides which user a web-application is run with?

    – Jonas Grønbek
    Mar 20 at 20:21





    Very nice addition! I myself might need a little more abstraction before grasping how a RCE works completely. It sparks a question: What decides which user a web-application is run with?

    – Jonas Grønbek
    Mar 20 at 20:21




    1




    1





    Understanding "what decides which user a web-application is run with" is a huge subject that probably should be its own SE question. With Apache, you set the desired user/group in a configuration file. At launch, the main daemon process (running as root) spawns new child processes as whatever user you tell it in the configuration file. There are also other permissions models for Apache. more info.

    – Eric Seastrand
    Mar 21 at 12:47





    Understanding "what decides which user a web-application is run with" is a huge subject that probably should be its own SE question. With Apache, you set the desired user/group in a configuration file. At launch, the main daemon process (running as root) spawns new child processes as whatever user you tell it in the configuration file. There are also other permissions models for Apache. more info.

    – Eric Seastrand
    Mar 21 at 12:47











    1














    This actually depends on what you do on your server. In addition to the answer by @Ravexina (guess password attack): Do you e.g.




    • access some websites

    • read mail

    • view some pictures

    • read PDFs


    All of these have been attack vectors in the past (browsers on a regular basis). If someone has used one of these vectors, he could




    • (non-root) access and remove all of your files, install software for the local user, etc

    • (root) do everything


    While non-root exploits can be escalated (see https://superuser.com/questions/301646/linux-keylogger-without-root-or-sudo-is-it-real), this offers an additional layer of protection. It also protects against accidents as mentioned by @David Schwartz:




    Everyone who has used Linux for long enough has had a time when they accidentally entered a command that, had they been root at the time, would have completely destroyed their system. My most recent was wanting to remove all the contents of my current directory and accidentally typing rm -rf . /* instead of rm -rf ./*.







    share|improve this answer




























      1














      This actually depends on what you do on your server. In addition to the answer by @Ravexina (guess password attack): Do you e.g.




      • access some websites

      • read mail

      • view some pictures

      • read PDFs


      All of these have been attack vectors in the past (browsers on a regular basis). If someone has used one of these vectors, he could




      • (non-root) access and remove all of your files, install software for the local user, etc

      • (root) do everything


      While non-root exploits can be escalated (see https://superuser.com/questions/301646/linux-keylogger-without-root-or-sudo-is-it-real), this offers an additional layer of protection. It also protects against accidents as mentioned by @David Schwartz:




      Everyone who has used Linux for long enough has had a time when they accidentally entered a command that, had they been root at the time, would have completely destroyed their system. My most recent was wanting to remove all the contents of my current directory and accidentally typing rm -rf . /* instead of rm -rf ./*.







      share|improve this answer


























        1












        1








        1







        This actually depends on what you do on your server. In addition to the answer by @Ravexina (guess password attack): Do you e.g.




        • access some websites

        • read mail

        • view some pictures

        • read PDFs


        All of these have been attack vectors in the past (browsers on a regular basis). If someone has used one of these vectors, he could




        • (non-root) access and remove all of your files, install software for the local user, etc

        • (root) do everything


        While non-root exploits can be escalated (see https://superuser.com/questions/301646/linux-keylogger-without-root-or-sudo-is-it-real), this offers an additional layer of protection. It also protects against accidents as mentioned by @David Schwartz:




        Everyone who has used Linux for long enough has had a time when they accidentally entered a command that, had they been root at the time, would have completely destroyed their system. My most recent was wanting to remove all the contents of my current directory and accidentally typing rm -rf . /* instead of rm -rf ./*.







        share|improve this answer













        This actually depends on what you do on your server. In addition to the answer by @Ravexina (guess password attack): Do you e.g.




        • access some websites

        • read mail

        • view some pictures

        • read PDFs


        All of these have been attack vectors in the past (browsers on a regular basis). If someone has used one of these vectors, he could




        • (non-root) access and remove all of your files, install software for the local user, etc

        • (root) do everything


        While non-root exploits can be escalated (see https://superuser.com/questions/301646/linux-keylogger-without-root-or-sudo-is-it-real), this offers an additional layer of protection. It also protects against accidents as mentioned by @David Schwartz:




        Everyone who has used Linux for long enough has had a time when they accidentally entered a command that, had they been root at the time, would have completely destroyed their system. My most recent was wanting to remove all the contents of my current directory and accidentally typing rm -rf . /* instead of rm -rf ./*.








        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Mar 20 at 19:23









        serv-incserv-inc

        1,6551420




        1,6551420























            1














            I think the security advantage of creating a non root user is vastly overestimated. Still it costs you basically nothing and it does not create any security problems. So I would recommend that you do it.



            https://xkcd.com/1200/



            But don't neglect to secure what is really important.






            share|improve this answer
























            • That xkcd comic captures exactly what I have been thinking for a while now myself.

              – Sebastian
              Mar 20 at 20:52
















            1














            I think the security advantage of creating a non root user is vastly overestimated. Still it costs you basically nothing and it does not create any security problems. So I would recommend that you do it.



            https://xkcd.com/1200/



            But don't neglect to secure what is really important.






            share|improve this answer
























            • That xkcd comic captures exactly what I have been thinking for a while now myself.

              – Sebastian
              Mar 20 at 20:52














            1












            1








            1







            I think the security advantage of creating a non root user is vastly overestimated. Still it costs you basically nothing and it does not create any security problems. So I would recommend that you do it.



            https://xkcd.com/1200/



            But don't neglect to secure what is really important.






            share|improve this answer













            I think the security advantage of creating a non root user is vastly overestimated. Still it costs you basically nothing and it does not create any security problems. So I would recommend that you do it.



            https://xkcd.com/1200/



            But don't neglect to secure what is really important.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Mar 20 at 20:39









            emoryemory

            1213




            1213













            • That xkcd comic captures exactly what I have been thinking for a while now myself.

              – Sebastian
              Mar 20 at 20:52



















            • That xkcd comic captures exactly what I have been thinking for a while now myself.

              – Sebastian
              Mar 20 at 20:52

















            That xkcd comic captures exactly what I have been thinking for a while now myself.

            – Sebastian
            Mar 20 at 20:52





            That xkcd comic captures exactly what I have been thinking for a while now myself.

            – Sebastian
            Mar 20 at 20:52



            Popular posts from this blog

            "Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

            Alcedinidae

            Origin of the phrase “under your belt”?