audit_syslog man page on SmartOS

Printed from http://www.polarhome.com/service/man/?qf=audit_syslog&af=0&tf=2&of=SmartOS

AUDIT_SYSLOG(5)						       AUDIT_SYSLOG(5)

NAME
       audit_syslog - realtime conversion of Solaris audit data to syslog mes‐
       sages

SYNOPSIS
       /usr/lib/security/audit_syslog.so

DESCRIPTION
       The  audit_syslog  plugin  module  for  Solaris	audit,	/usr/lib/secu‐
       rity/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 mes‐
       sage.

       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 indicated 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  rep‐
       resents	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 are generated.

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 │ See below.      │
       └────────────────────┴─────────────────┘

       The  message format and message content are Uncommitted. The configura‐
       tion parameters are Committed.

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

       System Administration Guide: Security Services

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.

				 Sep 25, 2008		       AUDIT_SYSLOG(5)
[top]

List of man pages available for SmartOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net