Standards, Environments, and Macros auditsyslog(5)
NAME
auditsyslog - realtime conversion of Solaris audit data to
syslog messages
SYNOPSIS
/usr/lib/security/auditsyslog.so
DESCRIPTION
The auditsyslog plugin module for Solaris audit,
/usr/lib/security/auditsyslog.so, provides realtime conver-
sion of Solaris audit data to syslog-formatted (text) data
and sends it to a syslog daemon as configured in
syslog.conf(4). The plugin's path is specified in the audit
configuration file, auditcontrol(4).
Messages to syslog are written if selected via the plugin
option in auditcontrol. Syslog messages are generated with
the facility code of LOGAUDIT (audit in syslog.conf(4)) and
severity of LOGNOTICE. Audit syslog messages contain data
selected from the tokens described for the binary audit log.
(See audit.log(4)). As with all syslog messages, each line
in a syslog file consists of two parts, a syslog header and
a message.
The syslog header contains the date and time the message was
generated, the host name from which it was sent, auditd to
indicate that it was generated by the audit daemon, an ID
field used internally by syslogd, and audit.notice indicat-
ing the syslog facility and severity values. The syslog
header ends with the characters ], that is, a closing square
bracket and a space.
The message part starts with the event type from the header
token. All subsequent data appears only if contained in the
original audit record and there is room in the 1024-byte
maximum length syslog line. In the following example, the
backslash (\) indicates a continuation; actual syslog mes-
sages are contained on one line:
Oct 31 11:38:08 smothers auditd: [ID 917521 audit.notice] chdir(2) ok\
session 401 by joeuser as root:other from myultra obj /export/home
In the preceding example, chdir(2) is the event type. Fol-
lowing this field is additional data, described below. This
data is omitted if it is not contained in the source audit
SunOS 5.11 Last change: 25 Sep 2008 1
Standards, Environments, and Macros auditsyslog(5)
record.
ok or failed Comes from the return or exit token.
session <#> <#> is the session ID from the subject
token.
by is the audit ID from the subject
token.
as : is the effective user ID and
is the effective group ID from
the subject token.
in The zone name. This field is generated
only if the zonename audit policy is
set.
from is the text machine address
from the subject token.
obj is the path from the path token
The path can be truncated from the left
if necessary to fit it on the line.
Truncation is indicated by leading
ellipsis (...).
procuid is the effective user ID of the
process owner.
procauid is the audit ID of the process
owner.
The following are example syslog messages:
Nov 4 8:27:07 smothers auditd: [ID 175219 audit.notice] \
system booted
Nov 4 9:28:17 smothers auditd: [ID 752191 audit.notice] \
login - rlogin ok session 401 by joeuser as joeuser:staff from myultra
Nov 4 10:29:27 smothers auditd: [ID 521917 audit.notice] \
SunOS 5.11 Last change: 25 Sep 2008 2
Standards, Environments, and Macros auditsyslog(5)
access(2) ok session 255 by janeuser as janeuser:staff from \
129.146.89.30 obj /etc/passwd
OBJECT ATRIBUTES
The pflag attribute, specified by means of the plugin
directive (see auditcontrol(4)), is used to further filter
audit data being sent to the syslog daemon beyond the
classes specified through the flags and naflags lines of
auditcontrol and through the user-specific lines of
audituser(4). The parameter is a comma-separated list; each
item represents an audit class (see auditclass(4)) and is
specified using the same syntax used in auditcontrol for
the flags and naflags lines. The default (no pflags listed)
is that no audit records are generated.
EXAMPLES
Example 1 One Use of the plugin Line
In the specification shown below, the plugin line (in con-
junction with flags and naflags) is used to allow class
records for lo but allows class records for am for failures
only. Omission of the fm class records results in no fm
class records being output. The pc parameter has no effect
because you cannot add classes to those defined by means of
flags and naflags and by audituser(4). You can only remove
them.
flags: lo,am,fm
naflags: lo
plugin: name=auditsyslog.so; pflags=lo,-am
Example 2 Use of all
In the specification shown below, with one exception, all
allows all flags defined by means of flags and naflags (and
audituser(4)). The exception the am metaclass, which is
equivalent to ss,as,ua, which is modified to output all ua
events but only failure events for ss and as.
flags: lo,am
naflags: lo
plugin: name=auditsyslog.so; pflags=all,^]ss,^]as
SunOS 5.11 Last change: 25 Sep 2008 3
Standards, Environments, and Macros auditsyslog(5)
ATRIBUTES
See attributes(5) for a description of the following attri-
butes:
ATRIBUTE TYPE ATRIBUTE VALUE
MT Level MT-Safe
Interface Stability See below.
The message format and message content are Uncommitted. The
configuration parameters are Committed.
SEE ALSO
auditd(1M), auditclass(4), auditcontrol(4),
syslog.conf(4), attributes(5)
System Administration Guide: Security Services
NOTES
Use of the plugin configuration line to include
auditsyslog.so requires that /etc/syslog.conf is configured
to store syslog messages of facility audit and severity
notice or above in a file intended for Solaris audit
records. An example of such a line in syslog.conf is:
audit.notice /var/audit/audit.log
Messages from syslog are sent to remote syslog servers by
means of UDP, which does not guarantee delivery or ensure
the correct order of arrival of messages.
If the parameters specified for the plugin line result in no
classes being preselected, an error is reported by means of
a syslog alert with the LOGDAEMON facility code.
The time field in the syslog header is generated by
syslog(3C) and only approximates the time given in the
binary audit log. Normally the time field shows the same
whole second or at most a few seconds difference.
SunOS 5.11 Last change: 25 Sep 2008 4
|
