Hello all,
I'm working on transitioning of auditd(1M) configuration into SMF. While
configuration directives like audit policy, masks etc. would map to SMF
properties in a quite straightforward way, I'm not sure how to map more complex
configuration related to audit plugins.
Problem:
- auditd can load various plugins (they are .so objects loaded at runtime via
dlopen) based on its configuration
- each plugin has different configuration directives in general
- plugin should not depend on smf (ie. should not be smf-aware code, its
configuration is supplied on the plugin initialization by auditd)
Proposal:
- smf docs mentions <property_group> tags which seem to me the best approach
how to group each plugin configuration into a logical group. Below is a
sample of smf manifest.
- each plugin has its own property group of type 'SUNW,audit_plugin'. auditd
will iterate over all property groups of type containing audit_plugin
(allowing possible 3rd party plugins to be used as well).
- each plugin property group will have known properties recognized by auditd,
like name (for library path), enabled (if this plugin should be loaded at
all) and attributes, ie. configuration depending on the plugin of type
string list
My questions:
- is it right to use <property_group>s for this purpose?
- is type='SUNW,audit_plugin' correct?
- wouldn't it be better to drop plugin's 'attributes' list in favor of
several plugin specific attributes with names beginning with eg. p_ to be
recognizable by auditd and passed to a plugin upon initialization?
Note the plugin configuration is sensitive and should be readable only for
solaris.audit.config authorization.
Thanks for help,
--
Tomas
