Audit Changes For Solaris 10

1 Introduction

PSARC 2002/150 is a Solaris 10 project that adds an option to select audit data for output to syslog.

This document is notes on should be added to the Administration manual chapter on Solaris audit to cover this new capability and as such is written as an explanation to the writer rather than to the customer. Some of the notes in this document are warnings to the user concerning the reliability and security of syslog for capturing logs; inclusion of these warnings in the manual is at the direction of the ON Steering Committee.

1.1 Overview

The current Solaris audit log is a binary format file that is intended to meet the requirements of security certifications such as specified in the Common Criteria Controlled Access Protection Profile (CAPP). As an alternative or companion to the binary audit log, one may choose to select from the binary audit data classes of audit records to be recorded via syslog(3C).

The generation of syslog data allows the customer to use the same management and analysis tools already used for syslog messages from a variety of Solaris and non-Solaris environments, including workstation, servers, firewalls, and routers. Besides providing a data stream in the form most used by customers, the use of syslog.conf to route messages to remote storage can protect log data from alteration or deletion by an attacker. On the other hand, the syslog option provides a summary of audit record data and (in the case of remote storage) is susceptible to network attacks such as denial of service and spoofed source addresses.

1.2 References

The following new or updated man pages, included in the PSARC commitment materials, provide specific configuration information as well as a description of the new syslog messages.

• audit
• audit_syslog
• audit_control
• audit_log
• auditd
• syslog
• syslog.conf

2 Configuration

Configuring Solaris audit to log audit data via syslog requires configuration of both audit and syslog. Audit configuration via audit_control(4) selects which audit records are output and syslog configuration via syslog.conf(4) routes audit data to the correct log host and file.

2.1 Configuring Solaris Audit

You may either replace binary audit log generation with syslog audit generation or add syslog generation to occur concurrently with binary log generation. (See Deciding which Log Mechanism to Use) You must, however, choose at least one of the two output modes.

As with preceding releases of Solaris auditing, the audit_user(4) database and the audit_control(4) directives "flags" and"naflags" are used to select which audit records are generated by the Solaris Operating Environment. The audit_user(4) database and the "flags" and "naflags" directives in audit_control(4) are required no matter what combination of output formats are selected. In the rest of these notes, the record selection I've just described is called "preselection."^[1]

The audit_control(4) "dir" directive lists the directories into which audit log files are written. To omit output to binary log files, omit the "dir" lines from audit_control(4).

To get syslog output, a new "plugin" directive is used; its format and use is described in audit_control(4) and in audit_syslog(5). Since it may not be desirable to send all audit records to a syslog log, audit_syslog(5) describes how to select from the preselected audit records to get only the most significant data.

The audit "cnt" policy, set with "auditconfig -setpolicy +cnt" and cleared with "auditconfig -setpolicy -cnt" applies to syslog output as well as binary log output. If "-cnt" is set and binary and syslog output are both configured, if either data stream becomes stuck (file full, for example), both data streams are blocked. If "+cnt" is set and binary and syslog output are both configured, if the file data stream becomes stuck, syslog output will continue.

Notes

You may notice that we've introduced the concept of a plugin library to auditing. The API for the plugin is not public and shouldn't be mentioned or even hinted at in this write up. However the new plugin line in audit_control offers a new way of specifying audit directories and the minfree command. While the current "dir:" and "minfree:" lines are still supported, the new plugin syntax should be used in any new or updated documentation since we expect to obsolete the "dir:" and "minfree:" lines in a future release.

The auditconfig(1M) command audit tuning option -get/setqhiwater applies to syslog output as well as binary log output; it is the default queue size for each plugin and may be overridden with the "qsize" option in audit_control(4).

Since UDP messages are not acknowledged, the flow of data via syslog is unlikely to become stuck; only the file data stream is likely to cause blocking due to either full partitiions or loss of NFS communications.

2.2 Configurating Syslog

The Syslog configuration file, syslog.conf(4), allows a customer to select which syslog messages to discard, which to put into which log file, and which to route to another host. A new syslog "facility," "audit" has been added to Solaris syslog in conformance with the IETF standard. The default syslog.conf(4) will neither route nor store audit syslog messages. Here is an example of a syslog.conf(4) line which routes audit messages to a remote host:

 	audit.*				@central.corp.com 
     

And an example of how to configure syslog.conf(4) on the remote host.

 	audit.*				/var/adm/audit 
     

Syslog logs may be managed via logadm(1M), typically via cron(1M). Here's an example of a logadm command to rotate daily an audit log named "audit" without deletion of old files:

logadm -w audit /var/audit/audit -s 1b -p 1d -C 0 -z 1 -S 20m -a 'kill -HUP `cat /var/run/syslog.pid`'

3 Deciding which Log Mechanism to Use

You may either replace binary audit log generation with syslog audit generation or configure syslog generation to occur concurrently with binary log generation. Depending on the customer need, any of the three combinations makes sense. The following list describes the key considerations.

• Binary audit log output is highly reliable even at high data rates.
• The availability of tools for managing and analysing syslog files exceeds that of tools for binary audit logs.
• Syslog is supported by many non-Solaris platforms.
• Syslog UDP communications can be unreliable depending on network load.
• UDP delivery does not guarantee that messages are received in the order they are sent.
• Implementations of syslogd vary in their ability to handle high message loads. The Solaris implementation of syslogd has been tuned to handle high volume input; the most current version of syslogd should be used.
• The syslog protocol can be spoofed to introduce phony messages and UDP is susceptible to attack by a denial of service flood of data.
• Syslog messages are limited to 1024 bytes, including the header. To accomodate this, not all data from each audit record is written to syslog. Even with this sumarization, some records can exceed 1024 bytes; the resulting syslog message is truncated to fit. The key audit data from each record is written first, with file paths and arbitrary text most likely to be truncated.
• The content of the syslog messages is unstable and may change from release to release and even within patches.

Both the spoofing and denial of service attacks mentioned above can be addressed by the use of IPSec between the audited computer and the remote log server.

Notes

The possibility of truncation of data is highly dependent on system configuration. The most like case of a too-long syslog message is the use of path names that exceed 900 bytes.

The most recent version of syslogd is available via a patch for each release; the same syslogd implementation covers all Solaris releases starting with SunOS 5.6. The current syslogd is found in the /usr/sbin/syslogd patch for each release except for Solaris 7 for which syslogd is found in the kernel update patch.

Footnotes:

¹ The term "preselection" describes the choice of which audit records to generate; it is in contrast with "postselection," which is filtering done by the auditreduce(1M) command or possibly by third party analysis tools.