auditd

- audit service daemon

Synopsis

/usr/sbin/auditd 

Description

The audit service daemon, auditd, manages audit data generated either locally (see audit_binfile(5), audit_syslog(5) and audit_remote(5)) or remotely (see “Audit Remote Server” below). When auditing is enabled, auditd reads its configuration to do the following:

• Configure audit policy.

• Configure the audit queue control parameters.

• Configure the event-to-class mappings.

• Set the default audit masks.

• If local auditing is enabled (see “Local Auditing” below), load one or more plugins.

  Solaris provides three plugins. audit_binfile(5) writes binary audit data to a file. audit_remote(5) sends binary audit data to an authenticated server with privacy and integrity protection. audit_syslog(5) sends text summaries of audit records to the syslog daemon.

• Read audit data from the kernel and pass that data to each of the active plugins.

• Execute the audit_warn(1M) script to warn of various conditions.

• If remote auditing (ars(5)) is enabled, process requests and store the remotely generated audit data.

audit(1M) is used to control the audit service. It can cause auditd to:

• Close a connection to a remote audit server thus causing it to close its respective audit file.

• Start and refresh the service based on the current properties.

• Close the audit trail and disable local auditing and remote audit service.

auditconfig(1M) is used to configure the audit service. It can configure the active and permanent:

• audit policy

• audit queue control parameters

• default audit masks

• plugins to be loaded

• plugin attributes

• audit remote server state, attributes, and connection groups

Local Auditing

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.

Remote Auditing

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 termed the locally audited system.

Auditing Conditions

The audit service daemon enables local auditing in case at least one audit daemon plugin is configured as active.

The Audit Remote Server functionality is enabled, if the server is not configured as inactive (see the -setremote server option in auditconfig(1M)) and at least one connection group is active. See Audit Remote Server section for more information.

Local auditing and the Audit Remote Server can be configured independently.

Audit Remote Server

The Audit Remote Server, ARS, is an integral part of auditd. It makes a counterpart to the audit_remote(5) plugin. Data sent by the plugin can be captured, processed, and stored by the server according to its configuration.

ARS is delivered as a disabled Solaris audit component. It is necessary to configure it before it can be used to process a remote audit trail. ARS configuration is twofold: first, the underlying security mechanisms used for secure audit data transport has to be configured (see audit_remote(5)); second, the audit subsystem has to be properly configured.

To observe and configure the ARS, use the auditconfig(1M) -setremote and -getremote options. The configuration is divided to the configuration of server and group. The server configuration allows for changing common ARS parameters, while the group keyword allows configuration of connection groups, the sets of hosts sharing the same local storage parameters.

listen_address

Address the server listens on. Empty listen_address attribute defaults to listen on all local addresses.

listen_port

The local listening port; 0 defaults to 16162. Port associated with the solaris-audit Internet service name. See services(4).

login_grace_time

The server disconnects after login grace time (in seconds) if the connection has not been successfully established. 0 defaults to no limit.

max_startups

Number of concurrent unauthenticated connections to the server at which the server starts refusing new connections. Note that the value might be specified in begin:rate:full format to allow random early drop mode, for example 10:30:60. That means that ARS would refuse connection attempts with a probability of rate/100 (30% in our example) if there are currently 10 (from the start field) unauthenticated connections. The probability increases linearly and all connection attempts are refused if the number of unauthenticated connections reaches full (60 in our example).

binfile_dir, binfile_fsize, binfile_minfree

Attributes follow the respective p_* attributes defined in audit_binfile(5), in short:

binfile_dir

Directory for storing per host audit data.

binfile_fsize

The maximum size of each of the stored audit trail files; 0 defaults to no limit.

binfile_minfree

The minimum free space on file system with binfile_dir before the audit_binfile(5) lets administrator know by means of audit_warn(1M); 0 defaults to no limit.

hosts

Defines the hosts in the given connection group allowed to send audit data to server. Note that a comma is a delimiter in case of multiple host entries. If hosts is empty, such connection group is called a wild card connection group. If a new connection cannot be classified to any other (non-wild card) connection group and there is an active wild card connection group configured, the new connection is classified to that connection group. Only one active wild card connection group can be configured.

For a configuration example, see “Examples”.

For comprehensive configuration description and examples, see the appropriate chapter in the Oracle Solaris 11.1 Administration: Security Services.

Audit Record Queue

The maximum number of records to queue for audit data sent to the plugin is specified by the qsize parameter specified for the plugin. If omitted, the current hiwater mark is used. See the -getqctrl option in auditconfig(1M). When this maximum is reached, auditd will either block processes or discard data, depending on the cnt audit policy as described in auditconfig(1M).

Auditing System Warnings

The audit service daemon and audit plugins invoke the script audit_warn(1M) under certain conditions. See audit_warn(1M) for more information.

Examples

Example 1 Audit Remote Server Configuration

The following example describes steps to configure audit remote server to listen on a specific address. One wild card and one non-wild card connection group will be created. The non-wild card connection group configuration will address remote audit data from tic.cz.example.com and tac.us.example.com. The trail will be stored in /var/audit/remote.

# Print the current audit remote server configuration.
# Both server and connection groups (if any) is displayed.

# auditconfig -getremote

# Set address the audit remote server will listen on.

# auditconfig -setremote server "listen_address=192.168.0.1"

# Create two connection groups. Note that by default the
# connection group is created with no hosts specified
# (wild card connection group).

# auditconfig -setremote group create clockhouse
# auditconfig -setremote group create sink

# Add hosts to the connection group (convert the wild card
# connection group no non-wild card one). Set the storage
# directory and activate the connection group.

# auditconfig -setremote group active clockhouse \
# "hosts=tic.cz.example.com,tac.us.example.com,\
# binfile_dir=/var/audit/remote"

# Activate the wild card connection group.

# auditconfig -setremote group active sink

# Verify the audit remote server configuration.

# auditconfig -getremote

# Start or refresh the audit service.

# audit -s

Files

• etc/security/audit/audit_class

• etc/security/audit/audit_event

Attributes

See attributes(5) for descriptions of the following attributes:

See Also

audit(1M), audit_warn(1M), auditconfig(1M), praudit(1M), audit_class(4), audit_class(4), audit_event(4), services(4), ars(5), attributes(5), audit_binfile(5), audit_flags(5), audit_remote(5), audit_syslog(5), smf(5)

See the section on Auditing in Oracle Solaris 11.1 Administration: Security Services.

Notes

auditd is loaded in the global zone at boot time if auditing is enabled.

If the audit policy perzone is set, auditd runs in each zone, starting automatically when the local zone boots. If a zone is running when the perzone policy is set, auditing must be started manually in local zones. It is not necessary to reboot the system or the local zone to start auditing in a local zone. auditd can be started with audit -s and will start automatically with future boots of the zone.

When auditd runs in a local zone, the configuration is taken from the local zone's smf(5) repository and the /etc/security directory's files: audit_class, user_attr, and audit_event.

Configuration changes do not affect audit sessions that are currently running, as the changes do not modify a process's preselection mask. To change the preselection mask on a running process, use the –setpmask option of the auditconfig command (see auditconfig(1M)). If the user logs out and logs back in, the new configuration changes will be reflected in the next audit session.

The audit service FMRI is svc:/system/auditd:default.