Loading ...
Linux Tips: The proper way to allow regular users to run commands as root
There are many situations when you will need regular users to have more privileges than the normal user account they have. What situations? This will depend very much on a case by case basis but believe me there will be such cases… For example if a regular user needs to run a program that will change some some protected folder or file, or just a special root command (like shutdown for example).
What can be done in such situations? Well this depends: if you can go around it by assigning proper file/folder permission then this is great. But if not:
- you can give them the root password and place them in the group allowed to ’su’ and you are done. I never liked this option as it will allow them to do anything on the system, and this is not what we were trying to achieve.
- you can use a program like sudo, to fine tune the proper commands that you will allow the user to run. This is more likely what I would do in this situation…
So the magical solution to this problem is sudo (superuser do), a program that allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root or another user. And all the commands will be logged for your reference.
The installation, in case you don’t already have sudo on the system, is very simple, but in case you want it you can check out some simple details about installing sudo on Debian, or Rhel, Fedora, Centos, and some details about the configuration files location and default state.
Basically what we need is to: define the commands, define the users and assign what commands are allowed to each user defined. Everything is pretty straitforth and well documented in the manual page, but here is a simple example to see it better: let say that we want a regular user called ‘webadmin‘ to run as root a shell script that will call rsync for backup purposes.
Let’s define the user alias (not really needed but on more complex configurations can be very useful). In the user alias section we put:
# User alias specification
User_Alias WEBADMIN = webadminNow let’s define the commands this user will be allowed to run. In the command alias section we enter:
# Cmnd alias specification
Cmnd_Alias CMD_SYNC = /usr/bin/rsyncAnd the last thing is to assign to the user alias created the command allowed:
# User privilege specification
WEBADMIN ALL = NOPASSWD: CMD_SYNCSince I have entered the parameter NOPASSWD this will not ask the user for any password while running the command. If this is not used the user will be required to enter its regular password (not very useful). The configuration file for this example looks like this:
# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
# Host alias specification
# User alias specification
User_Alias WEBADMIN = webadmin
# Cmnd alias specification
Cmnd_Alias CMD_SYNC = /usr/bin/rsync
# User privilege specification
root ALL=(ALL) ALL
WEBADMIN ALL = NOPASSWD: CMD_SYNCNow each time the user ‘webadmin‘ will launch the rsync command with sudo it will be running it with root privileges:
sudo rsync --delete -va --exclude=upload/* /www/livesite/ /backup/wwwThis can have many usages based on the needs: like, you can allow an unprivileged user to be able to reboot the system if needed (shutdown) or update the system (apt, up2date, yum), etc. I just wanted to show you what you can do with this program and a simple example of usage.
Are you already using sudo on your servers to allow normal users to run some commands as root? Let me know what have you achieved with it and I will include it here as more examples of usage.
Tags: Security, shell, sudo, Tools
Share This
23rd May 2006, 06:50
in reference to the paragraph:
“So the magical solution to this problem is sudo (superuser do), a program that allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root or another user. And all the commands will be logged for your reference.”
If you give the sudoer access to a shell, such as bash, then the sudo logging is bypassed and you have only the bash history, not a reliable log. Or if you allow the sudoer to have “root” access to an editor like vi, then the sudoer can run about anything they want without logging simply by editing a script (such as a init.d script) that runs as root and adding any malicious code they want. If you want to rely on sudo’s logging, it is best to have a better understanding of the limitations of sudo’s limitations and ways to defeat it than it seems the author does.
23rd May 2006, 06:52
Hi
Wouldn’t it be better to make an script which calls rsync with the correct parameters and make what script sudo:able by som users.
Allowing rsync is like allowing cp. So it wouldn’t be to hard to replace /etc/group with a prepared one there someone unwanted was in group 0. After that can they run any command without sudo
Other than this a good article introducing sudo
23rd May 2006, 08:04
Rsync isn’t exactly the best choice here. A user can easily rsync over some important file to gain full root access this way.
23rd May 2006, 09:47
Thanks Johan and Mario for your comments. You are right and ‘rsync’ may not be the best way to exemplify the usage of sudo, but at the time I wrote this, I was out of ideas… Actually the way I have this in real life is calling a script that runs rsync with the proper parameters and have the user call that script, but for the sake of the example I thought that this would not look so clear and used rsync…
To plugh… Of course that this will depend on the commands you are allowing the users to run. If you are concerned about the logging then there are other ways to log the commands like snoopylogger for example.
As I said at the time I wrote this, please feel free to share with others how are you using sudo if you already rely on it.
23rd May 2006, 16:01
In reply to”
“To plugh… Of course that this will depend on the commands you are allowing the users to run. If you are concerned about the logging then there are other ways to log the commands like snoopylogger for example.”
Please re-read the paragraph I quoted. You claimed “the ability to run some (or all) commands”…”And all the commands will be logged for your reference.” As I pointed out, this is simply not true. If you give access to “(or all) commands” as you state, the logging can be defeated. The fact that you can run ANOTHER program like “snoop” to make up for this hole in sudo does not mean that that sudo’s logging can’t be defeated. You can use commands like snoop to monitor su as well as sudo.
I would not advise anyone to use sudo based on the claim that it logs all commands when you allows the user access to all commands. It simply is NOT TRUE. If you understood sudo and wanted to give out ACCURATE information to your readers, you would have pointed out this vulnerability to your readers and you would not try to make imply that “snoop” some how means that this vulnerability does not exist in sudo.
23rd May 2006, 17:26
Dear plugh,
You are correct. I have not understood your point initially, but you are correct, if you allow the user to run all the commands as root, then obviously logging can be disabled by a user that intends to do that. Thanks for pointing that out, and sorry if I have not understood you in the first place.
Of course that from the security point of view the administrator must be very careful on what commands he enables for his users to run as root.
24th May 2006, 09:25
A better example of sudo use might be cdrecord.
31st May 2006, 06:49
One could try to combine rsync and chroot to circumvent the security impact of filesystem wide rsync access while running it as root-sudoer.
just my 2cent
polarizer
21st March 2007, 18:53
[...] I could edit /etc/sudoers (the guide at MDLog:/sysadmin gives a good introduction to sudo) but I don’t know what security holes I might open in the process. One workaround is to enable the root account and use ssh root@localhost but enabling root access is really an unnecessary step. Instead, I prefer to use su - adminaccountname, after which I can sudo the appropriate command(s) and exit to return to a standard shell. [...]
21st March 2007, 22:55
[...] I could edit /etc/sudoers (the guide at MDLog:/sysadmin gives a good introduction to sudo) but I don’t know what security holes I might open in the process. One workaround is to enable the root account and use ssh root@localhost but enabling root access is really an unnecessary step. Instead, I prefer to use su - adminaccountname, after which I can sudo the appropriate command(s) and exit to return to a standard shell. [...]
9th June 2007, 03:16
ya i think linux is so lovely operating system and so interested for work. This site make help for many people who interested in linux operating system and work it. this site give so many documentation about linux command and script for use and gain your knowlege yourself…………