Assigning custom sudo privileges

Assigning 'standard' sudo privileges is fairly easy and is one of the first things a sysadmin will do when creating an administration user.

But what if you want to create another administrator but not give them access to all the commands as the sudo user?

On receipt of your VPS or server, you probably entered the command:

visudo

and then entered the admin user 'paul' like this:

paul   ALL=(ALL) ALL

Well that's OK for the majority of cases but there will be occasions when you want to give a user 'limited' sudo access. Perhaps you are going on holiday and there's going to be a caretaker or perhaps you are sharing responsibility for server administration.

In any case, it is possible to assign certain sudo privileges to individual users or groups.

Let's take a look at two such entries in the /etc/sudoers file (that's the file that's changed via the visudo command):

pete        ALL=(root) /bin/mkdir, /bin/rmdir
%temps  ALL=(root) /bin/cat

Dealing with the first line, we can see that the user 'pete' has been selected.

The first 'ALL' is related to the host on which this rule is used. 'ALL' is seen as a wild card and is usually fine left at that.

The 'root' in the brackets signals what user 'pete' can execute a command as. Again. if it was 'ALL' then it would be seen as a wild card and pete could have executed the commands as any user.

The final set displays what commands 'pete' can execute as root. Rather miserly in my trust of pete, I've only allowed him to make directories and remove directories. Mind you, he could reap a fair bit of damage with those commands alone!

I also have a group of users in the 'temps' group. I have indicated that 'temps' is a group by using '%' before the group name.

Again, host is a wildcard and they only have root privileges for the 'cat' command.

I am sure they are delighted they can read files previously denied to them.

There are some very practical uses for these limited commands and perhaps the most common use is the ability to administer users.

Giving another user or group sudo permissions for 'useradd' and 'userdel', etc can take an administrative burden off the sysadmin who should be concentrating on security and uptime.

You would assign these commands to the admin group like so:

%admin  ALL=(root) /usr/sbin/useradd, /usr/sbin/userdel

Sudo without a password

This next trick can be a blessing and a massive security hole.

This is having the ability to issue root commands, via sudo, and not giving a password.

Is this madness I hear you cry? Well, frankly yes, but it's up to you if want to provide this feature.

To do so, the syntax is the same as before but we add a NOPASSWD: before the commands:

madjohn  ALL=(root) NOPASSWD: /bin/rm

There we are, madjohn (our resident oddball) has root privileges with the rm command and he doesn't even have to give a password to use it.

Apart from the slightly daft examples I have given here, there are some real and practical uses for 'limited' sudo access. Obviously think hard before allowing the NOPASSWD to be given but sharing server responsibilities can ease workload.

Final note on security

We've talked about the NOPASSWD: option and it's obvious dangers, but do ensure that when you give these limited privileges you give the full path the executable.

If you gave this setting:

pete        ALL=(root) mkdir

You are say that 'pete' can execute the command 'mkdir' as the 'root' user but you are not specifying where the mkdir command is located.

He could create a very nasty script, call it 'mkdir', place it in his local bin and you have gone ahead and given him root powers to run it.

If you specify the full path of each command (as I have in each example) this risk is minimised.

PickledOnion.

Digg it | del.icio.us | reddit | StumbleUpon