In the Implementing Effective Access Control webinar that I did a few days ago, I spent a little time talking about sudo. It’s a pretty cool utility that, I think, is vastly underutilized. With some care, sudo can be the basis for a powerful role-based access control (RBAC) system on Linux.
Sudo is a Linux/UNIX/Mac OS X utility that reduces the need to run as root. Rather than logging in with the root account in order to access priviliged commands and restricted files, you log in with your personal (non-administrative) account and then invoke the sudo program whenever you want to perform an operation that requires root priviliges.
For example, to restart the network, instead of logging in as root and running:
/etc/init.d/network restart
You would log in with your personal account and run:
sudo /etc/init.d/network restart
The sudo command runs the privileged command for you after first consulting its configuration file, /etc/sudoers, to verify that you’re allowed to run the command.
In addition to minimizing the need to share the root password, sudo is also valuable because it performs logging. The command above would result in a log entry being written that identified who (your personal account) performed what operation (the network restart).
While we find that our customers are familiar with sudo, we find that many of them don’t use it. The problem with sudo is that, to use it, you need to carefully design a correspoding /etc/sudoer configuration file. Clearly, you don’t want everyone to be able to perform every privileged operation. You want to design a set of roles, for example:
- System administrator
- Database administrator
- Storage administrator
- Developer
- Help desk assistant
- End user
- …
And then you want to determine what privileged commands will be available to each of these roles. Finally, you need to assign roles to your users.
Adding individual users to /etc/sudoer can be painful. If new employees are being hired and fired frequently, it’s inconvenient to have to push out new versions of this file to all the machines in your network. Although /etc/sudoer allows the referencing of user groups instead individual users, without a centralized authentication system, identifying groups in sudo is no more convenient that identifying individual users. Each time an employee is hired or fired, you’ll need to push out a new /etc/groups file to all of your systems.
This is where our software comes us. Likewise allows Linux/UNIX/Mac OS X machines to authenticate users with the Active Directory credentials. We allow these non-Windows machines to be joined to AD and to perform Kerberos/LDAP based authentication against AD without any local account.
With Likewise, adding/removing employees from AD groups is all done at the central LDAP repository; no file needs to be updated on each participating Linux/UNIX/Mac OS X machine. Additionally, Likewise extends the Microsoft group policy architecture to these non-Windows systems and provides a GP setting for sudo. We can use group policy to distribute sudo configuration files automatically.
The combination of Likewise software and sudo makes it much, much, easier to eliminate the use of privileged accounts by relying on sudo as controlled by AD group memberships.
Strangely enough, there’s no equivalent functionality in Windows. The closest thing to sudo is the ability to runas another user (impersonation). At the shell level, you can right click on an application icon and invoke the Run As… menu item. You can then specify the credentials for an administrator and run an application to which you might not normally have access. With this technique, however, you still need to know the credentials for an administrative account.
At least one third-party implementation of sudo for Windows has been written (this one).