Important Considerations

The ACA is currently enabled for file-specific operations like stat, access, open, read, write, truncate, link, unlink, rename, chmod, and chown. Socket and memory operations are not supported. Furthermore, the ACA does not restrict access to critical operating system files, directories, and devices that are required for normal user activity.

For instance, 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.

If you only have the following ACA rule in the policy:
aca("file", "/etc/resolv.conf", "read");

Since there is no rule for any other actions, only read actions on /etc/resolv.conf are allowed, all other actions on all other files are disallowed. With the above rule in the policy,

pbrun cat /etc/resolv.conf

works, however, the following actions fail even as root:

pbrun ls /var
pbrun cat /home/myfile

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.

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 Privilege Management for Unix and 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/ 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 PMUL ACA policy), so every binary executed fails.
  • As of Privilege Management for Unix and Linux 21.1.0, ACA no longer supports HP-UX PA-RISC binaries.
  • ACA is disabled, by the operating system, on Linux 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.