deny sudo -s/ sudo -i command in linux with /etc/sudoers
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
There is no practical way to do blacklisting with sudo. You would not only have to block "sudo -i" and all shells, but also any command that has a shell escape (like just about all editors), as well as any command that might invoke a command that has a shell escape. It's so insecure that sudo has no support for it.
The sudo philosophy
===================
Sudo is a program designed to allow a sysadmin to give limited root privileges
to users and log root activity. The basic philosophy is to give as few
privileges as possible but still allow people to get their work done.
Last edited by r3sistance; 02-14-2017 at 01:41 PM.
sudo is coming from su + do, (so the command su existed and was used to develop sudo which has additional features - not only su, but do something immediately).
And now we can check man su:
Code:
su - run a command with substitute user and group ID
in short - if you want - set user, but it was never SuperUser: su already accepted a username.
but actually this discussion is out of scope here, so we need to open a new thread about the history of sudo if you wish.
sudo is coming from su + do, (so the command su existed and was used to develop sudo which has additional features - not only su, but do something immediately).
And now we can check man su:
Code:
su - run a command with substitute user and group ID
in short - if you want - set user, but it was never SuperUser: su already accepted a username.
but actually this discussion is out of scope here, so we need to open a new thread about the history of sudo if you wish.
true it is off-topic now, I'd say the name of SU changed, Old unix code apparently shows it was called super-user. https://pthree.org/2009/12/31/the-meaning-of-su/ tho this is referring to the 5th edition and su does appear likely to have come from the 1st edition. So perhaps it even meant something different before then?
Still sometimes it is worth a discussion on the history of things, it helps us understand how things evolved and in terms of security that is always good, I think. More so this thread is rife with some old sudo abuse from the 1st post... some real abuse of it. I think we can both agree that it is best to limit down and then explicity allow rather than explicity deny in the context of sudo!
It looks like no use of su - can now be used by a username I suppose rules applied one can change it to a group name too.
Code:
# Allow guestx user to remote poweroff
guestx ALL=(ALL) !ALL
guestx ALL=NOPASSWD: /sbin/poweroff
Translation: disallow all commands, then allow only the desired command (without asking for password in this case).
With this configuration sudo asks for the password and then fails for commands other than the whitelisted one:
guestx@ds:~$ sudo su -
Password:
Sorry, user guestx is not allowed to execute '/bin/su -' as root on ds.
guestx@ds:~$
I have not tried it to see if this also apples to the sudo -s/ sudo -i commands
I'd look into this further per sudo man page
Code:
Set to the login name of the target user when the -i
option is specified, when the set_logname option is
enabled in sudoers or when the env_reset option is
enabled in sudoers (unless LOGNAME is present in the
env_keep list).
i figure out a solution and it is a little complicated , thought , it helps me to prohibit restricted user to execute "sudo -i / sudo -s /sudo su "to promote as root right.
of course , it still has bugs and user can escape from the auditing, but once user escape our security setting, like :
ln -s /bin/su ~/rootme
sudo ~/rootme
our accounting system will start to work , all user's operation will be record and audit, so that we can locate the responsibility of the risk operations.
not really. for example: they edit crontab to execute xterm as root on a specific display and they will have root access without audit. but obviously this is not a good example.
not really. for example: they edit crontab to execute xterm as root on a specific display and they will have root access without audit. but obviously this is not a good example.
yes, but , once root has operations, accounting system will record , and we will know
as my habit , i used to execute sudo iptables -nvL --line-number , not all users like to use -nvL, and --line-number, may be i just use sudo iptables -L to list all rule in filter table .
Cmnd_Alias should have a way to express all circumstance with element -nvL --line-number , in that way, i can define a expression to match all possibles
There is no practical way to do blacklisting with sudo. You would not only have to block "sudo -i" and all shells, but also any command that has a shell escape (like just about all editors), as well as any command that might invoke a command that has a shell escape. It's so insecure that sudo has no support for it.
forgive me if I am tossing in a wrench, but does not one need at lease one shell for the CLI. sh or something? therefore block every other shell but sh.
so forget about how to formulate the !sudo -i something like this untested bit
Code:
GROUP or user ALL = !/usr/bin/bash, !/bin/bash, !/bin/dash, !/bin/whatevershell
to block the user or group from being able to use any of the other shells. therefore, one should only be able to use sh (or whatever shell is provided) but when they try to change shells it is now blocked by the Not ! and path leading to the executable for the other shell(s).
but I maybe getting the term shell mixed up as one can invoke another shell within a shell, within a shell and again and again like in a bash script. would that be the same in what is being spoke of in here relating to gaining or getting into "different" shell, which makes no sense to my brain at this moment.
sh to bash to dash to whatever else all within the same terminal emulator makes sense to my brain though. which that should block ..
Once you start any shell, that shell can do anything it could normally do, including running any other program or shell. And, if you block all shells, all the user needs to do is run "sudo vi", and from within vi type ":shell". Presto -- a root shell appears! The same can be done from many other programs that have shell escapes. You would need to discover and block them all, and blocking all editors (for example) would probably not be acceptable. If you've allowed sudo access to the cp command, it's easy to copy /bin/bash to another name and invoke that. You are trying to make a sieve leakproof, and there is just no way to make this one hold water.
$ sudo bash
[sudo] password for BW-userx:
Sorry, user BW-userx is not allowed to execute '/bin/bash' as root on server.lan.
$ cp /bin/bash /tmp/woot
$ sudo /tmp/woot
[sudo] password for BW-userx:
# whoami
root
#
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
