Paul Roberts' Musings

Friday July 11, 2008

Limiting the size of the auditing log

Versions of Solaris up to and including Solaris 9 provide a nice feature within the auditing subsystem by which an upper limit can be defined for the size of the auditing log. Once this is reached the auditing log is automatically closed and a new log is opened in its place. This upper limit is set (and read) via the auditconfig(1M) command:

SYNOPSIS

auditconfig option...

[...]

-setfsize size

Set the maximum size of an audit file to size bytes. When the size limit is reached, the audit file is closed and another is started. If perzone is not set, this option is valid only in the global zone.

While still documented, this functionality, however, does not work correctly in Solaris 10 and beyond.

In Solaris 9, the actual writing of all of the auditing data to disk was handled by the kernel, with the job of the userland auditd(1M) deamon being only to perform the initial setup of the auditing log and then hand everything over to the kernel (basically by calling auditsvc(2)) and then waiting until the kernel reported that something had gone wrong. As a result of this, the implementation of the upper limit for the auditing log (in other words, the code that stopped writing data once a certain amount of it had been written) was implemented in the kernel, and the interface for making use of it was provided via a system call (and the auditconfig command mentioned above makes use of the system call).

In Solaris 10 things changed significantly. A new project was initiated to alter the auditing subsystem so that instead of just writing auditing data to a binary file on disk, a plugin architecture was produced which would allow new output methods for the logging of the auditing data to be created, and then for these to be freely configured for use on site (and even allows different plugins to act on the same auditing data together). It makes sense for these plugins to run in userland (rather than requiring them to be kernel modules or something similar, as this would limit the usefulness of the plugins and put an extra burden on the people creating them). So the auditing subsystem was split into two across the kernel to userland boundary. Rather than just dispatching the writing of the auditing data to the kernel and then going away, as occurred previously, the auditd daemon now registers a door server with the kernel and stays awake. As the kernel generates auditing data it passes the data back down into userland to the running auditd daemon via the door server, where auditd then takes over the responsibility of recording the auditing data by passing it to the available plugins which in turn handle actually recording the data using whatever method they are intended to implement.

The default plugin, audit_binfile(5) just recreates the previous behaviour of writing the log to a binary file. As a further example, the new plugin audit_syslog(5), writes the data to the system log instead (where you can configure it via the usual syslog.conf(4) method).

All of this means, however, that the kernel code which previously handled the auditing file size limit, was no longer applicable, because the auditing data was no longer written within the kernel. Furthermore, the whole concept of a file size limit is specific to the process of writing data to disk, and therefore doesn't match the new generic paradigm where the auditing subystem no longer knows what happens to the auditing data once it is passed to the plugins. As a result, setting the kernel-based file size limit using the traditional '-setfsize' auditconfig command had no affect, and no alternative userland implementation had been created to replace it.

I have recently been working on a project to rectify that last problem, and the fruits of that project were integrated into OpenSolaris build 91 (see here for diffs). As the actual writing of the auditing data to disk now occurs within the audit_binfile(5) plugin, this change creates a new parameter associated with that plugin, called p_fsize, which when set will produce the same functionality as was previously available via the '-setfsize' command, namely it will close the audit log when a certain limit is reached and open a new one. This parameter can be set within the audit_control(4) file in the normal way, for example:

plugin: name=audit_binfile.so.1;p_fsize=512000

which will set the filesize limit to 512,000 bytes. Here's a quote from the updated OpenSolaris audit_binfile(5) man page which describes this feature:

The p_fsize attribute defines the maximum size in bytes that an audit file can become before it is automatically closed and a new audit file opened. This is equivalent to an administrator issuing an audit -n command when the audit file contains the specified number of bytes. The default size is zero (0), which allows the file to grow without bound. The value specified must be within the range of [512,000, 2,147,483,647].

Update: This fix is now available in Solaris 10 as of 10/08, and is documented in the corresponding man pages. It is also available in patches 138085-01 (SPARC) and 138086-01 (x86).