Go to main content

Managing Auditing in Oracle® Solaris 11.4

Exit Print View

Updated: November 2020
 
 

Specifying Files or Directories to Be Audited

Administrators with the appropriate privileges can set ACL entries to audit access attempts for specific files or specific directories.

    The following rights profiles enable administrators to view and modify audit ACLs:

  • Object Access Management

  • Media Backup

  • Media Restore

Local, NFS, and SMB access or failed access to a ZFS file or directory may result in the generation of an audit record, depending on that file or directory's audit ACL entries.

You cannot view or modify the Audit ACEs of a ZFS ACL without the file_audit privilege.

    For remote callers to be able to view or set audit ACL entries:

  • NFS client callers must be root and must have root access on the server, for example, where the client host has been given root access on the server NFS share. Note that this NFS option has security vulnerabilities and is not recommended.

  • SMB client callers must be in an SMB group, with a SID, which has an Administrator, Backup, or Restore privilege. Backup and restore operations may require reading and setting ACL's which contain audit ACEs.


Caution  -  Unprivileged users can perform some tasks that affect the ACL for files and could lose audit information for those files. For example, users could rename another file to replace an existing file that has an audit ACL, thus losing the ACL information. Given this limitation, administrators might want to create default audit ACLs on directories in order to better monitor files in those directories. In addition, some interfaces may update files without preserving the ACL, including the passwd command and other commands that affect password management, such as the useradd command. Administrators should use the appropriate commands when updating system files in order to preserve the ACL, using commands such as chmod, pfedit, remove, rename, or vim.


Setting Audit ACL Entries

The procedures for setting audit ACL entries have been built into existing procedures for modifying ACL entries.

Use the following command syntax to set Trivial ACL audit entries:

chmod [options] A[index]{+|=}owner@ |group@ |everyone@: \
  access-permissions/...[:inheritance-flags]: \
successful_access|failed access:audit file ...
chmod [options] A-owner@, group@, everyone@: \
  access-permissions/...[:inheritance-flags]: \
successful_access|failed access:audit file ...

As shown in this syntax, the chmod command includes the audit option. The command also includes a variable specifying that successful access attempts, failed access attempts, or both will be audited.


Note -  Audit ACL entries can be set using either trivial ACL format or non-trivial format. For a detailed explanation of these formats, see ACL Entry Descriptions in Securing Files and Verifying File Integrity in Oracle Solaris 11.4.
Example 15  Setting Audit ACL Entries

In this example, a trivial ACL exists on a directory named dir1. Run the following command to set an audit requirement for that directory.

# chmod A+everyone@:read_data/read_attributes/read_acl:failed_access:audit dir1

This command specifies that whenever a person in the everyone group tries to access dir1 and fails, that access failure is recorded in the audit log.

To view revised ACL settings for this file, run the following command.

# ls -v
total 1
drwxr-xr-x   2 foo     staff          2 Feb  1 19:28 dir1
     0:everyone@:list_directory/read_data/read_attributes/read_acl
         :failed_access:audit
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/write_xattr/execute/delete_child
         /read_attributes/write_attributes/read_acl/write_acl/write_owner
         /synchronize:allow
     2:group@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow
     3:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow 

Viewing Per-Object Logs

Almost all of the records that can be generated by per-object auditing are existing events in existing classes, so you can search as you usually do by class and then scan for per-file events. Use the auditreduce command to select records by audit classes, including the syntax described in the audit_flags(7) man page to select failed events or successful events. To search for audit records related to a specific file, use the auditreduce command with the –o option and the file=pathname variable. For instructions, see Selecting Audit Events to Be Displayed.


Note -  The only new events for per-object auditing are events for reading file attributes and writing file attributes. These events are not included in any audit class.

For further information, see the auditreduce(8) and audit_flags(7) man pages.