The inner design of Linux and UNIX does not contemplate the idea of least privilege between admin users nor even accountability. When it comes to administering the OS, you are root or nothing and you are all root no matter how many different admins there are.
Enter: sudo.
Sudo is awesome for implementing least privilege over the monolithic “root or nothing” model of Linux and UNIX on a single system. When you sudo it right no one logs on as root and you get fine-grained control over exactly which commands each user can run and even which arguments the user can use with each command.
But let's face it, sudo is a foundation technology for controller privileged actions on a given system. Sudo supports the idea of controlling policy on multiple systems but it doesn't manage or facilitate managing least privilege policies on multiple systems. What's the difference? Well, you can design your sudoers file so that the same file is valid against many different systems. You just specify a Host_List in your rules (aka User_Spec) and those rules are applied to the specified hosts. So for rules that apply to all hosts you simply omit Host_List specified from the rule. And include Host_List to allow other commands for a subset of specific hosts.
In this real training for free ™ webinar I'll review how sudo works and then dive into how you craft a single sudoers file to rule them all. And sudo is great at that.
But how do you deploy that sudoers file to each system? And what about version control and change management? Sudo does not address that. Your options are:
- Leverage an existing systems management solution like Chef or Puppet
- Store sudoers in an ldap directory (not!)
- Put some scripts together
- Get a product that leverages the extensibility of sudo
I'll show you some examples of scripts that either push or pull your central sudoers file to each system and discuss the pros and cons.
But once you centralize your sudoers policy file you next need to think about centralized logging. Even with sudo you don’t achieve accountability or fulfill compliance requirements unless you have a high-integrity audit trail of what was done via sudo. And the problem is that by default sudo writes out both logs to local storage. Sudo writes out a log each command users try to run through sudo to syslog so that is relatively easy to centralize. But sudo also produces IO logs which is basically a full fidelity security camera recording of everything that happens after the command starts. You can't leave IO logs on the same system where they are created because they are vulnerable to the very people over which the logs are intended to provide a control.
So we'll also look at centrally collecting and archiving IO logs.
Then Paul Harper will briefly show you PowerBroker for Sudo, a new product from BeyondTrust that leverages the extensibility features of sudo to solve the problems of accountability, compliance and centralized management without replacing sudo. Admins keep working as they always have.
This is very technical real training for free ™ event focused on Linux/Unix security. Don't miss it. Please register now.