Security, et al

For compliance and protecting root access on UNIX and Linux you can’t live without sudo. I’ve written and done several webinars recently on how to implement sudo so that

• no one ever logs on with root
• you can implement least privilege instead making everyone all powerful
• enforce accountability over privileged users with a high integrity audit trail of every command executed

But most folks have more than one system to manage. It might be simple to start off using sudo by maintaining a different sudoers file on each system. As you setup sudo on each system you just copy and paste portions of sudoers from another system already set up. But that is a bad pitfall you do well to stay out of. Usually the differences in sudo policy between each system are important but subtle; most of your sudoers policy can be re-used across systems. Creating independent but substantially similar sudoers files leads to management headaches and security risks because files inevitably become out-of-date and inconsistent as roles, users and security needs change.

Thankfully sudo is designed to support multiple systems. For instance you can use the Host_Alias directive to define groups of systems and then assign the same rule(s), once, to all appropriate systems via the Host_Alias.

That’s how sudo supports multiple systems within the sudoers file but how do you get all your systems to share the same sudoers file? One way is maintaining the file on system and using a variety of file copy utilities to physically copy sudoers to each system. But sudo also supports storing your sudoers policy in your LDAP directory. http://www.sudo.ws/sudo/man/sudoers.ldap.html. This isn’t as simple as it sounds because it does involve schema changes which many admins fear.

In my next webinar with BeyondTrust I’ll explore how to manage sudo on multiple systems. Please tune in.