audit_syslog(5) 					Standards, Environments, and Macros					   audit_syslog(5)

NAME

       audit_syslog - realtime conversion of Solaris audit data to syslog messages

SYNOPSIS

       /usr/lib/security/audit_syslog.so

DESCRIPTION

       The  audit_syslog plugin module for Solaris audit, /usr/lib/security/audit_syslog.so, provides realtime conversion 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, audit_control(4).

       Messages  to syslog are written if selected via the plugin option in audit_control. Syslog messages are generated with the facility code of
       LOG_AUDIT (audit in syslog.conf(4)) and severity of LOG_NOTICE. 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 indicating 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 messages 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. Following this field is additional data, described below. This data is omitted if	it
       is not contained in the source audit record.

       ok or failed

	   Comes from the return or exit token.

       session <#>

	   <#> is the session ID from the subject token.

       by <name>

	   <name> is the audit ID from the subject token.

       as <name>:<group>

	   <name> is the effective user ID and <group> is the effective group ID from the subject token.

       in <zone name>

	   The zone name. This field is generated only if the zonename audit policy is set.

       from <terminal>

	   <terminal> is the text machine address from the subject token.

       obj <path>

	   <path>  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 indi-
	   cated by leading ellipsis (...).

       proc_uid <owner>

	   <owner> is the effective user ID of the process owner.

       proc_auid <owner>

	   <owner> 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] 
       access(2) ok session 255 by janeuser as janeuser:staff from 129.146.89.30 
       obj /etc/passwd

OBJECT ATTRIBUTES

       The p_flag attribute, specified by means of the plugin directive (see audit_control(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 audit_control and through the user-specific lines of
       audit_user(4). The parameter is a comma-separated list; each item represents an audit class (see audit_class(4)) and is specified using the
       same  syntax used in audit_control for the flags and naflags lines. The default (no p_flags listed) is that no audit records will be gener-
       ated.

EXAMPLES

       Example 1: One Use of the plugin Line

       In the specification shown below, the plugin line (in conjunction 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 audit_user(4). You can only remove them.

       flags: lo,am,fm
       naflags: lo
       plugin: name=audit_syslog.so; p_flags=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  audit_user(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=audit_syslog.so; p_flags=all,^+ss,^+as

ATTRIBUTES

       See attributes(5) for a description of the following attributes:

       +-----------------------------+-----------------------------+
       |      ATTRIBUTE TYPE	     |	    ATTRIBUTE VALUE	   |
       +-----------------------------+-----------------------------+
       |MT Level		     |MT-Safe			   |
       +-----------------------------+-----------------------------+
       |Interface Stability	     |: 			   |
       +-----------------------------+-----------------------------+
       | message format 	     |Unstable			   |
       +-----------------------------+-----------------------------+
       | message content	     |Unstable			   |
       +-----------------------------+-----------------------------+
       | config parameters	     |Evolving			   |
       +-----------------------------+-----------------------------+

SEE ALSO

       auditd(1M), audit_class(4), audit_control(4), syslog.conf(4), attributes(5)

NOTES

       Use of the plugin configuration line to include audit_syslog.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 LOG_DAEMON 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.10							    26 Aug 2004 						   audit_syslog(5)