This is the second blog in a series of three that reviews best practices in Unix/Linux least privilege policy development using PowerBroker for Unix & Linux. This post will be geared toward PowerBroker customers developing a policy that restricts mid-level system administrators from certain activities on a system. Be sure to read the first blog focused on senior sys admins, and look for the next blog where we will review junior administrator policies. Or get the entire series in this tech brief, "Best Practices for Creating Simple, Effective Unix/Linux Least Privilege Policies".
In my last blog, I reviewed how important privileged access management is on Unix/Linux systems, and how using the PowerBroker for Unix & Linux flexible policy language can help to simplify policy development so you can more easily meet your security and compliance objectives on administrator activity. This blog reviews mid-level administrator restrictions. But first, let’s review the important role privileged access management plays in achieving regulatory compliance.
Regulatory Requirements and Privileged Access – a Primer
Globally, there are a large number of regulatory requirements that govern the delivery of privileged access management solutions. Ultimately, all of these regulations drive toward the same goal – protecting information for which an organization is responsible. Best practices dictate that companies, when faced with several regulations, should adhere to the highest standard that applies. In so doing, they will meet or exceed the lesser requirements. The most commonly recognized requirements are contained within one or more of these laws:
- Sarbanes-Oxley (SOX) – This is a US law that requires accurate reporting of financial information for all publicly held companies. Protecting financial databases from being altered (Privileged Access and Audit) can be considered under section 404 as an audit point.
- Payment Card Industry / Data Security Standards (PCI/DSS) – This is an over-arching requirement for all organizations that handle financial information, and describes processes and procedures required to safely handle this data. Although this is not a law, it is treated as a mandate in most companies where financial data is handled.
- Health Insurance Portability and Accountability Act (HIPPA) – This is a US law that provides requirements related to the handling of health-care information. The most common interpretation of Title II requires companies to protect from disclosure all patient related information. In cases where database or system access is provided, audits must be available to prove compliance.
It is important to note that there are a number of overlapping requirements that can bind a company to multiple regulatory requirements. For instance, a small company that handles financial transactions and expects to abide by PCI/DSS requirements may also have a healthcare plan for their employees. How this healthcare related information is handled is a requirement of HIPAA regulations in addition to PCI/DSS, so elements of both may apply. Organizations should regularly consult with their legal, regulatory, and compliance teams to determine how and which regulations apply to their business.
Writing System Administrator Policies
System administrators are responsible for making sure that systems are available and healthy; they monitor processes and ensure that applications are performing as designed, and they maintain systems to keep them patched and up to standards.
It is important that policies be developed based on the experience of system administrators that balances the risk of inappropriate activity against system maintenance. As system administrators become more experienced, they can be progressively granted more privileges on systems. For instance, you may want to restrict a junior system administrator from being able to stop a network interface, or reboot a server without a higher-level administrator confirming that is the correct solution.
This method also opens the door to having oversight on system administrators where a second pair of eyes may be required to execute the most privileged commands.
When building the system administration policies, it is best to begin with a base policy that has the least restriction (Level 3), and use that as a template to add restrictions for the other levels. This may seem counter-intuitive, but having a solid template, and locking it down further for the other levels is the easiest way to proceed.
The code below is meant to be demonstrative, rather than efficient. The purpose is to demonstrate the logical construct of a policy, and to show examples for later use.
Best Practice: Back up files
When writing policy, or modifying existing policies, files should be backed up, and with each change, policy should be confirmed with the built-in ‘pbcheck’ command to test syntax and policy structure. All policies should be thoroughly tested prior to implementation.
System Administrator Policy – Level 2 (mid-level)
We will use the Senior System Administrator policy from the first in this series of tech tips as a template to build the Level 2 system administrator policy. The structure will be the same, and some additional command restrictions will be added to tighten user activities using some other features available within the policy language.
In this example, we will restrict the Level 2 administrators from performing a ‘shutdown’ command on a server, or disabling a network interface. Using Advanced Control and Audit (ACA) within PBUL language, access to files, file systems, or execution of binaries can be restricted.
The Senior System Administrator policy from the first post in this series will be used as a template, and new lines will be inserted to add restrictions. Those lines will be in red within the policy for visibility.<br /># Level 2 System Administrator Policy<br /># Permits mid-level system administrators to execute nearly any<br /># command on any server. These administrators are not permitted<br /># to shutdown, or reboot a server, nor are they allowed to stop<br /># or reconfigure network interfaces.<br />#<br /># Author: Bob Policywriter<br /># Original Implementation: 01/01/2017<br />#<br /># Changelog:<br /># 01/10/2017 – Fred PolicyWriter – Added something at the<br /># request of the administrators (CHG0010000)<br />#<br /># Who<br /># In the development policy, mid-level system administrators are<br /># all members of the LDAP group ‘L2ADMINS’<br /># Define the group that this policy will apply to<br />L2AdminGroup = “L2ADMINS”;<br />#<br /># Where<br /># In the development policy, we’ll pretend that there are four<br /># *NIX servers in our environment.<br /># Define Server list where policy will apply<br />UnixServers = “{abc123, abc124, abc125, abc126}”;<br /># What<br /># In the development policy, the senior administrators can run<br /># any command on any of the servers listed.<br /># Commands = “{*}”; -- All commands are authorized.<br />#<br /># Define the condition where this will apply using built-in<br /># variables that come when a request is processed.<br />if ( (L2AdminGroup in groups) && (runhost in UnixServers) ) {<br /># Prevent direct execution of specific commands<br />if ( basename(command) in { "shutdown", "halt", "reboot”, “ifconfig” }) {<br /># do not allow these commands to be delegated<br />reject("This is a restricted command -- '" + basename(command) + "'.");<br />}<br /># Set up I/O (keystroke) log for this session<br /># Identify the root directory where iologs will be stored<br />iolog_dir="/iologs";<br /># Set the HHMM for log file naming<br />logtime=strftime("%H:%M");<br /># Set the log file name<br />iolog=iolog_dir<br />+ "pbul_iolog." # All logs will start with ‘pbul_iolog’<br />+ "admin-session." # Description for session<br />+ sprintf("%d-%d-%d",month,day,year) + "." # MM-DD-YYYY<br />+ logtime + "." # HH:MM<br />+ split(runhost,".")[0]; # Short name of the host<br />+ basename(command) + "."; # Command entered<br />+ ".XXXXXX"; # Unique serial number<br /># Set user environment for this session<br />runcwd = "/tmp"; # Directory to run command from<br />rungroup = "!g!"; # Group for user<br />rungroups = {"!G!"}; # All groups for user<br />setenv("SHELL", "!!!"); # Set user shell<br />setenv("HOME", "!~!"); # Set user home<br />setenv("USER", RunUserName); # Set username<br />setenv("USERNAME", RunUserName); # Set Name i.e. ‘bob jones’<br />setenv("LOGNAME", RunUserName); # Set logname variable<br />setenv("PWD", runcwd); # Set directory to start in<br />setenv("PATH", "/bin:/usr/bin:/sbin:/usr/sbin"); Set PATH<br /># Set command execution<br />runuser = “root”; # All commands for this policy run as ‘root’<br /># Restrict command execution within a session.<br />aca("file", "/bin/shutdown", "!exec");<br />aca("file", "/bin/halt", "!exec");<br />aca("file", "/bin/ifconfig", "!exec");<br />aca(“file”, “/bin/reboot”, “!exec”);<br /># Notify user that session logging is on<br />print("WARNING: This session is being centrally recorded.”);<br />print("Session Recording Filename:",iolog);<br /># Accept the command, and proceed with execution<br />accept;<br />} # End if group and host are in the list
Note that there are two sets of ACA rules in the policy. The first is in case the command was called directly (‘pbrun shutdown’), and the second will work within a session if someone directly accessed ‘root’.
Mid-level System Administrator Policy – Summary
Restricting activities for various levels of system administrators can be considered a way to enforce internal escalation within an operational environment. If the need to stop a system, or a network interface arises, making this unavailable to lower level administrators will ensure that senior administrators are engaged before availability is impacted. In some cases, only two levels will suffice, but any number of levels can be designed using policy, each with separate or compound restrictions.
It is strongly recommended that the above examples be used as a starting point for developing policies customized to suit your environment. For more information on how BeyondTrust can help you simplify Unix/Linux security and compliance, download our white paper, "Simplifying Unix & Linux", or contact us for a demo today.
Up next is the final blog in this series that discusses policies for junior system administrators. Or get the entire series in this tech brief, "Best Practices for Creating Simple, Effective Unix/Linux Least Privilege Policies".
Chad Erbe, Professional Services Architect, BeyondTrust
Chad Erbe is a Certified Information Systems Security professional (CISSP), with nearly 30 years’ experience in a Unix/Linux administration role. Chad has worked in DoD high-security environments, manufacturing, and with large financial services companies throughout his career. This broad experience has lead him to an architectural role with BeyondTrust where he focuses on Privileged Access Management, particularly in the Unix suite of products. Chad also maintains his PCI ASV certification from the PCI council.