SUDO Restriction

nippon · 06-19-2017, 07:34 PM

Guys,

I need your help.

I'm aware that you should not grant "sudo" privileges to anyone you don't trust wholly.

I'm aware that once a user has a "sudo" access, everything is a game.

But is it realistically possible to create a group or sudo user with limited server functions such as:

deny access to /etc/passwd
deny access to useradd/adduser
deny access to /etc/ssh/sshd_config
deny access to visudo
deny access to yum & rpm install
deny access to history -c
deny access from accessing "root" home.

Box are CentOS/RHEL 7.

Thank you!

business_kid · 06-20-2017, 09:35 AM

You can provide limits in /etc/sudoers which you edit with visudo. Have a go, test it, and if you get stuck post again.

EDIT: The key is getting the word "ALL" out of the config.

dejank · 06-20-2017, 10:12 AM

Quote:

deny access to /etc/passwd

Nope, cause read access to passwd is needed by several things. So, do not touch it. As for others, it is easier to allow certain commands than to exclude just few commands. So, ask yourself, what commands you want to allow to non privileged users. Then create command alias in sudoers, or even better some file under /etc/sudoers.d/ for that commands. Something like this:

Code:

Cmnd_Alias      POWER = /sbin/shutdown, /sbin/halt, /sbin/reboot, /sbin/restart
POWERPUFF ALL = POWER

then create that powerpuff group, and add users you want to be able to execute those commands in powerpuff group. For nice tutorial, go here: https://www.digitalocean.com/communi...ntu-and-centos

nippon · 06-20-2017, 06:04 PM

Thank you so much for the guidance.

I'm grateful.

I just don't want this user to have access to these:

/bin/rpm, /usr/bin/up2date, /usr/bin/yum, /sbin/service, /sbin/chkconfig, /usr/bin/systemctl start, /usr/bin/systemctl stop, /usr/bin/systemctl reload, /usr/bin/systemctl restart, /usr/bin/systemctl enable, /usr/bin/systemctl disable, /usr/bin/updatedb, /sbin/fdisk, /sbin/sfdisk, /sbin/parted, /sbin/partprobe, /bin/mount, /bin/umount, /usr/sbin/visudo, /bin/chown, /bin/chmod, /bin/chgrp

BW-userx · 06-20-2017, 06:57 PM

Quote:

Originally Posted by nippon

Thank you so much for the guidance.

I'm grateful.

I just don't want this user to have access to these:

/bin/rpm, /usr/bin/up2date, /usr/bin/yum, /sbin/service, /sbin/chkconfig, /usr/bin/systemctl start, /usr/bin/systemctl stop, /usr/bin/systemctl reload, /usr/bin/systemctl restart, /usr/bin/systemctl enable, /usr/bin/systemctl disable, /usr/bin/updatedb, /sbin/fdisk, /sbin/sfdisk, /sbin/parted, /sbin/partprobe, /bin/mount, /bin/umount, /usr/sbin/visudo, /bin/chown, /bin/chmod, /bin/chgrp

then you'd just exclude them from the above scenario given by dejank

just out of curiosity what is left that sudo can do?

dejank · 06-20-2017, 07:01 PM

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.

nippon · 06-20-2017, 07:58 PM

Guys, you have bee great and more than helpful than I could expect.

Thank you so much.

Here is what I have done so far:

After adding halfadmin:

Code:

uid=1003(halfadmin) gid=1006(halfadmin) groups=1006(halfadmin),1007(systemadmins)

Code:

halfadmin ALL=(systemadmins) ALL

Code:

%systemadmins ALL = !/bin/rpm, !/usr/bin/up2date, !/usr/bin/yum, /sbin/service, !/usr/bin/updatedb, !/sbin/fdisk, !/sbin/sfdisk, !/sbin/parted, !/sbin/partprobe, !/bin/mount, !/bin/umount, !/usr/sbin/visudo, !/bin/chown, !/bin/chmod, !/bin/chgrp

Code:

sudo systemctl status sshd

I also used:

Code:

systemadmins ALL = !/bin/rpm, !/usr/bin/up2date, !/usr/bin/yum, !/sbin/service, !/sbin/chkconfig, !/usr/bin/systemctl start, !/usr/bin/systemctl stop, !/usr/bin/systemctl enable, !/usr/bin/systemctl disable, !/usr/bin/updatedb, !/sbin/fdisk, !/sbin/sfdisk, !/sbin/parted, !/sbin/partprobe, !/bin/mount, !/bin/umount, !/usr/sbin/visudo, !/bin/chown, !/bin/chmod, !/bin/chgrp

Result for each scenario:

Sorry, user halfadmin is not allowed to execute '/bin/systemctl status sshd' as root on lab.server.com.

nippon · 06-20-2017, 08:11 PM

Quote:

Originally Posted by BW-userx

then you'd just exclude them from the above scenario given by dejank

just out of curiosity what is left that sudo can do?

I thought this a lot.

The only thing I want this account to do is to access all other user's home but not mine nor root.

I also don't want to allow access to visudo of any kind of installation.

I'm not even sure if this is possible but would be sufficient.

AwesomeMachine · 06-20-2017, 08:30 PM

Then you have to make your home inaccessible to other users. /home/user is allowed access to other /home/users by default. Sudoers is only for commands, not permissions on files and directories. So, you'd have to remove read permissions for the users group.

BW-userx · 06-20-2017, 08:42 PM

Quote:

Originally Posted by nippon

I thought this a lot.

The only thing I want this account to do is to access all other user's home but not mine nor root.

I also don't want to allow access to visudo of any kind of installation.

I'm not even sure if this is possible but would be sufficient.

along with what @AwesomeMachine said in how to do this, what is it you are actually using this "person" for? what would be his duties and responsibilities? whence you figure this out if you need more help to see if this can be done. Then come back and share it with us in here for help and guidance.

just for someone else to be able to peek inside of someone else's home dir ?

Code:

userx%slackwhere ⚡ ~ ⚡> sudo adduser deleteme
Login name for new user: deleteme
User ID ('UID') [ defaults to next available ]: 
Initial group [ users ]: 
Additional UNIX groups:
Users can belong to additional UNIX groups on the system.
For local users using graphical desktop login managers such
as XDM/KDM, users may need to be members of additional groups
to access the full functionality of removable media devices.
* Security implications *
Please be aware that by adding users to additional groups may
potentially give access to the removable media of other users.
If you are creating a new user for remote shell access only,
users do not need to belong to any additional groups as standard,
so you may press ENTER at the next prompt.
Press ENTER to continue without adding any additional groups
Or press the UP arrow key to add/select/edit additional groups
:  
Home directory [ /home/deleteme ] 
Shell [ /bin/bash ] 
Expiry date (YYYY-MM-DD) []: 
New account will be created as follows:
---------------------------------------
Login name.......:  deleteme
UID..............:  [ Next available ]
Initial group....:  users
Additional groups:  [ None ]
Home directory...:  /home/deleteme
Shell............:  /bin/bash
Expiry date......:  [ Never ]
This is it... if you want to bail out, hit Control-C.  Otherwise, press
ENTER to go ahead and make the account.
Creating new account...
Changing the user information for deleteme
Enter the new value, or press ENTER for the default
        Full Name []: 
        Room Number []: 
        Work Phone []: 
        Home Phone []: 
        Other []: 
Changing password for deleteme
Enter the new password (minimum of 5 characters)
Please use a combination of upper and lower case letters and numbers.
New password: 
Bad password: too short.  
Warning: weak password (enter it again to use it anyway).
New password: 
Re-enter new password: 
passwd: password changed.


Account setup complete.
userx%slackwhere ⚡ ~ ⚡> 
userx%slackwhere ⚡ ~ ⚡> cd /home
userx%slackwhere ⚡ home ⚡> ls
deleteme  ftp  lost+found  userx  userx-bk
userx%slackwhere ⚡ home ⚡> cd deleteme
userx%slackwhere ⚡ deleteme ⚡> ls
ls: cannot open directory '.': Permission denied
userx%slackwhere ⚡ deleteme ⚡> su  
Password: 
bash-4.3# ls
bash-4.3# pwd
/home/deleteme
bash-4.3#

nippon · 06-20-2017, 08:50 PM

Quote:

Originally Posted by BW-userx

along with what @AwesomeMachine said in how to do this, what is it you are actually using this "person" for? what would be his duties and responsibilities? whence you figure this out if you need more help to see if this can be done. Then come back and share it with us in here for help and guidance.

I should have laid this out from the beginning.

We have a remote support team.
Their only task is to help customers with issues.
Each customers has his own home dir.
The team must have access access to these dir. in order to resolve the issues but with nothing else than that.

They have access to a GUI that shows them the server status and all information they need to know when something is working or not.
If it is not working, we will know and they can put in request for that to be resolved.

That's about it.

Thank you!

rknichols · 06-20-2017, 09:27 PM

Quote:

Originally Posted by nippon

We have a remote support team.
Their only task is to help customers with issues.
Each customers has his own home dir.
The team must have access access to these dir. in order to resolve the issues but with nothing else than that.

That task is probably best handled by ACLs. If you tried to accomplish that by restricting what commands can be run via sudo, you would have to block, in addition to the specific commands you listed above, any command that has a shell escape (e.g., most editors) and any other command that can exec() arbitrary commands ("find" comes immediately to mind, and even the fairly benign "less" can launch other commands).

nippon · 06-20-2017, 09:39 PM

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.

Turbocapitalist · 06-20-2017, 10:53 PM

Quote:

Originally Posted by nippon

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.

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?

dejank · 06-21-2017, 02:15 AM

Quote:

Originally Posted by nippon

Guys, you have bee great and more than helpful than I could expect.

Thank you so much.

Here is what I have done so far:

After adding halfadmin:

Code:

uid=1003(halfadmin) gid=1006(halfadmin) groups=1006(halfadmin),1007(systemadmins)

Code:

halfadmin ALL=(systemadmins) ALL

Code:

%systemadmins ALL = !/bin/rpm, !/usr/bin/up2date, !/usr/bin/yum, /sbin/service, !/usr/bin/updatedb, !/sbin/fdisk, !/sbin/sfdisk, !/sbin/parted, !/sbin/partprobe, !/bin/mount, !/bin/umount, !/usr/sbin/visudo, !/bin/chown, !/bin/chmod, !/bin/chgrp

Code:

sudo systemctl status sshd

I also used:

Code:

systemadmins ALL = !/bin/rpm, !/usr/bin/up2date, !/usr/bin/yum, !/sbin/service, !/sbin/chkconfig, !/usr/bin/systemctl start, !/usr/bin/systemctl stop, !/usr/bin/systemctl enable, !/usr/bin/systemctl disable, !/usr/bin/updatedb, !/sbin/fdisk, !/sbin/sfdisk, !/sbin/parted, !/sbin/partprobe, !/bin/mount, !/bin/umount, !/usr/sbin/visudo, !/bin/chown, !/bin/chmod, !/bin/chgrp

Result for each scenario:

Sorry, user halfadmin is not allowed to execute '/bin/systemctl status sshd' as root on lab.server.com.

You should do man sudoers :P Later inputs take precedence over former inputs. So what you did was to allow full sudo privileges to halfadmin and then you've said that you've changed your mind and that you actually just want to prevent them from commands on list. Considering amount of commands you want to restricted, better approach would be to just allow them what you want them to do. As someone mentioned, ACLs and file permissions are better way to do what you want.