lianep at eng.sun.com writes:
>
> I've asked Tom Whitten (who wrote the configd audit code) to write up
> the current plan for his audit events and post them here so that we can
> reconcile his modification events with the plans for reading events.
>
> liane
> --
> Liane Praza, Solaris Kernel Development
> liane.praza at sun.com - http://blogs.sun.com/lianep
> _______________________________________________
> smf-discuss mailing list
> smf-discuss at opensolaris.org
Here is the current list of audit events. The code to generate all of
these events has been written and tested, but because of project priorities I
am not yet able to do the putback into the Nevada ON gate.
tom
------------------------------------------
SMF Auditing
In conjunction with PSARC case 2006/13, the Service
Management Facility (SMF) has code to generate audit events
whenever SMF performs administrative actions.
svc.configd(1M) is responsible for detecting when an
auditable action takes place and for generating the
appropriate audit events. This document describes the audit
events that are generated by svc.configd.
All events exccept AUE_smf_annotation contain two standard
pieces of data.
1. "auth_used" is the authorization (see auths(1)) that
enabled the administrative action. If the event is
documenting a rejected action, "auth_used" specifies
the authorization that is needed by the user to be
permitted to perform the action.
2. "FMRI" is the fault management resource identifier of
the service or service instance being affected by the
administrative action.
The discussion below will document any additional pieces of
information that are logged for specific audit events.
In addition to the SMF specific audit events, the auditing
framework, auditd(1M), records additional information such
as:
o time of event
o user id and process id of program generating the event
(for SMF this is the doors client of svc.configd)
o an audit session
The remainder of this document lists the SMF audit events.
Where applicable an example of a command that triggers the
event is given. Keep in mind that the command is just a
specific example, and that many of these events are
generated throughout the SMF framework or by the services
themselves. For example, "svccfg mark maintenance" is given
as an example that generates the AUE_smf_maintenance event.
svc.startd(1M) will also generate this event if it detects
that a service has gone into the maintenance state.
AUE_smf_enable -- persistently enable service instance:
This event is the result of a "svcadm enable" command. No
additional data is logged with this event.
AUE_smf_tmp_enable -- temporarily enable service instance:
This event is the result of a "svcadm enable -t" command.
No additional data is logged with this event.
AUE_smf_disable -- persistently disable service instance:
This event is the result of a "svcadm disable" command. No
additional data is logged with this event.
AUE_smf_tmp_disable -- temporarily disable service instance:
This event is the result of a "svcadm disable -t" command.
No additional data is logged with this event.
AUE_smf_restart -- restart service instance:
This event is the result of a "svcadm restart" command. No
additional data is logged with this event.
AUE_smf_refresh -- refresh service instance:
This event is the result of a "svcadm refresh" command. No
additional data is logged with this event.
AUE_smf_clear -- clear service instance state:
This event is the result of a "svcadm clear" command. No
additional data is logged with this event.
AUE_smf_degrade -- set service instance degraded state:
This event is the result of a "svcadm mark degraded"
command. No additional data is logged with this event.
AUE_smf_maintenance -- persistently set service instance
maintenance state:
This event is the result of a "svcadm mark maintenance"
command. No additional data is logged with this event.
Note, however, that SMF does not currently preserve the
maintenance state across reboots.
AUE_smf_tmp_maintenance -- temporarily set service instance
maintenance state:
This event is the result of a "svcadm mark -t maintenance"
command. No additional data is logged with this event.
Note, however, that svcadm does not currently send the -t
option to svc.configd. Therefore, AUE_smf_tmp_maintenance
events are not currently generated by SMF.
AUE_smf_milestone -- set service management facility
milestone:
This event is the result of a "svcadm milestone" command.
No additional data is logged with this event.
AUE_smf_create -- create service or service instance object:
This event is the result of a "svccfg create" command. The
FMRI data in the event is the FMRI of the service or service
instance being created. No additional data is logged with
this event.
AUE_smf_delete -- delete service or service instance object:
This event is the result of a "svccfg delete" command. The
FMRI data in the event is the FMRI of the service or service
instance being deleted. No additional data is logged with
this event.
AUE_smf_create_pg -- create persistent property group:
This event is the result of a "svccfg addpg" command with no
flags. The type of the property group is logged as
additional audit event data.
AUE_smf_create_npg -- create non-persistent property group:
This event is the result of a "svccfg addpg" command with
the P flag. The type of the property group is logged as
additional audit event data.
AUE_smf_delete_pg -- delete persistent property group:
This event is the result of a "svccfg delpg" command when
applied to a persistent property group. The type of the
property group is logged as additional audit event data.
AUE_smf_delete_npg -- delete non-persistent property group:
This event is the result of a "svccfg delpg" command when
applied to a non-persistent property group. The type of the
property group is logged as additional audit event data.
AUE_smf_create_snap -- create repository snapshot:
This event is generated when a snapshot is created.
Snapshots are created by the SMF framework, so there is no
example command for generating this event. The name of the
snapshot is logged as additional audit event data.
AUE_smf_delete_snap -- delete repository snapshot:
This event is generated when a snapshot is deleted.
Snapshots are deleted by the SMF framework, so there is no
example command for generating this event. The name of the
snapshot is logged as additional audit event data.
AUE_smf_attach_snap -- attach repository snapshot:
This event is done when one snapshot is attached to another.
Typically, this is done by svc.startd(1M) as part of the SMF
framework activities. Thus, there is no example command for
generating this event. This event logs the FMRIs of both
service instances as well as the names of both snapshots.
AUE_smf_create_prop -- create service or service instance
property:
This event is generated when a "svccfg setprop" command is
used to create a new property for a service or service
instance. Additional parameters that are logged are the
type and value of the new property.
AUE_smf_change_prop -- change service or service instance
property:
This event is generated when a "svccfg setprop" is used to
change the type or value of an existing property for a
service or service instance. Additional parameters that are
logged are the new type and value of the property.
AUE_smf_delete_prop -- delete service or service instance
property:
This event is generated when "svccfg delprop" is used to
delete a property of a service or service instance. No
additional data is logged with this event.
AUE_smf_annotation -- annotate transaction:
This event is unlike any of the others. It is used by
svccfg(1M) to place additional information in the audit log
when it is doing an import or apply operation.
Specifically, the two pieces of information are:
1. The operation -- "svccfg apply" or "svccfg import".
2. The name of the file that is being applied or
imported.
The AUE_smf_annotation event will appear in the log before
any of the transactions associated with the apply or import
operation. This the one SMF event that does not record the
auth_used or FMRI standard SMF event data. It merely
records the operation and the file name. The audit session
ID can be used to correlate the annotation data with other
events in the operation.
