The following terms are used to describe the audit service. Some definitions include pointers to more complete descriptions.
A grouping of audit events. Audit classes provide a way to select a group of events to be audited.
For more information, see Audit Classes and Preselection, and the audit_flags(5), audit_class(4), and audit_event(4) man pages.
A repository of audit files in binary format.
For more information, see Audit Logs and the audit.log(4) man page.
A security-related system action that is auditable. For ease of selection, events are grouped into audit classes.
For more information, see Audit Events and the audit_event(4) man page.
An audit class that is supplied as an argument to a command or keyword. Audit flags preselect which audit classes are to be audited for a process.
For information about using audit flags, see Audit Class Syntax and the audit_flags(5) man page.
A module that transfers the audit records in the queue to a specified location. The audit_binfile plugin creates binary audit files. Binary files comprise the audit trail, which is stored on audit file systems. The audit_remote plugin sends binary audit records to a remote repository. The audit_syslog plugin summarizes audit records and writes them to the system log using the syslog utility.
For more information, see Audit Plugin Modules and the module man pages, audit_binfile(5), audit_remote(5), and audit_syslog(5).
A set of auditing options that you can enable or disable at your site. You can specify policies such as the following:
Whether to record certain kinds of audit data
How much information to include in the audit content
How to handle certain types of files
How to handle a full audit queue
For more information, see Understanding Audit Policy and the auditconfig(1M) man page.
Audit data that is collected in the audit queue. An audit record describes a single audit event. Each audit record is composed of audit tokens.
For more information, see Audit Records and Audit Tokens and the audit.log(4) man page.
A field of an audit record. Each audit token describes an attribute of an audit record, such as a user, a group, a program, or other object.
For more information, see Audit Token Formats and the audit.log(4) man page.
A collection of one or more audit files that store the audit data from all audited systems that use the default plugin, audit_binfile.
For more information, see Audit Trail.
The collecting of audit records that are generated on the local system. The records can be generated in the global zone or in non-global zones, or both.
For more information, see Audit Plugin Modules.
The choice of which audit events to examine from the preselected audit trail. The default active plugin, audit_binfile, creates the audit trail. A post-selection tool, the auditreduce command, selects records from the audit trail.
For more information, see the auditreduce(1M) and praudit(1M) man pages.
The initial choice of which audit classes to monitor. The audit events of preselected audit classes are collected in the audit queue. Audit classes that are not preselected are not audited, so their events do not appear in the queue.
For more information, see Audit Classes and Preselection and the audit_flags(5) and auditconfig(1M) man pages.
A file that is owned by the root user and readable by the world. For example, some files in the /etc directory and the /usr/bin directory are public objects. Public objects are not audited for read-only events. For example, even if the file_read (fr) audit class is preselected, the reading of public objects is not audited. You can override the default by changing the public audit policy option.
The audit remote server (ARS) that receives and stores audit records from a system that is being audited and is configured with an active audit_remote plugin. To distinguish an audited system from an ARS, the audited system can be referred to as the "locally audited system."
For more information, see the –setremote option on the auditconfig(1M) man page, examples on the ars(5) man page, and Audit Remote Server.
Audit events represent auditable actions on a system. Audit events are listed in the /etc/security/audit_event file. Each audit event is connected to a system call or user command, and is assigned to one or more audit classes. For a description of the format of the audit_event file, see the audit_event(4) man page.
For example, the AUE_EXECVE audit event audits the execve() system call. The command auditrecord -e execve displays this entry:
# auditrecord -e execve execve system call execve See execve(2) event ID 23 AUE_EXECVE class ps,ex (0x0000000080100000) header path [attribute] omitted on error [exec_arguments] output if argv policy is set [exec_environment] output if arge policy is set subject [use_of_privilege] return
When you preselect either the audit class ps or the audit class ex, then every execve() system call is recorded in the audit queue.
Auditing handles attributable and non-attributable events. Audit policy divides events into synchronous and asynchronous events, as follows:
Attributable events – Events that can be attributed to a user. The execve() system call can be attributed to a user, so the call is considered an attributable event. All attributable events are synchronous events.
Non-attributable events – Events that occur at the kernel-interrupt level or before a user is authenticated. The na audit class handles audit events that are non-attributable. For example, booting the system is a non-attributable event. Most non-attributable events are asynchronous events. However, non-attributable events that have associated processes, such as a failed login, are synchronous events.
Synchronous events – Events that are associated with a process in the system. Synchronous events are the majority of system events. If synchronous events cannot be queued, the process is blocked until they can be queued.
Asynchronous events – Events that are not associated with any process, so no process is available to be blocked and later started. Initial system boot and PROM enter and exit events are examples of asynchronous events.
In addition to the audit events that are defined by the audit service, third-party applications can generate audit events. Audit event numbers from 32768 to 65535 are available for third-party applications. Vendors need to contact their Oracle Solaris representative to reserve event numbers and obtain access to the audit interfaces.
Each audit event belongs to an audit class. Audit classes are convenient containers for large numbers of audit events. When you preselect a class to be audited, all the events in that class are recorded in the audit queue. For example, when you preselect the ps audit class, execve(), fork(), and other system calls are recorded.
You can preselect for events on a system and for events initiated by a particular user.
System-wide preselection – Specify the system-wide defaults for auditing by using the –setflags and –setnaflags options to the auditconfig command.
User-specific preselection – Specify additional audit flags to audit for individual users to be included along with the system-wide auditing defaults. The useradd, roleadd, usermod, and rolemod commands place the audit_flags security attribute in the user_attr database. The profiles command places audit flags for rights profiles in the prof_attr database.
The audit preselection mask determines which classes of events are audited for a user. For a description of the user preselection mask, see Process Audit Characteristics. For the configured audit flags that are used, see Order of Search for Assigned Rights in Securing Users and Processes in Oracle Solaris 11.3.
Audit classes are defined in the /etc/security/audit_class file. Each entry contains the audit mask for the class, the name for the class, and a descriptive name for the class. For example, the lo and ps class definitions appear in the audit_class file as follows:
0x0000000000001000:lo:login or logout 0x0000000000100000:ps:process start/stop
The audit classes include the two global classes: all and no. The audit classes are described in the audit_class(4) man page. For the list of classes, read the /etc/security/audit_class file.
The mapping of audit events to classes is configurable. You can remove events from a class, add events to a class, and create a new class to contain selected events. For the procedure, see How to Change an Audit Event's Class Membership. To view the events that are mapped to a class, use the auditrecord -c class command.
Each audit record records the occurrence of a single audited event. The record includes information such as who did the action, which files were affected, what action was attempted, and where and when the action occurred. The following example shows a login audit record with three tokens, header, subject, and return:
header,69,2,login - local,,example_system,2010-10-10 10:10:20.020 -07:00 subject,jdoe,jdoe,staff,jdoe,staff,1210,4076076536,69 2 example_system return,success,0
The type of information that is saved for each audit event is defined by a set of audit tokens. Each time an audit record is created for an event, the record contains some or all of the tokens that are defined for the event. The nature of the event determines which tokens are recorded. In the preceding example, each line begins with the name of the audit token. The content of the audit token follows the token name. Together, the header, subject, and return audit tokens comprise the login - local audit record. To display the tokens that comprise an audit record, use the auditrecord -e event command.
For a detailed description of the structure of each audit token with an example of praudit output, see Audit Token Formats. For a description of the binary stream of audit tokens, see the audit.log(4) man page.
The audit plugin modules direct the audit records from the audit queue to a file or repository. At least one plugin must be active or ARS must be configured. By default, the audit_binfile plugin is active. You configure plugins with the auditconfig -setplugin plugin-name command.
The audit service provides the following plugins:
audit_binfile plugin – Handles delivery of the audit queue to the binary audit files. For more information, see the audit.log(4) man page.
audit_remote plugin – Handles secure delivery of binary audit records from the audit queue to a configured remote server. The audit_remote plugin uses the libgss() library to authenticate the server. The transmission is protected for privacy and integrity. For information about ARS, see Audit Remote Server.
audit_syslog plugin – Handles delivery of selected records from the audit queue to the syslog logs.
For information about how to configure a plugin, see the auditconfig(1M) man page. For examples of plugin configuration, see the tasks in Configuring Local Audit Logs. For information about the plugins, see the audit_binfile(5), audit_remote(5), and audit_syslog(5) man pages.
The audit remote server (ARS) is the counterpart of the audit_remote plugin. Data sent by the plugin can be captured, processed, and stored by ARS according to the server configuration.
ARS is delivered as a disabled audit component in Oracle Solaris systems. You must configure ARS before it can be used to process a remote audit trail. To configure ARS:
Configure the underlying security mechanisms used for secure audit data transport. See the audit_remote(5) man page.
Configure the audit remote subsystem using the auditconfig -setremote command. The configuration includes both server configuration and connection group configuration. A connection group is the sets of systems sharing the same local storage parameters. For information and examples, see the ars(5) man page and the auditconfig(1M) man page.
See also Audit Remote Server.
Audit records are collected in audit logs. The audit service provides three output modes for audit records.
Logs that are called audit files store audit records in binary format. The set of audit files from a system or site provides a complete audit record. The complete audit record is called the audit trail. These logs are created by the audit_binfile plugin or the Audit Remote Server, and can be reviewed by the praudit and auditreduce post-selection commands.
The audit_remote plugin streams audit records to a remote repository. The repository is responsible for maintaining an audit trail and supplying post-selection tools.
The syslog utility collects and stores text summaries of the audit record. A syslog record is not complete. The following example shows a syslog entry for a login audit record:
Feb 5 11:54:57 example_system audit: [ID 702911 audit.notice] \ login - login ok session 2870512630 by user as user:staff
A site can configure auditing to collect audit records in all formats. You can configure the systems at your site to use binary mode locally, to send binary files to a remote repository, and to use syslog mode. The following table compares binary audit records with syslog audit records.
|
For more information about plugins and audit logs, refer to the following:
ars(5), audit_binfile(5), audit.log(4), and audit_syslog(5) man pages
Binary records provide the greatest security and coverage. Binary output meets the requirements of security certifications, such as the Common Criteria (https://www.commoncriteriaportal.org/) audit requirements.
The audit_binfile plugin writes the records to a file system that you protect from snooping. On a single system, all binary records are collected and displayed in order. The UTC time stamp on binary logs enables accurate comparison when systems on one audit trail are distributed across time zones. The praudit command enables you to view the records in a browser in XML. You can also use scripts to parse the XML output.
The audit_remote plugin writes the records to a remote repository. The repository handles storage and post-selection.
The audit remote server also yields binary.
In contrast, the syslog or rsyslog records might provide greater convenience and flexibility. For example, you can collect the syslog data from a variety of sources. Also, when you monitor audit.notice events in the syslog.conf file, the syslog utility logs an audit record summary with the current time stamp. You can use the same management and analysis tools that you have developed for syslog messages from a variety of sources, including workstations, network servers, firewalls, and routers. The records can be viewed in real time, and can be stored on a remote system.
By using syslog.conf to store audit records remotely, you protect log data from alteration or deletion by an attacker. However, consider the following drawbacks to the syslog mode.
The records are susceptible to network attacks such as denial of service and spoofed source addresses.
The UDP protocol can drop packets or can deliver packets out of order.
The 1024 character limit for syslog entries can cause some audit records to be truncated in the log.
On a single system, not all audit records are collected, and might not be displayed in order.
Each audit record is stamped with the local system's date and time. Thus, you cannot rely on the time stamp to construct an audit trail for several systems.
When the audit_binfile plugin is active, an audit file system holds audit files in binary format. A typical installation uses /var/audit and can use additional file systems. The contents of all audit file systems comprise the audit trail. Audit records are stored in these file systems in the following order:
Primary audit file system– /var/audit functions as the default file system for audit files for a system
Secondary audit file systems – File systems where the audit files for a system are placed at administrator discretion
The file systems are specified as arguments to the p_dir attribute of the audit_binfile plugin. A file system is not used until a file system that is earlier in the list is full. For an example with a list of file system entries, see How to Create ZFS File Systems for Audit Files.
Placing the audit files in the default audit root directory assists the audit reviewer when reviewing the audit trail. The auditreduce command uses the audit root directory to find all files in the audit trail. The /var/audit functions as the default audit root directory.
You can use the following options with the auditreduce command:
The –M option to the auditreduce command can be used to specify the audit files from a specific physical machine.
The –S option can be used to specify a different audit file system.
For examples of the use of the auditreduce command, see How to Merge Audit Files From the Audit Trail. For more information, see the auditreduce(1M) man page.
The audit service provides commands to combine and filter files from the audit trail. The auditreduce command can merge audit files from the audit trail. The command can also filter files to locate particular events. The praudit command reads the binary files. Options to the praudit command provide output that is suitable for scripting and for browser display.
When you merge audit logs from several systems, the date and time on those systems must be accurate. Similarly, when you send audit logs to a remote system, the recording system and the repository system must have accurate clocks. The Network Time Protocol (NTP) keeps system clocks accurate and coordinated. For more information, see Chapter 3, Time-Related Services in Introduction to Oracle Solaris 11.2 Network Services and the ntpd(1m) man page.
After the audit_remote plugin is configured, a remote repository receives the audit records. The ARS provides a receiver for audit records. The audit records stream to the ARS over a protected connection and can be stored similarly to how they are stored locally. To configure an ARS, see How to Configure a Remote Repository for Audit Files. For a description of the ARS, see Audit Remote Server and the ars(5) man page.