Security models have struggled to match the evolution of Unix.
Over its long history, Unix has evolved and changed in many different ways. What started in Bell Labs 40 years ago has spawned more than 150 variants of Unix in use today. Unlike the linear progression of Windows operating systems, in which most organizations use a single version until it is replaced, many flavors of Unix are in use at the same time, even within a single organization.
One thing that hasn’t changed much in all these years is that every Unix server, and its open-source cousin Linux, has a local database of users and groups. If you have a single host with one user, there’s no problem with management. But, when you have multiple servers, a single user becomes multiple and it’s very easy to start mixing things up and create a mess.
You can easily end up with different usernames, UID’s, PGID’s, GID’s, home directories, login shells, and, of course, passwords on each system. I might be Pharper with a capital P on the first one, pharper on the second, p.harper on the third, and so on. With a user’s attributes tied so tightly to the file and folder permissions on a Unix host, which is something else that hasn’t changed much since the early days of Unix, user, group, and permission management quickly becomes a tedious and time-consuming task.
It’s a lot of work for administrators to keep things secure. Users struggle to remember their credentials and compliance becomes more or less impossible.
Administrators have turned to numerous different workarounds and configurations to try and ease this burden, with varying success and still resulting in too many local accounts on their system. Others still use generic shared accounts and control privileged access to those shared accounts. This approach is a violation of least privilege best practices and makes it difficult to know who is using the system and what they are doing, which then makes compliance reporting and forensics in the case of a breach quite challenging.
Imagine the work when an employee leaves your organization
Some companies have tried to design and integrate their own synchronization or provisioning tool, none of which have shown much success. Even those that try to leverage LDAP end up with overly complicated configurations and spend many hours managing multiple directories that are separate from Active Directory. You need to assign privileges to users across multiple different accounts, including LDAP, local accounts, and Active Directory. Just imagine the work when an employee leaves your organization and all the places and permutations you’d need to check to revoke their access.
Ignoring the Unix risk is not an option. If you don’t include Unix and Linux in your security strategy, you’re leaving open some of the most vulnerable and high-value targets prone to attack.
Why should you focus on Unix and Linux security?
Simply put, Unix and Linux systems are high-value targets for cyber criminals.
Your mission-critical applications, such as web servers, database servers, and application servers, are more often than not running on Unix/Linux. Linux has now become the most common, go-to operating system for computer hardware and even mainframes these days. It’s not just these systems that you must protect; it’s the applications and the data stored on them.
All Unix and Linux systems suffer from the same weak point—the “root” account. The root account provides the highest and broadest level of control (god-like privileges), so protecting root access must be a priority.
In a Unix/Linux environment, many people need or at least claim to need superuser privileges. I have heard the phrase “I need root” more times than I care to remember. A user must have superuser privileges for many day-to-day operations, such as installing, removing, or changing any piece of software on a given host. A superuser (such as root) has access to the Unix operating system in an unrestricted form and therefore has access to all commands, files, directories, and resources.
Unix/Linux privilege management is different from Windows and Mac
Unlike in a Windows or Mac environment, you need to consider privilege management on Unix and Linux in terms of the command line. The goal of ‘command control’ is to determine by a policy which commands should be allowed to run and which ones should be explicitly denied. In fact, given the numerous ways Unix and Linux allow commands to be issued at the command line, unlike in Windows and Mac environments, choosing which commands or system functions to block is actually more important than choosing which to allow.
Privileged session management is another key difference for Unix and Linux security. To monitor and audit privileged account activity on a Windows machine, you typically perform some form of video screen recording. For Linux and Unix however, you need to log everything the user sees on the screen, specific keystrokes they type, what commands they execute, and even the actions being performed by the system.
System-level auditing is important given the amount of administration performed using scripts. Much of the user and superuser changes would be excluded from the audit trail without such recording capabilities. Once all this information is gathered, typically in text form, it should be indexed and made searchable and/or reportable to avoid labor-intensive data review processes.
The typical method of Unix/Linux privilege management and privilege elevation is Sudo
Once proper account management has been implemented and you’ve taken steps to secure passwords of privileged accounts (credential and secrets vaulting), then removing all unnecessary access, including direct or break-glass, to accounts such as root should be the next priority in your Privileged Access Management (PAM) journey.
To address this challenge, Sudo allows Unix and Linux users to run programs with the security privileges of another user. It’s basically the equivalent of the “run as” command in Windows.
The Sudo method for Unix privilege management is 30 years old. It originally stood for “superuser do” as the older versions of Sudo were designed to run commands only as of the superuser. Later versions of Sudo added support for running commands as other users, so it’s now commonly defined as “substitute user do.”
Sudo provides more fine control than the Unix “Su” command. Su switches you to the root user account and requires the root account’s password to run. Sudo can run a single command with root privileges. It doesn’t switch to the root user or require a separate root user password.
The purpose of Sudo is to enforce a least privilege policy, while still allowing you to elevate a user account to have root privileges temporarily.
Once a user enters a password to provide system-based permissions, the Sudo command provides permissions to any particular command that a user wants to execute. After authentication, and if the configuration file (policy file/sudoers) provides the user access, the system invokes the requested command with elevated rights.
You can configure detailed access permissions to increase security controls, such as enabling commands only from the invoking terminal, requiring a password per user or group, requiring re-entry of a password every time for a particular command line, permitting or restricting passing arguments, and so on.
A sophisticated Unix team can add privileged security functionality to basic Unix protections
The flexibility of Unix and the strength of the Linux open-source community means you can find many options to enhance privileged security on your own.
For example:
- Open-source options and third-party software allow for Unix session monitoring and recording.
- In association with SELinux, Sudo can be used to transition between roles in Role-Based Access Control.
- In newer versions of Linux, using the integrity measurement architecture, module signing, and Secure Boot, it’s possible to have a system where almost any change is detected.
There are downsides to cobbling together your own Unix or Linux privilege management solution
Managing Unix and Linux security on your own is a heavy lift, however. There are many downsides to cobbling together your own privilege management solution.
Unix privilege security is cumbersome and expensive to set up. To properly use Sudo, you need highly skilled (and highly paid) system administrators to spend a great deal of time building sudoers files. Then you have to distribute the files across your organization.
This privileged security approach is an order of magnitude more difficult to maintain when new versions of Unix or Linux are adopted by your users. Even after you complete the initial setup, doing everything yourself means you have no vendor to rely on for testing, maintaining, documenting, and other ongoing software management functions.
In addition to administrative and operational costs, there are also security and compliance risks with the typical approach to privileged security for Unix and Linux:
- Sudo privilege elevation introduces a security risk because it’s controlled by local files. Auditors don’t like the distributed Sudo configuration files because they utilize “static trust.” These files are stored in a way that local administrators could easily make modifications.
- There’s no safety net for Unix super users. For example, there’s nothing preventing a superuser with broad privileges from intentionally or accidentally deleting a system file.
- It’s difficult to confirm users are who they appear to be. Sudo doesn’t inherently provide multifactor authentication as part of the user authorization process. Without built-in accountability, there’s no way to tell which person may be responsible for the damage.
- If an application is executed by a superuser using a root account, full root privileges are transferred to that application. If the application receiving the privileges contains a security vulnerability, the door is open to exploit from a cyber criminal.
If you don’t maintain and update Sudo, you may miss security vulnerabilities. Just last year, developers fixed a flaw in Sudo that let you claim root-level access even if the configuration explicitly forbids it. If an intruder had enough access to run Sudo, they could perform any action they wanted on a given machine.
Comprehensive, enterprise PAM is a better solution for Unix/Linux protection
We believe it’s time to think differently about how to manage Unix security. A multi-layered approach simplifies management and reduces security risk.
We recommend the following approach:
Step 1
The first order of business for Unix protection is to get everything in one place. To manage Unix security in a sustainable way, you need to get user accounts under control and assigned to a single account.
In a Windows environment, Active Directory (AD) allows this unification. AD leverages LDAP under the hood, but it largely uses Kerberos as the authentication protocol for Windows machines, so Unix devices struggle to integrate with AD.
An AD bridge extends Group Policy to non-Windows platforms so you can perform account maintenance and password updates for all systems through a single tool. With an Identity Bridge, you take advantage of consistent data across all of your systems. Each user truly has one username, one ID, one password, one home directory, etc.
Step 2
Once this type of identity unification is in place, a central PAM solution connects to your AD and lets you authenticate users and assign privileges with ease. PAM solutions enable the ongoing discovery of Unix/Linux superuser privileges to increase accountability and enforce consistent management. Immutable audit trails and enhanced controls, such as session monitoring and recording, provide oversight and simplify reporting and compliance.
Step 3
After a user is authenticated and logged in to your IT resources, Unix privilege management controls what actions they can take. Granular control of root credentials limits privileges while meeting compliance regulations and policies for Unix Superuser Privilege Management (SUPM).
You can reduce the risk of privileged account abuse or accidental error by restricting commands based on defined policies and limited superuser permissions. SSH command allowlist allows admins to log in as root, but only gives them access to a set of predefined commands. For example, a Unix allowlist might mean IT administrators might be able to restart the database and read log files, but not reset user passwords.
Benefits of a unified privilege management/PAM system for Windows, Mac, and Unix
Most organizations have a mix of different operating systems for different functions. Some teams will always prefer Unix and Linux to Windows or Mac due to their flexibility as well as their open-source nature. As a security leader, you need to include all types of IT systems and all parts of your organization in your security strategy and ensure they follow security policies consistently.
You can support the different operating system groups within your IT organization and manage a comprehensive privileged security strategy with advanced least privilege solutions. Users like this approach because they no longer have to remember multiple credentials to log onto each of their systems.
A central PAM solution reduces the risk and complexity of managing a heterogeneous environment. It provides the benefit of common security policies and practices across groups. Preparing reports for management and audits become a simple, repeatable process. Now, when you need to revoke access when an employee leaves your organization, you can manage it with one step and include all systems.
Talk with our team about Delinea and Unix / Linux privileged management and stay tuned as we continue to roll out solutions for each step in a layered approach to Unix protection.