Sudo: Setting Up Intelligent Security Policies Part Two

In Part One we went over the basics of sudo, what it is, why we use it, and how it is used properly.  In this article we are going to take it a step further and look at specific use cases for sudo.  The key thing to remember though, is that you have two ways you can use sudo, 1) to allow for program execution as root, a white-list  2) to restrict program execution as root, a black-list.  If you are doing the later there is no definitive way to restrict a program execution, so you should only use the latter with administrators who are trusted completely (the same users who would have access to the root password).

Allow A Specific Command Execution as Root (The Real Sudo)

This first policy example is what sudo is for.  This is where you want individuals to perform a specific action as root (for example restart a service which is known to be flaky instead of calling you at 2AM).  These commands can be specific down to parameters and everything.  Of course once the sudo policy is in place you could even go a step further and create aliases in their user profile so that they can execute simpler commands.  For example “/etc/init.d/network restart” can be aliased to “internet-reboot” or something equally simple/ridiculous.

# cat /etc/sudoers
# Specific Command Execution
Defaults logfile=/var/log/sudo.log
User_Alias ROOTCOMMAND = user1, user2
Cmnd_Alias REBOOT = /sbin/reboot
Cmnd_Alias SERVICE = /etc/init.d/network restart

One other small thing I did in this example.  Since this has a VERY restrictive policy and we are only allowing to possible commands to be run I have removed the password requirement. I do not allow this on a wider policy.  This comes back to the saying:

Quick, Easy, Secure – pick two.

Allow Root Access with Some Disallowances

This policy is a much safer policy for individuals who are not fully trusted, for example Junior Sys Admins.  This policy closes most of the holes which would allow them to inadvertently or intentionally lock out other individuals from the machine, the key difference between this and the above policy is that it requires all commands be executed via sudo, instead of being able to spawn a shell as root, and bypass the logging.

# cat /etc/sudoers
# Root with Restrictions
Defaults logfile=/var/log/sudo.log
User_Alias ROOTRESTRICTED = user1, user2
Cmnd_Alias SHELLS = /bin/sh, /bin/bash, /bin/ash, /bin/bsh, /bin/tcsh, /bin/csh, /bin/ksh, /bin/ksh93
Cmnd_Alias SU = /bin/su, /usr/bin/vncserver
Cmnd_Alias PASSWD = /bin/passwd, /usr/sbin/useradd, /usr/sbin/userdel, /usr/sbin/usermod
Cmnd_Alias VISUDO = /usr/sbin/visudo

Allow Unrestricted Root Access

This is the basics of a policy that I use on my workstations.  This also fits very well on servers where you have a requirement to not login to the root account except in an emergency.

This policy has NO restrictions on it.  As such the only people whom you will want to grant this policy to are the same folks you would provide your root password to.  This policy also allows the direct invocation of a shell as root, which gives you a root shell, which after that nothing is logged in the sudo.log.

# cat /etc/sudoers
# Root Equivalent
Defaults logfile=/var/log/sudo.log
User_Alias ROOTEQUIVALENT = user1, user2

Switch Users Using Sudo

Here is another little tidbit I like to use on systems which require multiple system accounts to run multiple applications.  Instead of having to track and know each user and password combination (or having someone else have to do the same) I like to enable users to use sudo to invoke su to switch to the specific user.  This of course means that they will not be prompted to enter a password for the user that they are logging into but they will be logging that entry into sudo.

# cat /etc/sudoers
# Switch User Without Additional Password Management
Defaults logfile=/var/log/sudo.log
User_Alias TSTEBSUSER = bob, bill
Cmnd_Alias SUTSTEBS = /bin/su tstebs, /bin/su - tstebs
User_Alias TSTWLSUSER = bob, mark, jon
Cmnd_Alias SUTSTWLS = /bin/su tstebs, /bin/su - tstebs

Above we can see that we have two environments to be managed our TSTWLS and our TSTEBS environment.  Each of these environments is executed and managed using the tstwls and tstebs users respectively.  We can also see that according to the policy we have a user named bob with access to both environments.  The TSTEBS environment also has a user named bill who has access to the environment.  While on TSTWLS we additionally have mark, and jon who have access to the environment.

These are the most common use cases I have run into for using sudo.  There are many more policy restrictions (noexec – disallow the execution of scripts) which are detailed in the man pages for sudo.

Comments are closed.