Purpose of creating non root user [closed]
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
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.
add a comment |
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
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
add a comment |
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
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
permissions sudo root
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
add a comment |
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
add a comment |
4 Answers
4
active
oldest
votes
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.
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 beenroot
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 typingrm -rf . /*
instead ofrm -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 likefail2ban
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
add a comment |
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.
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
add a comment |
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 ofrm -rf ./*.
add a comment |
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.
That xkcd comic captures exactly what I have been thinking for a while now myself.
– Sebastian
Mar 20 at 20:52
add a comment |
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
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 beenroot
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 typingrm -rf . /*
instead ofrm -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 likefail2ban
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
add a comment |
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.
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 beenroot
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 typingrm -rf . /*
instead ofrm -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 likefail2ban
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
add a comment |
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.
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.
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 beenroot
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 typingrm -rf . /*
instead ofrm -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 likefail2ban
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
add a comment |
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 beenroot
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 typingrm -rf . /*
instead ofrm -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 likefail2ban
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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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 ofrm -rf ./*.
add a comment |
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 ofrm -rf ./*.
add a comment |
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 ofrm -rf ./*.
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 ofrm -rf ./*.
answered Mar 20 at 19:23
serv-incserv-inc
1,6551420
1,6551420
add a comment |
add a comment |
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.
That xkcd comic captures exactly what I have been thinking for a while now myself.
– Sebastian
Mar 20 at 20:52
add a comment |
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.
That xkcd comic captures exactly what I have been thinking for a while now myself.
– Sebastian
Mar 20 at 20:52
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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