A Better Way to Sudo 

Part 1: Using Sudoers to understand Centrify DirectAuthorize 

Series overview

The goal of this series is to help Centrify Server Suite customers take better advantage of our enhanced implementation of sudo and sudoers known respectively as "dzdo" and DirectAuthorize. In this series we'll address several areas around  UNIX privilege elevation, such as our Sudoers to DirectAuthorize migration tooling. To kick-off the series, its important that we have a basic understanding of the DirectAuthorize policy model. If you are familiar working with sudoers, you will be right at home with DirectAuthorize. And if you’re not familiar with sudoers, no problem… we’ll show you how the pieces logically fit together. At this point, I’ve identified the first three parts to series with more to come:

• Part 1 - Using Sudoers to understand Centrify DirectAuthorize: We’ll discuss the key gaps in “native” sudoers heard from our customers and why you should consider migrating to DirectAuthorize. Next, we’ll compare how UNIX users interact in the UNIX environment through “dzdo” (Centrify’s enhanced implementation of sudo).  And then we'll use sudoers as a frame-of-reference to introduce the DirectAuthorize policy model.
• Part 2 – Representing sudoers policies through the Centrify user interface: Using the working sudoers file example introduced in Part 1, you’ll see how these policies are represented in Active Directory and the Centrify DirectManage Access Manager user interface.
• Part 3 – Sudoers to DirectAuthorize migration tooling: We introduce the out-of-the-box technical tooling to assist in your transition from your current sudoers file based implementation to DirectAuthorize. To set expectations, the purpose of showing Centrify's out-of-the-box suoders migration wizard is to further illustrate the similarities between Centrify's UNIX RBAC model and native sudoers. That said, if you are considering a migration, it might be worthwhile to enlist experienced guidance from Centrify's Professional Services team.

Sudoers challenges in an enterprise environment

Sudo authorizes UNIX users to run specific commands  within the "elevated" context of a privileged account (e.g. root). Sudo has been evolving since its introduction in the 1980’s. Given “native” sudo’s longevity, UNIX administrators are well accustomed to working with it. However, sudo also has key gaps when considering today’s enterprise climate of privilege identity related breaches, compliance reporting, and IT operations spanning on-prem and Infrastructure-as-a-Service. So when we first discuss with our customers that Centrify Server Suite includes a simpler, scalable, and more secure approach to native sudo, it is not surprising to see conflicting reactions of both optimism and apprehension. As one customer put it, “On the upside, I can see how Centrify's approach to UNIX privilege elevation addresses native sudoers' shortcomings. That said, we’ve worked with sudoers for years. And as a sys-admin I can say that we're all creatures-of-habit.” As a result, we see some customers use Centrify Server Suite primarily for authentication and session auditing/recording without fully taking advantage of Centrify's enhanced implementation of sudo. So, how do we reconcile these conflicting reactions to sudoers' (e.g. its shortcommings and comfort/familiarity)? In short, once UNIX administrators understand how Centrify's RBAC policy model parallels the native sudoers format they're accustom to,  everything starts to click. From there, the value of Centrify's enhanced sudoers implementation becomes readily apparent. As a UNIX administrator you will see that our approach is both familiar to work with AND it resolves native sudoers' major shortcomings. 

Native Sudoers' Shortcomings

Let's drill-down on some examples of sudoers' shortcomings we hear from customers:

“We’ve used sudo for years. It’s fine…for the most part. That said, sudoers has its challenges within our enterprise:

• APT’s and Bots: With sudo you can only re-challenge someone with username/password authentication. And password challenge does not provide assurance that there is an authorized human behind the keyboard… It could be a bot, an attacker with stolen credentials, etc. LinkedIn and Facebook, make it too easy for the attackers to target spear-phishing attacks against my staff. They are well trained and vigilant. That said all it takes is for someone to have a quick mental lapse and open an email attachment he shouldn’t. And boom, the bad guys are in and setting up shop… worse, there’s a good chance we won’t even know it. 
• Multi-factor Authentication: That said, it would be great if there were an easy way to trigger an MFA challenge on my Linux systems when invoking a privileged command. Backstopping invocation of a privileged command with an out-of-band multi-factor challenge would give us better assurance that this is one of my people performing the action… not a bot or an attacker with stolen credentials.
• Granting & revoking temporary access to privileged commands: We have partners that need to perform specific tasks, usually on some time-limited basis. When I share this requirement with vendors, we’re usually presented with shared account password management (SAPM) features. To be clear, I’m not talking about giving someone temporary access to the root password!!! No… We need the ability to assign named users time-limited access to a defined set of privileges. Trying to provision and de-provision temporary privileged rights within sudoers files distributed all over the enterprise across numerous internal and offshore teams doesn’t scale.
• Granting access to specific PAM enabled applications: We have “business” users with UNIX accounts to access specific PAM enabled business apps. These users do not need to access the servers’ UNIX shell. With sudo there’s no way to restrict a UNIX account’s access to specific UNIX PAM applications.
• Reporting – Who is doing what?: Even with sudoers, too many users feel they need root 24x7 to do their job. So people login as root. Beyond the obvious issue of someone misusing this access, we are also unable to attribute account activity in our local logs to the actual person that performed the action. We can see that the root account ran commands X, Y, and, Z… But who was actually at the keyboard? We had a production outage last week. Of course when I asked the team if anyone made any changes, all I heard were crickets.
• Reporting - Who has access to what?: You can’t manage what you can’t see. Given that sudoers files, UNIX accounts and UNIX groups are configured locally on each system, it is not easy discerning who can do what and on what machines. We don’t have an effective process that connects the dots between people and their UNIX privileges. Today we rely on a homegrown manual process that aggregates access into spreadsheets where we try to eyeball any excessive access and remediate.
• Compliance drift & sustainability: Unfortunately, after remediation we don’t do a good job of sustaining least access and least privilege. And, its not too long after remediation when users begin accumulating excessive access all over again. Our identity lifecycle management processes do a decent job controlling access to applications, AD accounts, and AD groups. However, we don’t address server access rights very well. Beyond compromising our compliance posture, this “compliance drift” further exacerbates the potential damage done by the APT and stolen credential concerns mentioned earlier.
• Balance enterprise standards with departmental control: Our Linux growth spans several departments both on-prem and across a couple IaaS providers. We need to make sure teams comply with our corporate security requirements. At the same time, it is important to delegate decision making authority to those directly responsible for their systems. We’ve looked at LDAP-based sudoers and centralized *NIX config management to push a “master” sudoers. However, among their shortcomings, both approaches lack the balance between centralized control and departmental autonomy.

So, what can you do for us? Before you answer, keep mind that we don’t have the appetite to deploy massive infrastructure and retrain my staff on some new and proprietary security paradigm. Whatever the solution is, it must be familiar… don’t reinvent the wheel… just make the wheel enterprise class. So please, tell me…”

What else do we hear about native sudo?

When we first start working with customers, most use sudo. The sophistication to which sudo is configured ranges from fairly coarse grained controls to very granular and complex policy rules that grow over the years. We encounter customers disciplined about using named accounts to perform administrative tasks. On the other hand, even with sudo in place, some shops still struggle with admins authenticating directly with privileged account (e.g. root) rather than their personal named accounts.

What is consistent across orgs is that sudo is a bear to administer consistently. Most shops rely on local sudoers files to administer policy. To maintain consistency, larger enterprises might push a “master” sudoers file through a configuration management solution such as Puppet or Chef. Configuration management has an important place in the enterprise. That said, config management tools are not the same as a purpose-built UNIX policy administration point. Furthermore, the challenge with treating sudoers as “just another config file” is that maintaining the “one sudoers file to rule them all” usually results in a file that is very complex and brittle. This complexity creates lifecycle management headaches and potential policy blind spots where access is granted in unintended ways.

Now that we’ve shared some of native sudoers key gaps we hear from our customers, lets discuss how we’re similar to sudo and what we do better…

Invoking Privilege Elevation (sudo and dzdo):

First the basics… here’s an example Illustrating how to invoke a privileged operation first with sudo and DirectAuthorize (dzdo).

Figure 1

And if typing “dzdo” to invoke a privileged command seems strange, no problem. Simply set an alias to sudo.

Regarding the advanced persistent threat (APT) and bot concern mentioned above, lets take a look at another example (Figure 2 and 3). Here a web administrator, Wanda, needs to perform a privileged action such as restarting the production web server. Since this is a particularly sensitive operation, we want to make sure it really is Wanda behind the keyboard first. Before the command executes, a multi-factor authentication challenge is presented to Wanda via her Centrify mobile app.

Figure 2: Similar to "sudo", the user types in "dzdo" to run a command in a privileged user context. The policy for this command was set to require an MFA challenge. The user is then presented simple options to complete the MFA challenge.

Figure 3: The user then accesses her Centrify mobile app (iOS or Android) to complete the MFA challenge. Available options include the app’s Approve/Deny buttons, a one-time-passcode, etc.

Sudoers 101:

Before we begin to layout the parallels between the DirectAuthorize and sudoers policy models, let’s level set and build out a few simple sudoers policy definitions. Here a sys admin, Gautam, needs the rights to perform a few privileged back-up related commands on a Linux machine (us-nonprod-rh-web1):

Figure 4

Easy, right? OK… now Becky needs those same rights:

Figure 5

Now let’s say that Gautam, Becky, and the back-up team (e.g. ADM_US_RH_BKUP) are responsible for all back-ups on all Red Hat machines in the US (e.g. SVR_US_RH). Along with this, the non-production web admin team (e.g. ADM_NP_RH_WEB) is responsible for managing Apache on all non-production Red Hat servers globally (SVR_NP_RH_WEB). Let’s add the non-prod US databases (SVR_US_NP_RH_ORCL) and DBA’s (ADM_US_NP_ORCL) to the mix as well. Relatively speaking, the sudoers example below is just a baby. But its easy to see that overtime these policies can grow to the point where keeping the file organized and error free becomes a complex undertaking and a source of security risk.

Figure 6

Mapping Centrify’s RBAC model to sudoers

Its important to understand that DirectAuthorize’s policy model provides everything you need to represent your sudoers policies and then some. Table 1 provides a quick cheat sheet that maps sudo terms to Centrify Server Suite’s RBAC model.

Table 1: Sudoers to Centrify Server Suite RBAC terminology

Let’s review this from the perspective of an example sudoers file in Figures 7-10.

Figure 7: The User_Alias corresponds to AD groups of users

Figure 8: The Host_Alias corresponds to an AD group of computers

Figure 9: The Cmnd_Alias corresponds to Centrify Roles. The UNIX commands comprising a Cmnd_Alias also appear individually in the Centrify UI as UNIX Rights. Customers can then recombine Centrify “UNIX Rights” to form new Centrify Roles (which we’ll cover in the next article)

Figure 10: The Sudoers User Specification (User_Alias, Host_Alias, and Cmnd_Alias) equates to Centrify Computer Roles (e.g. AD User Group, AD Computer Group, and Centrify Role).

Checkout Part 2

Hopefully you found this opening article to the “A Better Way to Sudo” series helpful. I look forward to your feedback and questions. In the next series installment, we’ll cover how the sudoers policies introduced in Part 1 are represented through the Centrify user interface and Active Directory.