Secure Remote Audit Log Specification

1 Introduction

Overview

Consider an audited system A and log host system L. The primary goal of this project is to place the audit log of A beyond the reach of an attacker who may have compromised A either by exploiting a vulnerability or by betraying trust; data captured on L before A is compromised can only be altered or deleted by also compromising L. This goal is the source of the words "Secure Remote" in the project title.

The secondary goal of this project is to respond to customer requests that Solaris audit data be merged with syslog. This is in part due to customer requests to have central log facilities to collect syslog, firewall log, router log, and other log data and in part because of the need to play in heterogenous environments.

An architectural goal of the project is to implement the new functionality via a plugin API to provide for future format and transmission requirements and to provide a simpler interface for 3rd parties, such as IDS providers, who presently replace our auditd implementation with theirs. The translation of audit records for syslog use is a plugin to be delivered as part of this project. The present c2audit functionality for writing binary data to files is also moved to a plugin and delivered as part of this project.

The use of syslog to transport audit records meets both goals at the cost of communications reliability and security and at the cost of having to morph the audit data into the syslog message model. Since the resulting system does not meet security evaluation requirements for audit, this new capability will be an option; the current audit log storage capability will continue to be supported both as the default option and concurrently with the new syslog option.

The current Solaris audit log storage mechanism is inadequate for the following reasons:

An attacker with root access can delete one or more log files; use of NFS for a remote store doesn't solve this problem since an NFS server set up to allow write access from the compromised host doesn't distinguish between write and delete/truncate for access. A short discussion with the NFS group made it clear that providing an "append-only" NFS share mode is not the way to provide remote logging since it is special-purpose and since it does not play well with the design of existing NFS clients.

An attacker can, via a custom program or a binary editor, modify the log content either locally or via NFS. An easier attack is to simply insert (or overwrite) random data into the binary log; records are easily lost in the parsing process and the result chalked up to "error."

Background

auditd(1M) is controlled by the command audit(1M), which sends signals to close the current audit log file and open a new one, to re-read audit_control(4), and to shut down auditing. auditd exec's the script audit_warn(1M) to send alerts for various conditions such as being low on or out of file space.

auditd(1M) presently manages disk partitions based on /etc/security/audit_control configuration. Its basic operation is to read configuration and call auditsvc(2) with a file handle; this creates a thread from which the kernel module c2audit can write data. File full or nearly full (and other conditions requiring attention from auditd) are handled by a return from the auditsvc call with an appropriate errno.

The primary mechanism for alerting an operator of trouble is based on the script /etc/security/audit_warn, which is exec'd by auditd. Problems (including a full or nearly full partition) detected by the kernel module c2audit are handled via an error return code on the auditsvc system call; auditd alerts operators via the audit_warn script.

Customers are encouraged to define two or more partitions which are dedicated to audit logging. auditd uses the partitions in the order they are defined in the configuration file; it closes the log file when a partition's nearly full threshhold is reached and opens a new file in a less full partition. Each of these instances generates a warning via the audit_warn script. Subsequent to all partitions reaching their threshholds, logs are written to each partition in turn until it fills, with higher severity warnings being issued. When all partitions are full, the final warning is issued. Depending on customer-selected policy (auditconfig -setpolicy +cnt), audit records will be discarded or each audited process will block. The recovery from the blocked case depends on the customer defining a user who is not audited so that a log in can occur without the new process also blocking.

audit(1M)

audit(1M) controls auditd via signals; one signal which is generated for the audit option of "-s" causes auditd to re-read the audit_control file. Errors in editing audit_control can be difficult to recover from and can lead to lost audit data. With the new "plugin" line, audit_control becomes a bit longer and therefore more likely to contain errors. audit will now do a basic validation of audit_control before signalling auditd to re-read it.

---

auditd(1M)

Driven by new configuration statements in audit_control(4) and using new capabilities provided by auditsvc(2), auditd will continue to generate binary audit logs as described above. auditd can also be configured to generate syslog messages.

---

audit_control(4)

/etc/security/audit_control sets host-wide configuration for auditd. See the man page for the "dir:" entry which defines a directory to be used for creating and writing to log files. Normally this directory is a mount point for a dedicated partition; use of NFS is recommended.

A new configuration line ("plugin") is defined to provide the path of the library that implements conversion of audit records to syslog messages. It also defines parameters which can be used to reduce the output of audit records to syslog by listing audit classes to be excluded from output. See the updated audit_control man page for specifics. For consistency, the configuration of binary file output may optionally be defined using the new "plugin" specifier.

---

auditsvc(2)

An upward compatible interface change will be made for auditsvc()^[1] to check the file descriptor type and, if it is a door descriptor, act as a client to the referenced door server.

---

auditd plugin

See the man page "audit_plugin(3BSM)" in the commitment materials for a Service Provider Interface description for the use of the plugin facility. (The man page will not be delivered.) The description covers the use of /etc/security/audit_control to select a plugin library and the call interface the plugin must support. A new header file, /usr/include/bsm/auditd.h, defines the plugin interfaces.

---

audit_syslog.so.1

See the new man page "audit_syslog(5)" for a description of the supplied plugin. The description covers the use of /etc/security/audit_control to select this plugin. The Sun-provided plugin is /usr/lib/security/audit_syslog.so.1 and is referenced via the audit_control configuration line plugin as audit_syslog.so.1.

---

audit_binfile.so.1

See the new man page "audit_binfile(5)" for a description of the supplied plugin. The description covers the use of /etc/security/audit_control to select this plugin. The Sun-provided plugin is /usr/lib/security/audit_binfile.so.1 and is referenced via the audit_control configuration line plugin as audit_binfile.so.1.

---

References

Schedule and Deliverables: http://nishiki.eng/projects/audit/secureLog/schedule.html

Man pages: http://nishiki.eng/projects/audit/secureLog/man/

RFC 3164: The BSD syslog Protocol (http://www.ietf.org/rfc/rfc3164.txt) A copy is included with the PSARC commitment materials.

2 Requirements

In the two lists that follow, the use of UDP and the syslog protocol affect whether the listed requirements are met.

Key Requirements Which are Met

1. Compromise of the audited host shall not allow deletion or alteration of logged data prior to the compromise.
2. Compromise of the audited host shall not allow an attacker control of any administrative interfaces to the secure log service.
3. The log server shall be able to handle expected enterprise data volumes.
4. The secure log should exhibit at least the same client-side performance and server-side scalability as NFS with cacheing off^[2].
5. The secure log mechanism shall be usable in Trusted Solaris without modification and the log server shall be able to accept data from a mixture of Trusted Solaris and standard Solaris systems.

Security Requirements Which are Not Met

1. There shall be a mechanism to ensure the customer is aware of failures in the logging system. (Detectable failures are reported via audit_warn, but lost UDP messages are not detectable.)
2. An attacker cannot send bogus data to the server, e.g. Bob can't cause an audit record to be logged that says "Mary changed the root password".
3. Alterations to the log due to compromise of the server shall be detectable.
4. Every audit record generated shall be recorded; it shall be an option to discard records or block processes when the log partition fills.

3 Architecture

3.1 Model Conflict between Audit and Syslog

Two key characteristics distinguish the syslogd design and implementation from Solaris audit:

Audit is designed to capture every generated record and to block if it gets behind, while syslog discards data when busy explicitly in the syslogd client implementation and the /dev/log driver and implicitly via the use of UDP messages.

Syslog message generation is done by applications which are sending messages about events whose significance is usually clear from the application context, while audit records are generated in ignorance of context. Syslog messages self-explain their significance but audit messages gain significance only by interpretation either by a human reader or a pattern-matching system such as an IDS.

Another model conflict is that syslog messages convey a short message that describes a contextually significant event while audit records provide fine detail about who, with what privilege, did what to which object and with what result. One consequence is of this is that the audit records must be summarized for syslog use and certain audit record fields such as a path or other text may be truncated.

3.2 auditd / kernel

The Current auditd

The current auditd implementation manages data storage for Solaris audit and creates a kernel thread from which the kernel's audit queue module, c2audit, writes audit records; the daemon does no realtime processing or even copying of audit data.

The New auditd

auditd becomes a door server to c2audit to receive binary audit records from the audit queue and output via either or both plugins.

3.3 Syslog

Syslog Protocol

RFC 3164 describes the syslog protocol which was written as a discovery exercise to provide a basis for the work on Secure Syslog (RFC 3195). /etc/syslog.conf is used to determine whether a message is sent to the console, to a file, or to a remote syslogd. This choice is based on the "facility" and "severity" code at the beginning of the message.

The syslog RFC recognizes an "audit" facility code, assigned the value of 13, which is not used in Solaris. A new constant will be defined to associate LOG_AUDIT and the text "audit" with 13 for syslogd. (section 4.1.1 of the RFC. The severity code is be 5 (LOG_NOTICE), "Notice: normal but significant condition."

Syslog Protocol Extension

A syslog message as described in RFC3164 consists of a header and "message," which is freeform text. This project makes no extensions to the syslog record format.

The audit record representation in a syslog has a evolving format and an unstable content. A description of the syslog message content and format is given in the audit_syslog(5) man page supplied with the PSARC case materials.

3.4 syslogd

The Solaris syslogd is a multi-threaded process with threads for processing /dev/log input, UDP input, and file output. The input threads match routing configuration from syslog.conf with the facility and severity codes to determine which file or remote UDP service to write them to. No changes other than the new LOG_AUDIT facility code are required for the new audit messages.

4 Deliverables and Packaging

Deliverables

• Updated auditd.
• /usr/lib/security/audit_syslog.so.1
• /usr/include/security/auditd.h
• An updated kernel audit queue logic in c2audit to provide a door uplink to auditd.
• An updated man pages for audit, audit_control, auditconfig, syslog, binfile, audit_warn, audit.log, syslog.conf, and auditd.
• A short description of remote server use / configuration to be provided to pubs for inclusion in the Solaris audit section of the admin manual. This description includes an explanation of UDP reliability and security as requested by both ONSC and PSARC.
• Service Provider Interface description for the interface and use of the plugin facility.

Packaging

• The only planned change from the current build / package are the plugins used to write binary records to files and to translate binary records to syslog messages. They will be packaged with the existing Solaris audit files in SUNWcsu and will be installed to /usr/lib/security/audit_syslog.so.1 and /usr/lib/security/audit_binfile.so.1.

Footnotes:

¹ For no good reason, auditsvc was a public interface prior to Solaris 10. A separate fasttrack, PSARC 2002/665, has been approved to make this interface project private with announcement in an S9 update and removal of the man page in S10^[3]. The auditsvc system call is analogous to the private nfs_svc call.

² Because of the behavior of NFS when a partition becomes full, NFS mounts for audit logs are done with the option "noac" which disables client-side cacheing.

³ At least two commercial products replace auditd with their own daemon and use auditsvc as their interface to c2audit. The use of a plugin for data transformation and output is intended to allow these products to use auditd directly in their future versions. Since the door mechanism used in the new audit is more efficient than the pipe mechanism presently used by the third parties, they have a good reason to switch.