Audit Administration Profiles
The Solaris operating environment provides profiles for configuring the audit service and for analyzing the audit trail.
Audit Control - Profile that enables a role to configure Solaris auditing. The profile grants authorizations to configure auditing files and to run auditing commands. Roles with the Audit Control profile can run the following commands: audit, auditd, auditconfig, bsmconv, and bsmunconv.
Audit Review - Profile that enables a role to analyze Solaris auditing records. The profile grants authorization to read audit records with the praudit and auditreduce commands. The role can also run the auditstat command.
System Administrator - Profile that includes the Audit Review profile. A role with the System Administrator profile can analyze audit records.
To assign a profile to a role, see Creating Roles.
Audit Classes and Their Audit Flags
Audit flags indicate classes of events to audit. Machine-wide defaults for auditing are specified for all users on each machine by flags in the audit_control file. The file is described in The audit_control File.
You can modify what is audited for individual users by putting audit flags in a user's entry in the audit_user file. The audit flags are also used as arguments to the auditconfig command. See the auditconfig(1M) man page.
Definitions of Audit Flags
The following table shows each predefined audit class. The table shows the audit flag, the long name, and a short description. The audit flag is the short name that stands for the class. You use these audit flags in the auditing configuration files to specify which classes of events to audit. You
also use them as arguments to auditing commands, such as auditconfig. You can define new classes by modifying the audit_class file. You can also rename existing classes. See the audit_class(4) man page for more information.
Table 23-1 Predefined Audit Flags
Short Name | Long Name | Short Description |
|---|
all | all | All classes (meta-class) |
no | no_class | Null value for turning off event preselection |
na | non_attrib | Nonattributable events |
fr | file_read | Read of data, open for reading |
fw | file_write | Write of data, open for writing |
fa | file_attr_acc | Access of object attributes: stat, pathconf |
fm | file_attr_mod | Change of object attributes: chown, flock |
fc | file_creation | Creation of object |
fd | file_deletion | Deletion of object |
cl | file_close | close system call |
ap | application | Application-defined event |
ad | administrative | Administrative actions (old administrative meta-class) |
am | administrative | Administrative actions (meta-class) |
ss | system state | Change system state |
as | system-wide administration | System-wide administration |
ua | user administration | User administration |
aa | audit administration | Audit utilization |
ps | process start | Process start and process stop |
pm | process modify | Process modify |
pc | process | Process (meta-class) |
ex | exec | Program execution |
io | ioctl | ioctl system call |
ip | ipc | System V IPC operations |
lo | login_logout | Login and logout events |
nt | network | Network events: bind, connect, accept |
ot | other | Miscellaneous |
Audit Flag Syntax
The prefixes to the audit flags determine whether a class of events is audited for success, or for failure. Without a prefix, a class is audited for success and for failure. The following table shows the format of the audit flag and some possible representations.
Table 23-2 Plus and Minus Prefixes to Audit Flags
prefixflag | Explanation |
|---|
lo | Audit all successful attempts to log in and log out, and all failed attempts to log in. You cannot fail an attempt to log out. |
+lo | Audit all successful attempts to log in and log out. |
-all | Audit all failed events. |
+all | Audit all successful events. |
 Caution - The all flag can generate large amounts of data and fill up audit file systems quickly. Use the all flag only if you have extraordinary
reasons to audit all activities.
Prefixes That Modify Audit Flags
Audit flags that were previously selected can be further modified by a caret prefix, ^. The following table shows how the caret prefix modifies a preselected audit flag.
Table 23-3 Caret Prefix That Modifies Already-Specified Audit Flags
^prefixflag | Explanation |
|---|
-all,^-fc | Audit all failed events, except do not audit failed attempts to create file system objects |
am,^+aa | Audit all administrative events for success and for failure, except do not audit successful attempts to administer auditing |
am,^ua | Audit all administrative events for success and for failure, except do not audit user administration events |
The prefixes to the audit flags can be used in the following files and commands:
In the flags line in the audit_control file
In flags field in the user's entry in the audit_user file
With arguments to the auditconfig command
See The audit_control File for an example of using the prefixes in the audit_control file.
Audit Policies
Audit policies determine if additional information is added to the audit trail. The audit policies are described in Determining Which Audit Policies to Use.
Process Audit Characteristics
The following audit characteristics are set at initial login:
Process preselection mask - A combination of the audit flags from the audit_control file and the audit_user file. When a user logs in, the login command combines the flags to
establish the process preselection mask for the user's processes. The process preselection mask specifies whether events in each audit event class are to generate audit records.
The algorithm for obtaining the process preselection mask is described in the following equation:
user's process preselection mask = (flags: line + always-audit flags) - never-audit flags
|
Add the audit flags from the flags: line in the audit_control file to the flags from the always-audit field in the user's entry in the audit_user file. Then, subtract from the total the flags from the user's never-audit field.
Audit ID - A process acquires an audit ID when the user logs in. The audit ID is inherited by all child processes that were started by the user's initial process. The audit ID helps enforce accountability. Even after a user becomes root,
the audit ID remains the same. The audit ID that is saved in each audit record always allows you to trace actions back to the original user who had logged in.
Audit Session ID - The audit session ID is assigned at login. The session ID is inherited by all descendant processes.
Terminal ID (port ID, machine ID) - The terminal ID consists of the host name and the Internet address, followed by a unique number that identifies the physical device on which the user logged in. Most often, the login is through the console
and the number that corresponds to the console device is 0.
|
Previous