Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
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.
You can see what elevated privileges they are granted using "sudo -l"
As to settin what they can and can't do that is (mostly) done in /etc/sudoers
However, it is necessary to revisit the approach that you are trying:
It is a mistake to try to blacklist commands. A mischeivious or malevolent user could always make a local copy of a forbidden command but give the copy a new name and run sudo to elevate privileges on that new name. Thus blacklisting does not and cannot work in sudo. I'm not sure even why the syntax allows it. What you do need to set up is a whitelist in /etc/sudoers of the programs you actually do want to let them have access to.
About the file system privileges, those are something else, but easier. Consider mode 751 or 701 for /home or also even some home directories.
Can you go into a little more detail about what you want to allow and what you want to block?
With the config provided, they don't even need to go to the trouble of copying a command. The blacklist allows shell access, so a simple 'sudo -i' will allow the user to do anything they want, including every one of the blacklisted commands.
Blacklists can be useful for setting up exceptions for a whitelist, but they don't work in trying to implement a "everything except ..." scenario. For example, with a whitelist/blacklist, you could allow a user to reset user passwords, but not change the root password, or manage services except the network.
For example, with a whitelist/blacklist, you could allow a user to reset user passwords, but not change the root password, or manage services except the network.
Ah, yes. I should be more specific. Blacklisting of users or groups can work but blacklisting commands cannot ever work.
It is fascinating that even as things change, and everything gets easier, there hasn't been a tool that can effectively list out permissions and allow one to choose what a "sudo" user can and can't do.
I believe you see it like that because you are wanting to you sudo for something other then what it is intended for. as one already pointed out Access Control Lists (ACL) was developed for restricting control, where sudo was developed for giving control.
out of the gate:
ACL says you can do this and this and this, but not this.
whereas sudo says you can do everything.
It has been quite a learning experience for me a I have never encountered a situation such as the one I'm trying to address.
While there are tools like Jumpcloud, Userify (which is what we have been using for a while) and others that makes managing SSH access easier for remote teams, they either don't have the ability to assign permission levels on a group of systems to a group of users or planning to release in the future to make group management easier.
It would have been easier with one or two boxes, but these are 100s of servers with multiple accounts being created each day.
For now, I have decided not to proceed with the "sudo" access until I figure out the best way to get this accomplished.
Again, thank you so much for each and every contribution.
If you want to exclude commands from certain users, think that you can put exclamation mark in front of command, but never used it personally. Something like this:
Code:
%halfadmin ALL = !/bin/rpm, !/usr/bin/up2date, !/usr/bin/yum
where halfadmin is name of group for those you want to have restricted use of sudo.
The problem with that is that you ALSO have eliminate any commands that may grant access... such /bin/sh. /bin/vi, /bin/awk, ....
Vi can start a shell... or any command directly. So "sudo vi" permits bypassing any restrictions. As does any shell. You can even do python or perl...
Ahh, yes, thought that you've said that you will not be able to use vi with those restrictions. Yes, those restrictions can be bypassed in several ways, if group/user is granted full privileges and then restricted in something, like this:
Code:
%halfadmin ALL = ALL, !/bin/ls
As someone said, sudoers file is better suited for allowing someone to do something which requires root privileges, than to restrict someone.
However, for editors it is nearly always inappropriate to allow them to run privileged. Instead use sudoedit which is the same as sudo with the -e option. That runs the editor unprivileged but makes a copy of the file to be edited by the unprivileged account. When the editor exits, then the file edited by the unpriviledged account is copied over the original file. That way you avoid running the editor with privileges.
If you want to exclude commands from certain users, think that you can put exclamation mark in front of command, but never used it personally. Something like this:
Code:
%halfadmin ALL = !/bin/rpm, !/usr/bin/up2date, !/usr/bin/yum
where halfadmin is name of group for those you want to have restricted use of sudo.
I'd strongly advise against using sudo exclusions. There are numerous (not to mention obvious) well known pitfalls in this unreliable method. Stick to traditional white-listing.
This was a presentation by Michael W Lucas (the author or "sudo Mastery):
However, for editors it is nearly always inappropriate to allow them to run privileged. Instead use sudoedit which is the same as sudo with the -e option. That runs the editor unprivileged but makes a copy of the file to be edited by the unprivileged account. When the editor exits, then the file edited by the unpriviledged account is copied over the original file. That way you avoid running the editor with privileges.
NOEXEC is a bit of help - it only works via a preload library. That library can still be bypassed.
Granted, it takes more effort.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
