> 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.
The top-level question to ask is whether plug-in configuration is (a) intended as tunables for administrators or (b) really only for developers or for the "I'm a Solaris OEM" level of customization. For example, for fmd(1M), I have a set of plug-ins, but the architecture is entirely oriented around (b). Therefore, for fmd, plug-in delivery and config is handled entirely outside SMF. If your answer is more (a), then property groups is likely the best approach because you have to control the plug-in namespace anyway, so you can just mirror that namespace in the property group layout. A second-order question is what is the nature of your configuration data. SMF works well at encapsulating relatively small amounts of relatively "flat" data, like a small set of integers, booleans, and strings. Alternatively, if your configuration data is something more like at 1200-line policy language input file, then for architectural reasons alone it will need to live outside of SMF, although in model (a) one could use SMF properties to store the URI of the location of the policy input file. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
