blog-pro-tip-3-create-simple-unix-linux.jpgThis is the final 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 junior system administrators from certain activities on a system. Be sure to read the first blog focused on senior sys admins, and the second blog focused on mid-level admin 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 certain compliance regulations, and how Unix/Linux least privilege is essential to achieving those requirements, along with writing policies for administrators tasked with addressing these regulations. In this blog, I will review what it takes to enable a junior admin using the PowerBroker for Unix & Linux flexible policy language. But first, let’s review policies in general.

General Policies for Unix & Linux Least Privilege

When writing PowerBroker policies, you have access to many resources on systems. Among these are centralized authentication (Active Directory, LDAP, or local group and identity information), DNS to positively identify both the source and destination servers, and other network resources that may be configured in an enterprise. It is a best practice to make as much use of these external sources as possible. This will help to avoid having to hard-code specifics into policy. It also adheres to the philosophy of ‘separation of duties’ where the policy writer is not responsible for delivering policy and provisioning identities or servers.

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.

Unix Linux Pro Tip

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 1 (Junior Administrators)

We will use the first two policies from this series as a template to build the Level 1 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 addition to the restrictions placed on the mid-level administrators which prevented shutting down servers, or stopping network interfaces, we will add a restriction that prevents modification of any system configuration in the /etc directory.

The mid-level system administrator policy from the second article 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.

# Level 1 System Administrator Policy<br /># Permits junior 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 or modify host<br /># configuration.<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, junior system administrators are<br /># all members of the LDAP group ‘L1ADMINS’<br /># Define the group that this policy will apply to<br />L1AdminGroup = “L1ADMINS”;<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 ( (L1AdminGroup in groups) && (runhost in UnixServers) ) {<br /># Prevent direct execution of specific commands<br /># Capture the entire command the user entered<br />RequestCommand=sprintf(“%s”,runargv);<br />if ( ( basename(command) in { "shutdown", "halt", "reboot”, “ifconfig” }) || ( RequestCommand in { “vi /etc/*” } ){<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 />aca(“file”, “/etc”, “!write”);<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

Junior system administrator policy – summary

I strongly recommend that the policies in this blog series be used as a starting point for developing ones customized to suit your environment. With more than 30 years of experience having pioneered the Unix/Linux least privilege market, we’ve seen it all. 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. Or get the entire series in this tech brief, "Best Practices for Creating Simple, Effective Unix/Linux Least Privilege Policies".