Free Privileged Account Discovery Tool: Identify & secure credentials to stop lateral movement. Download Free

BeyondTrust
  • Products
    Privileged Password Management
    Discover, manage, audit, and monitor privileged accounts
    Password Safe DevOps Secrets Safe
    Endpoint Privilege Management
    Manage privileges on Windows, Mac, Linux, and Unix endpoints
    Windows and Mac Unix and Linux Active Directory Bridge
    Secure Remote Access
    Centrally manage and secure remote access for service desks and vendors
    Remote Support Privileged Remote Access
    BeyondInsight Analytics
    See All Solutions
  • Resources

    Universal Privilege Management

    Our innovative Universal Privilege Management approach secures every user, asset, and session across your entire enterprise.

    Watch Video

    Learn

    Case Studies
    Competitor Comparisons
    Datasheets
    Glossary
    Product Demos
    Whitepapers

    Attend

    Events
    Go Beyond
    Training
    Webinars

    Support

    Changelog
    Professional Services
    Technical Documentation
  • Blog
  • Partners
  • Contact
  • Support
  • Services
  • Training
  • Events
  • Company

Advanced Control & Audit with PowerBroker for Unix & Linux

January 25, 2016

  • Blog
  • Archive


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.

Scott Lang

Sr. Director, Product Marketing at BeyondTrust

Scott Lang has nearly 20 years of experience in technology product marketing, currently guiding the product marketing strategy for BeyondTrust’s privileged account management solutions and vulnerability management solutions. Prior to joining BeyondTrust, Scott was director of security solution marketing at Dell, formerly Quest Software, where he was responsible for global security campaigns, product marketing for identity and access management and Windows server management.

Stay Up To Date

Get the latest news, ideas, and tactics from BeyondTrust. You may unsubscribe at any time.

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

You May Also Be Interested In:

Whitepapers

Evolving Privileged Identity Management (PIM) In The 'Next Normal'

Webcasts | January 21, 2021

Welcome to 2021: A BeyondTrust Global Partner Update

Webcasts

Security Wellness Check: Keeping Healthcare Safe from Ransomware & other Cyberattacks

BeyondTrust Logo
  • Facebook
  • Twitter
  • LinkedIn

Keep up with BeyondTrust

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

Customer Support
Contact Sales

Products

  • Endpoint Privilege Management
  • Password Management
  • Privileged Remote Access
  • DevOps Secrets Safe
  • Remote Support

Resources

  • Blog
  • Case Studies
  • Competitor Comparisons
  • Datasheets
  • Glossary
  • Videos
  • Webcasts
  • Whitepapers

About

  • Company
  • Careers
  • Contact
  • Events
  • Leadership Team
  • Partner Program
  • Press

Languages

  • English
  • German
  • French
  • Spanish
  • Korean
  • Portuguese
  • Japanese
  • Privacy
  • Security
  • Manage Cookies
  • WEEE Compliance

Copyright © 1999 — 2020 BeyondTrust Corporation. All rights reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust Corporation is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.