how to restrict users not to login to root by using sudo -i and sudo su - and other if exists [duplicate]
Clash Royale CLAN TAG#URR8PPP
up vote
3
down vote
favorite
This question already has an answer here:
Preventing other users from viewing my files [closed]
3 answers
I have tried to restrict user by editing sudoers file M ALL=!/bin/su. I am able to restrict sudo su - but not sudo -i.
sudo su not-root-user account-restrictions
edited Jan 23 at 11:49
roaima
39.7k545108
asked Jan 23 at 11:03
mmk_ind
161
marked as duplicate by sourcejedi, Jeff Schaller, Rui F Ribeiro, jayhendren, G-Man Jan 24 at 1:01
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
 |Â
show 1 more comment
up vote
3
down vote
favorite
This question already has an answer here:
Preventing other users from viewing my files [closed]
3 answers
I have tried to restrict user by editing sudoers file M ALL=!/bin/su. I am able to restrict sudo su - but not sudo -i.
sudo su not-root-user account-restrictions
edited Jan 23 at 11:49
roaima
39.7k545108
asked Jan 23 at 11:03
mmk_ind
161
marked as duplicate by sourcejedi, Jeff Schaller, Rui F Ribeiro, jayhendren, G-Man Jan 24 at 1:01
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
2
A few problems with this approach are mentioned here: unix.stackexchange.com/questions/392483/…
– Guy
Jan 23 at 11:27
If you're trying to ensure a user can't get a root shell, you need to check that every command you allow users to run viasudodoesn't have a way to create a shell. For example, most editors have a shell escape to allow a user to run a shell. You also need to make sure any command you do allow users to run viasudodoesn't have any holes such as using environment variables controlled by the user.
– Andrew Henle
Jan 23 at 11:32
I want to allow him in all other activities where as he has to run scripts but not to login as root.
– mmk_ind
Jan 23 at 11:51
3
A seasoned user will know how to get around those limitations easily. They are mere annoyances. I would refine better the security model defining wether certain users need or not to have root access.
– Rui F Ribeiro
Jan 23 at 11:53
Trivial to get aroundALL=!/bin/su. See:sudo su ## Permission deniedbut thenln -s /bin/su /tmp/ouch; sudo /tmp/ouch ## Succeeds
– roaima
Jan 23 at 12:02
 |Â
show 1 more comment
up vote
3
down vote
favorite
up vote
3
down vote
favorite
This question already has an answer here:
Preventing other users from viewing my files [closed]
3 answers
I have tried to restrict user by editing sudoers file M ALL=!/bin/su. I am able to restrict sudo su - but not sudo -i.
sudo su not-root-user account-restrictions
edited Jan 23 at 11:49
roaima
39.7k545108
asked Jan 23 at 11:03
mmk_ind
161
This question already has an answer here:
Preventing other users from viewing my files [closed]
3 answers
I have tried to restrict user by editing sudoers file M ALL=!/bin/su. I am able to restrict sudo su - but not sudo -i.
This question already has an answer here:
Preventing other users from viewing my files [closed]
3 answers
sudo su not-root-user account-restrictions
edited Jan 23 at 11:49
roaima
39.7k545108
asked Jan 23 at 11:03
mmk_ind
161
edited Jan 23 at 11:49
roaima
39.7k545108
edited Jan 23 at 11:49
roaima
39.7k545108
edited Jan 23 at 11:49
roaima
39.7k545108
39.7k545108
asked Jan 23 at 11:03
mmk_ind
161
asked Jan 23 at 11:03
mmk_ind
161
asked Jan 23 at 11:03
mmk_ind
161
161
marked as duplicate by sourcejedi, Jeff Schaller, Rui F Ribeiro, jayhendren, G-Man Jan 24 at 1:01
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by sourcejedi, Jeff Schaller, Rui F Ribeiro, jayhendren, G-Man Jan 24 at 1:01
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
2
A few problems with this approach are mentioned here: unix.stackexchange.com/questions/392483/…
– Guy
Jan 23 at 11:27
If you're trying to ensure a user can't get a root shell, you need to check that every command you allow users to run viasudodoesn't have a way to create a shell. For example, most editors have a shell escape to allow a user to run a shell. You also need to make sure any command you do allow users to run viasudodoesn't have any holes such as using environment variables controlled by the user.
– Andrew Henle
Jan 23 at 11:32
I want to allow him in all other activities where as he has to run scripts but not to login as root.
– mmk_ind
Jan 23 at 11:51
3
A seasoned user will know how to get around those limitations easily. They are mere annoyances. I would refine better the security model defining wether certain users need or not to have root access.
– Rui F Ribeiro
Jan 23 at 11:53
Trivial to get aroundALL=!/bin/su. See:sudo su ## Permission deniedbut thenln -s /bin/su /tmp/ouch; sudo /tmp/ouch ## Succeeds
– roaima
Jan 23 at 12:02
 |Â
show 1 more comment
2
A few problems with this approach are mentioned here: unix.stackexchange.com/questions/392483/…
– Guy
Jan 23 at 11:27
If you're trying to ensure a user can't get a root shell, you need to check that every command you allow users to run viasudodoesn't have a way to create a shell. For example, most editors have a shell escape to allow a user to run a shell. You also need to make sure any command you do allow users to run viasudodoesn't have any holes such as using environment variables controlled by the user.
– Andrew Henle
Jan 23 at 11:32
I want to allow him in all other activities where as he has to run scripts but not to login as root.
– mmk_ind
Jan 23 at 11:51
3
A seasoned user will know how to get around those limitations easily. They are mere annoyances. I would refine better the security model defining wether certain users need or not to have root access.
– Rui F Ribeiro
Jan 23 at 11:53
Trivial to get aroundALL=!/bin/su. See:sudo su ## Permission deniedbut thenln -s /bin/su /tmp/ouch; sudo /tmp/ouch ## Succeeds
– roaima
Jan 23 at 12:02
2
2
A few problems with this approach are mentioned here: unix.stackexchange.com/questions/392483/…
– Guy
Jan 23 at 11:27
A few problems with this approach are mentioned here: unix.stackexchange.com/questions/392483/…
– Guy
Jan 23 at 11:27
If you're trying to ensure a user can't get a root shell, you need to check that every command you allow users to run via
sudo doesn't have a way to create a shell. For example, most editors have a shell escape to allow a user to run a shell. You also need to make sure any command you do allow users to run via sudo doesn't have any holes such as using environment variables controlled by the user.– Andrew Henle
Jan 23 at 11:32
If you're trying to ensure a user can't get a root shell, you need to check that every command you allow users to run via
sudo doesn't have a way to create a shell. For example, most editors have a shell escape to allow a user to run a shell. You also need to make sure any command you do allow users to run via sudo doesn't have any holes such as using environment variables controlled by the user.– Andrew Henle
Jan 23 at 11:32
I want to allow him in all other activities where as he has to run scripts but not to login as root.
– mmk_ind
Jan 23 at 11:51
I want to allow him in all other activities where as he has to run scripts but not to login as root.
– mmk_ind
Jan 23 at 11:51
3
3
A seasoned user will know how to get around those limitations easily. They are mere annoyances. I would refine better the security model defining wether certain users need or not to have root access.
– Rui F Ribeiro
Jan 23 at 11:53
A seasoned user will know how to get around those limitations easily. They are mere annoyances. I would refine better the security model defining wether certain users need or not to have root access.
– Rui F Ribeiro
Jan 23 at 11:53
Trivial to get around
ALL=!/bin/su. See: sudo su ## Permission denied but then ln -s /bin/su /tmp/ouch; sudo /tmp/ouch ## Succeeds– roaima
Jan 23 at 12:02
Trivial to get around
ALL=!/bin/su. See: sudo su ## Permission denied but then ln -s /bin/su /tmp/ouch; sudo /tmp/ouch ## Succeeds– roaima
Jan 23 at 12:02
 |Â
show 1 more comment
1 Answer
1
active
oldest
votes
up vote
1
down vote
For your original question, you will need to exclude /bin/bash (or whatever is defined as the user's shell in /etc/passwd), like so:
tomk ALL= ALL,!/bin/su,!/bin/bash
However(!!!), as stated already in the comments to your question, even though this will deny the user from running sudo -s or sudo -i, it will not really prevent him/her from getting an interactive shell as root.
From man sudoers:
Limitations of the ‘!’ operator
It is generally not effective to “subtract†commands from ALL using the ‘!’ operator. A user can trivially circumvent this by copying the desired command to a different name and then executing that.
For example:bill ALL = ALL, !SU, !SHELLS
Doesn't really prevent bill from running the commands listed in SU or SHELLS since he can simply copy those commands to a different name, or use a shell escape from an editor or other program. Thereâ€Â
fore, these kind of restrictions should be considered advisory at best (and reinforced by policy).
In general, if a user has sudo ALL there is nothing to prevent them from creating their own program that gives them a root shell (or making their own copy of a shell) regardless of any ‘!’ elements in
the user specification.
answered Jan 23 at 13:11
Tom Klino
375316
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
For your original question, you will need to exclude /bin/bash (or whatever is defined as the user's shell in /etc/passwd), like so:
tomk ALL= ALL,!/bin/su,!/bin/bash
However(!!!), as stated already in the comments to your question, even though this will deny the user from running sudo -s or sudo -i, it will not really prevent him/her from getting an interactive shell as root.
From man sudoers:
Limitations of the ‘!’ operator
It is generally not effective to “subtract†commands from ALL using the ‘!’ operator. A user can trivially circumvent this by copying the desired command to a different name and then executing that.
For example:bill ALL = ALL, !SU, !SHELLS
Doesn't really prevent bill from running the commands listed in SU or SHELLS since he can simply copy those commands to a different name, or use a shell escape from an editor or other program. Thereâ€Â
fore, these kind of restrictions should be considered advisory at best (and reinforced by policy).
In general, if a user has sudo ALL there is nothing to prevent them from creating their own program that gives them a root shell (or making their own copy of a shell) regardless of any ‘!’ elements in
the user specification.
answered Jan 23 at 13:11
Tom Klino
375316
add a comment |Â
up vote
1
down vote
For your original question, you will need to exclude /bin/bash (or whatever is defined as the user's shell in /etc/passwd), like so:
tomk ALL= ALL,!/bin/su,!/bin/bash
However(!!!), as stated already in the comments to your question, even though this will deny the user from running sudo -s or sudo -i, it will not really prevent him/her from getting an interactive shell as root.
From man sudoers:
Limitations of the ‘!’ operator
It is generally not effective to “subtract†commands from ALL using the ‘!’ operator. A user can trivially circumvent this by copying the desired command to a different name and then executing that.
For example:bill ALL = ALL, !SU, !SHELLS
Doesn't really prevent bill from running the commands listed in SU or SHELLS since he can simply copy those commands to a different name, or use a shell escape from an editor or other program. Thereâ€Â
fore, these kind of restrictions should be considered advisory at best (and reinforced by policy).
In general, if a user has sudo ALL there is nothing to prevent them from creating their own program that gives them a root shell (or making their own copy of a shell) regardless of any ‘!’ elements in
the user specification.
answered Jan 23 at 13:11
Tom Klino
375316
add a comment |Â
up vote
1
down vote
up vote
1
down vote
For your original question, you will need to exclude /bin/bash (or whatever is defined as the user's shell in /etc/passwd), like so:
tomk ALL= ALL,!/bin/su,!/bin/bash
However(!!!), as stated already in the comments to your question, even though this will deny the user from running sudo -s or sudo -i, it will not really prevent him/her from getting an interactive shell as root.
From man sudoers:
Limitations of the ‘!’ operator
It is generally not effective to “subtract†commands from ALL using the ‘!’ operator. A user can trivially circumvent this by copying the desired command to a different name and then executing that.
For example:bill ALL = ALL, !SU, !SHELLS
Doesn't really prevent bill from running the commands listed in SU or SHELLS since he can simply copy those commands to a different name, or use a shell escape from an editor or other program. Thereâ€Â
fore, these kind of restrictions should be considered advisory at best (and reinforced by policy).
In general, if a user has sudo ALL there is nothing to prevent them from creating their own program that gives them a root shell (or making their own copy of a shell) regardless of any ‘!’ elements in
the user specification.
answered Jan 23 at 13:11
Tom Klino
375316
For your original question, you will need to exclude /bin/bash (or whatever is defined as the user's shell in /etc/passwd), like so:
tomk ALL= ALL,!/bin/su,!/bin/bash
However(!!!), as stated already in the comments to your question, even though this will deny the user from running sudo -s or sudo -i, it will not really prevent him/her from getting an interactive shell as root.
From man sudoers:
Limitations of the ‘!’ operator
It is generally not effective to “subtract†commands from ALL using the ‘!’ operator. A user can trivially circumvent this by copying the desired command to a different name and then executing that.
For example:bill ALL = ALL, !SU, !SHELLS
Doesn't really prevent bill from running the commands listed in SU or SHELLS since he can simply copy those commands to a different name, or use a shell escape from an editor or other program. Thereâ€Â
fore, these kind of restrictions should be considered advisory at best (and reinforced by policy).
In general, if a user has sudo ALL there is nothing to prevent them from creating their own program that gives them a root shell (or making their own copy of a shell) regardless of any ‘!’ elements in
the user specification.
answered Jan 23 at 13:11
Tom Klino
375316
answered Jan 23 at 13:11
Tom Klino
375316
answered Jan 23 at 13:11
Tom Klino
375316
answered Jan 23 at 13:11
Tom Klino
375316
375316
add a comment |Â
add a comment |Â
2
A few problems with this approach are mentioned here: unix.stackexchange.com/questions/392483/…
– Guy
Jan 23 at 11:27
If you're trying to ensure a user can't get a root shell, you need to check that every command you allow users to run via
sudodoesn't have a way to create a shell. For example, most editors have a shell escape to allow a user to run a shell. You also need to make sure any command you do allow users to run viasudodoesn't have any holes such as using environment variables controlled by the user.– Andrew Henle
Jan 23 at 11:32
I want to allow him in all other activities where as he has to run scripts but not to login as root.
– mmk_ind
Jan 23 at 11:51
3
A seasoned user will know how to get around those limitations easily. They are mere annoyances. I would refine better the security model defining wether certain users need or not to have root access.
– Rui F Ribeiro
Jan 23 at 11:53
Trivial to get around
ALL=!/bin/su. See:sudo su ## Permission deniedbut thenln -s /bin/su /tmp/ouch; sudo /tmp/ouch ## Succeeds– roaima
Jan 23 at 12:02