Advanced Control & Audit with PowerBroker for Unix & Linux

Advanced Control and Audit Release Notes description

The new Advanced Control and Audit (ACA) feature released in PowerBroker for Unix & Linux 9.0, will trap file system related library calls and allow, disallow, and audit the calls. The new ACA language will specify actions (e.g. open/read/write/exec) that can, or cannot be performed on a file (using shell style file patterns to match files), and will also specify an auditing level. Each specified library function call will be intercepted by a PowerBroker for Unix & Linux library. Once intercepted, the ACA statements will be processed to determine if the action is allowed, or if auditing is required. If auditing is specified, the relevant data will be sent back to the originating client to be written to an IO log or an ACA log.

Summary

ACA is best used to control file and application execution access of a delegated processes.

Common challenges solved by ACA:

"Shelling out”

Applications such as “vi”, “ ess”, and "more" allow an end user to execute applications as a child process. Launching a shell application (“bash” or “ksh” for example) from these applications is known as “shelling out.” Such behavior exists to allow referencing or duplicating contents of another file into the file being edited. This creates a great challenge for administrators.

Sudo solves this challenge by enforcing a “noexec” policy which denies the delegated process from spawning child processes. ACA, in essence, is the “triple platinum” version of “noexec” in that it allows the administrator to define allowed child processes rather than explicitly blocking everything. For example, ACA allows the editor to cat or grep a separate file and return to their edit without having to leave vi, while denying other applications from being executed.

Script abuse

The longevity and complexity of scripts make them difficult to review, approve, and secure. Although checksum or hashes are commonly utilized to “fingerprint” a script these hashes can be duplicated even after modification. As an additional layer of security, the script auditor can identify the applications and file access required to complete and permit minimum privilege to the script regardless of its “fingerprint”.

Data Leak and Privacy

With the ability to read and write files as root comes access to files owned by others. ACA has the ability to disallow such access dynamically jailing the submit user into their own home directory

Design

Tested platform: CentOS 6.6

/etc/pb.conf /etc/acaProcs /etc/acaForbidden

Contents of /bin/commands script.sh

The “acaProcs” policy file is designed with 7 different functions:

readACA	= read only (point to directory)
writeACA	= read/write & no exec
execACA	= exec
execsuidACA	= exec SETUID

NOTE: as SETUID applications are particularly powerful they must be explicitly permitted in the policy, the /bin/commands/suid is not implicitly permitted.

readsingleACA	= allow for a single file to be read (primarily to fix bash issues due to “forbidden”)
denyACA	= deny all action
defaultACA	= default allow lists everything, required for block listing commands. Primarily used in the script abuse section below.

Mandating the ability to exec where one cannot write and write where one cannot execute is the goal of this policy permitting the ability to investigate a system but not make administrative changes.

To allow additional applications to be run simply create a symbolic link in /bin/commands. If the applications is SETUID (confirm with ls –l on the targeted binary) the link must go into /bin/commands/suid and added to the policy (see more below).

As each privilege is delegated in the form a function additional access maybe permitted by adding the appropriate function call to the policy file. For example:

readsingleACA(“/etc/pb.settings”);	= allows admin to check the configuration of pb.settings
readACA(“/var”);	= allows read access to /var and its subdirectories
execSUID(“/bin/commands/mount”);	= allows the SETUID binary “mount” to execute (symbolic link does not exist in the provided files by default)

Exercise

Diagnostic Shell:

Running “pbrun bash” will provide you with what has been deemed a Diagnostic Shell allowing only applications under /bin/commands, /bin/commands/suid/ping, and write access to $HOME and /tmp

Browsing to another runuser’s home directory is denied.

Script protection:

The provided “script.sh“ simply runs the “date” command. However, in this example the script has been maliciously commandeered to also create the user “im-a-backdoor-user”. Fortunately, “user add” has been denied by denyACA (/usr/sbin/useradd”). To obfuscate the user add command, an attempt to copy the binary is also denied.

These advanced audit and control features are found in PowerBroker for Unix & Linux. For more information, contact us.