Advanced control and audit

What is Advanced Control and Audit (ACA)?

Advanced Control and Audit (ACA) is the ability to control and audit file system activity. The ACA language targets specific actions, such as open/read/write/exec, defines whether each action can or cannot be performed on a file, and can also specify the auditing level. The files for each rule are specified using shell-style file patterns to match files.

How does Advanced Control and Audit (ACA) work?

Each specified action is intercepted and processed to determine if the action is allowed and if auditing is required. Where an audit level is specified, the relevant data is sent back to the originating client to be written to an iolog. When ACA is enabled, the iolog contains both iologging and auditing information. The pbreplay -A (--audit) command line option is used to display the audit records from an iolog.

When the allowed action is an execute action, the ACA policy is passed-on to the new child task to enable ACA policy to continue to be enforced. This enables complete logging and control over a shell session. For example, EPM can be configured to control a bash shell and allow execution of vi while allowing the user to shell escape to another bash shell or to any other allowed program while still enforcing the ACA policy defined for vi and all subsequent executions.

ACA auditing requirements

ACA auditing requires iologging to be enabled for the session. If all ACA statements have a log level of 0 (zero), the task continues without logging. If any ACA statement contains a loglevel greater than zero, the requested task is rejected with the error: "1008.02 ACA audit logging requires an iolog to be specified.". ACA only affects the targeted process and child processes and poses no threat to the operating system as a whole. It can also be configured to not apply to specific child processes to ensure that services can be restarted without ACA being applied.

When should ACA not be used?

ACA should not be used to audit daemons as this results in very large sets of audit data and network traffic and adds little to no security to the non-interactive daemon. ACA rules can be specified to disable ACA for daemon launching mechanisms. In the case that a daemon needs to be executed within an ACA controlled shell session and that session is subsequently terminated, the controlling pbrun or pblocald forks a new process (owned by init) to continue processing ACA auditing.

ACA should also not be used on programs that manipulate logical volumes.

Symbolic links

When processing symbolic links, each link in a link chain is evaluated against the ACA policy. If the requested permission is blocked in any part of the chain, the requested permission is denied.

What are some ACA errors?

ACA errors, such as the inability to read the ACA policy, inability to audit, or out of memory, are logged to syslog and stderr.

ACA uses pbrestcall to send any error messages to a policy or log server using the REST interface. This requires that the adminpath keyword is set in the client’s pb.settings.

On the log server running pbconfigd, the keyword eventdestinations must be used to send ACA errlog data to syslog or to a database.

Example: pb.settings on the client

adminpath /usr/sbin

Example: pb.settings on the log server

eventdestinations errlog=syslog chgmgt=db

Example: Disable central logging

In the policy, set the variable pbulacacentrallogging to 0.

 pbulacacentrallogging=0;

Important considerations

• The Advanced Control and Audit (ACA) is enabled for file-specific operations such as stat, access, open, read, write, truncate, link, unlink, rename, chmod, and chown.

• Socket and memory operations are not supported.

• ACA does not restrict access to critical operating system files, directories, and devices that are required for normal user activity.

  • For example, read access to the following locations is protected: /proc, /dev/null, /dev/zero, /dev/tty, /dev/urandom, terminal, and time zone data.

• By default, ACA denies all actions. All allowed actions must be specified explicitly.

  • For example, if you only have the following ACA rule in the policy (and no other rules for any other actions):

    aca("file", "/etc/resolv.conf", "read");
    

    ...only read actions on /etc/resolv.conf are allowed. All other actions on all other files are not allowed.
    If you have the above rule in the policy, the following works, but the actions fail even as root:

    pbrun ls /var
    pbrun cat /home/myfile
    
    

    📘

    Note

    Many simple commands may operate correctly because they perform operations the ACA does not intercept. Commands such as id, date, pwd, and echo may not call any file-related functions such as open(), thus those commands work even though it appears ACA should deny all access.

    Caching daemons may also affect whether the file-related function calls are used. For example, nscd> may cache user data from /etc/passwd, so id may function without read access to /etc/passwd.

• ACA allows for the provisioning of a rule to cover other actions not specifically matched by the file specifications in subsequent ACA calls. It must be the first ACA rule in the policy.

  • To define this rule you use unmatched as the filespec, this matches all files not matched by other ACA commands. For example:
    ` aca( "file", "unmatched", "all", "DEFAULT Rule");aca( "file", "/etc/*", "!all", "Protect /etc");

    ```
    

    The first rule provides a default for the filesystem, allowing all access to all file actions and for all non-matched files, as long as the runuser has the correct file permissions required. The second rule disallows all access, including read, write, rename, chmod, truncate, and open on files in /etc.

Other considerations

• ACA does not apply to pbksh and pbsh.
• ACA has no control over stdin, stdout, or stderr, because they are opened before ACA begins processing.
• Creating links requires ACA read permissions for the existing file, and ACA link permissions for the new link.
• ACA recognizes Endpoint Privilege Management for Linux binaries to ensure that a permissions loop does not occur, which is when a process running ACA tries to launch a process with ACA.
• The system fails to work properly if you add the ACA shared libraries to the system /ect/ld.so.preload or equivalent file.
• The ACA shared libraries require policy data read from a file descriptor provided by the parent pbrun or pblocald. The system cannot provide that file descriptor (or the EPM-UL ACA policy), so every binary executed fails.
• ACA does not support HP-UX PA-RISC binaries.
• ACA is disabled by the Linux operating system for “Capabilities”-enabled binaries (see man setcap).
• When ACA is specified and an older client on versions 8.5 or below performs an Optimized Run Mode (ORM) request, the policy server rejects requests.
• ACA rules are processed within a secured task after pbrun has executed that secured task.
  • For example, if an ACA rule denies execution of vi, but normal policy allows vi, and the secured task is vi (e.g. pbrun vi), pbrun will execute vi, then that vi process and its children cannot exec a new vi process (vi can shell out to a prompt but that shell cannot run vi).
  • Certain ACA operations do take place before executing the initial secured task, such as determining the binary type, whether it is affected by Linux “capabilities” or is setuid on AIX or HP-UX.

aca

Description

Trap file system related library calls, such as open/read/write/exec, allow, disallow, and audit the calls and specify actions that can or cannot be performed on a file using shell style file patterns to match files. It also specifies an auditing level.

Syntax

aca( control_type, filespec, action permissions and auditing [, tag]);

Arguments

• Loglevel zero , or no log=level specified, specifies that no auditing (logging) of the call is performed.
• Loglevel 1 performs the minimal auditing, recording only the call, permission, and path.
• LogLevel 2 indicates that exec calls will additionally log the argv, and open calls for read, write, or both will additionally log the device/inode/mode/uid/gid of the file.
• LogLevel 3 indicates that exec calls will additionally log the environment supplied.

ACA can derive a shell’s command history by logging additional information. This is enabled with the procedure enablesessionhistory().

Interactions of exec, execstatic, execsetuid:

• exec means execution of a dynamically linked non-setuid not setgid binary is allowed.

• execstatic means execution of a statically linked non-setuid not setgid binary is allowed.

• execsetuid means execution of a dynamically linked setuid/setgid binary is allowed but not a nonsetuid/setgid binary.

• execstatic|execsetuid means any setuid binary or any static binary including a setuid static binary, a setuid dynamic binary, or a static binary.

  In other words, this allows execution of any non-dynamic binary.

• exec|execstatic|execsetuid allows any execution.

AIX and HP-UX do not support LD_PRELOAD or equivalent for setuid/setgid programs.  Similarly, Linux does not support LD_PRELOAD for programs with capabilities assigned. When an ACA controlled process (e.g. a shell) attempts to exec a setuid/setgid or capabilities-enabled binary (on the affected operating system), a warning is issued to the user, and (if configured) sent to the log server’s eventdestination for errlog.  ACA is disabled, and the setuid/setgid/capability program is executed.  EPM ACA Policy should be written to disable ACA,  or deny execution for each specific setuid/setgid/capability binary, thus avoiding the warning message, and assuring proper security for setuid/setgid/capability binaries.

Examples

Example to deny execution:

aca("file","/bin/su","all|!execsetuid|!exec|log=2");

Example to allow execution with ACA disabled:

aca("file","/bin/su","execsetuid|disable|log=2");

Return values

None

Examples

enablesessionhistory

Description

The enablesessionhistory() procedure is used to set the internal read-only variable pbulacasessionhistory. This is used for iologged, ACA controlled shell sessions (for example, bash). The enablesessionhistory() procedure takes a Boolean argument. Values of 1 or true will enable session history. Values of 0 or false will disable session history.

When enabled, the ACA preload library will audit additional information for the secured task (presumably a shell), giving pbreplay the ability to interpret the shell "history", within certain limitations.

Note that iolog must be set, and ACA must be enabled with at least one aca(. . . ) statement.

ACA normally exits when it encounters certain errors. When ACA is used only for session history, and no files or operations are blocked, an optional parameter can be used to cause ACA to continue when those errors are encountered. This results in the task being allowed to continue, however the session history recorded will be incomplete.

The relevant portion of the policy should be similar to:

aca("file", "default", "all");
enablesessionhistory( true, true);
iolog=<file>;

ℹ️

Note

Not supported in Endpoint Privilege Management for Linux (EPM-L).

Known limitations

This mechanism cannot capture or reproduce:

• Shell internals, such as if/then/else, while, math, variable setting or testing
• Which builtin was used
• 2>&1 redirection and ordering
• Complex redirection
• Exact quoting of argv
• (complex) | (pipelines)
• Exact shell history numbering

This feature adds the new --history option to pbreplay, to replay the shell’s "history" from the aca iolog. The --history option cannot be used in conjunction with the -A option).

Syntax

enablesessionhistory( enable_history  [, continue_on_error] );

Arguments

Example

enablesessionhistory( true );
enablesessionhistory( true, true );

See also

aca

ℹ️

Note

For more information, see pbreplay.