Advanced Control and Audit

Advanced Control and Audit (ACA) provides 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.

ACA auditing requires iologging to be enabled for the session. If ACA statements are included in the policy and iologging is not enabled, for versions prior to 10.3, the request proceeds with ACA controls, but without auditing. Beginning in 10.3, if all ACA statements have a log level of 0 (zero), the task continues without logging as before. 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.

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, Endpoint Privilege Management for Unix and Linux 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 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.

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.

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 also 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.

adminpath /usr/sbin

eventdestinations errlog=syslog chgmgt=db

pbulacacentrallogging=0;