This is the second blog in a series that reviews Unix & Linux use cases for least privilege, security and compliance.
In my first blog, I discussed some of the basic use cases you can address with a commercial Unix & Linux least privilege solution like PowerBroker for Unix & Linux. Primarily, what drives the need for such a solution above and beyond using native tools like sudo? Our experience says the primary benefits include:
- Reducing attack surfaces by eliminating credential sharing, enforcing least privilege, and elevating commands without requiring users to have root access.
- Monitoring and auditing sessions for unauthorized access and/or changes to files and directories.
- Analyzing behavior to detect suspicious user, account and asset activity.
For highly-regulated organizations, or those with business-critical data or PII on Unix/Linux systems, you have to go deeper than the basic use cases. In this technical blog, I will review three use cases that discuss the risks of not monitoring activity down to files, scripts and the system level, and how PowerBroker for Unix & Linux solves that.
Get all 15 use cases now by downloading this white paper "15 Common Server Privilege Management Use Cases for Unix & Linux" Download now
Controlling File System Permissions and Access
File systems allow for the setting of individual file and folder permissions such as read, write, execute, etc. However, file and folder permissions are very static in nature and need to be set on each host. There are also risks when allowing highly privileged accounts (such as root) access to a server or workstation, as an account with that type of privilege can easily manipulate permissions and ownership settings using commands such as chmod and chown. Giving an account unlimited access to files and data represents a significant risk.
PowerBroker for Unix & Linux has solved this challenge by allowing the application of centrally controlled, run time security settings that can secure valuable information from even the most privileged accounts. PowerBroker’s Advanced Control and Audit (ACA) policies can be dynamically applied, allowing for the enforcement of file system permission rules during certain times, or allowing access only if certain conditions are met, such as the input of a two-factor authentication or by supplying a valid ticketing system incident number.
With this capability, organizations can grant a full ‘root’ level shell, but at the same time block that root user from being able to access any user files stored in ‘/home’ or by allowing scripts to be executed, but not viewed or edited.
Controlling Script Access and Auditing Script Actions
Unix and Linux administrators rely heavily on the use of scripts to perform daily system administration duties. Many of these scripts have to run as a privileged user such as ‘root’ or call functions that in turn require high levels of privilege. Using a least privilege solution is very important when handing out rights to users that need these elevated rights, and traditionally the best way to audit these users’ activities was to enable some form of session recording, i.e. record stdin and stdout, or log everything the user types and everything the user sees on the screen. The problem with this approach is that when recording these actions, logging the fact that someone typed ‘update.sh’ on the command line provides no way to see what actions were actually performed within the script, what data may have been effected and how the system may have been manipulated.
Using PowerBroker for Unix & Linux and its Advanced Control and Audit (ACA) feature, not only can scripts be more tightly controlled (i.e. scripts can be executed and viewed, but not modified even by root), but with ACA organizations also have the ability to record within a traditional session log all the system level calls that are made, regardless of their source.
This capability allows for actions, such as the execution of a script, to be logged along with every call that the script makes (i.e. reads, writes, executes, etc.). In addition to logging all the script activities, PowerBroker also has the capability to control individual actions within the script and selectively allow or block those actions without stopping the overall processing of the script.
Controlling Access Down to the System Level
Traditional least privilege tools such as sudo focus on controlling what the user types on the command line rather than what the system actually tries to process. The rules defined in such tools focus on what the user is typing and not what the system is actually going to do. In most modern operating systems, however, these two can be very different. For example, on Windows it is very easy to create a shortcut to an item, like ‘notepad.exe’ and name that shortcut ‘My Fav Text Editor.lnk’. If an organization has a policy that stops someone from clicking on an icon named Notepad.exe what is going to happen when someone double clicks on the new short cut just created?
Exactly the same is true in the Unix and Linux world, only being a command line operating system, security policies focus heavily on what the user types at the command prompt. The problem is that shortcuts (known as symbolic links and hard links) can also be used to call binaries (executables) and scripts or reference files. In addition, binaries (executables) can also be renamed to circumvent security policies. Imagine if someone copied the ‘shutdown’ binary and named it ‘ping’. Shutdown may be blocked by sudo, but ping may be just fine. A sneaky admin runs ‘sudo ping’ and the system is going to power down without anyone to figure out what just happened.
PowerBroker for Unix & Linux Advanced Control and Audit (ACA) policy rules enable one line controls to be placed around files and folders, allowing for the target of individual files, files and folders that match a naming template or generically apply to entire folders and all of its subfolders. These controls allow for granular permissions to be set against the target, but more importantly, ACA operates at the system level and not the command line level. Regardless of how the ‘shutdown’ command is called, whether it be directly ‘/usr/sbin/shutdown’, a hard or soft link to ‘/usr/sbin/shutdown’ or a renamed copy of the shutdown command, ACA is intelligent enough to block the execution of the issued command.
See it Action
We’ve recorded a short demo video that explains how PowerBroker for Unix & Linux Advanced Control and Audit capability enables admins to perform more targeted auditing and improve the speed and ease with which audit activities and forensic investigations can be performed. Check it out!
If you’re ready to take the security and compliance of your Unix and Linux systems to the next level, contact us today for a one-on-one demo.
Get all 15 use cases now by downloading this white paper "15 Common Server Privilege Management Use Cases for Unix & Linux" Download now
Paul Harper, Product Manager, BeyondTrust
Paul Harper is product manager for Unix and Linux solutions at BeyondTrust, guiding the product strategy, go-to-market and development for PowerBroker for Unix & Linux, PowerBroker for Sudo and PowerBroker Identity Services. Prior to joining BeyondTrust, Paul was a senior architect at Quest Software/Dell. Paul has more than 20 years of experience in Unix/Linux operations and deployments.
