Quoth Tomas Zeman on Wed, Jul 25, 2007 at 01:49:20PM +0200: > 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.
Yes, property groups seem appropriate. > - 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). We allow arbitrary property group types, but I'm not sure that we should use them. I believe the design originally intended service-specific property groups to have type "application", which is why there is a solaris.smf.modify.application authorization (see smf_security(5)). As for the SUNW qualifier, I don't understand how that's useful in the type. Would another vendor use "XYZ,audit_plugin"? It seems like you're defining the type, and he should want to use whatever you defined. That is, we want to reuse types, rather than avoid name conflicts. For the property group name, on the other hand, we would want to avoid name conflicts between vendors, so the organization qualifier might be justified there. Can you elaborate on how the property groups would be named? > - 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? I think so. Do you know of a reason it wouldn't be? Quoth Gary Winiger on Wed, Jul 25, 2007 at 04:19:29PM -0700: > <property_group name='binfile' type='SUNW,audit_plugin'> > <property name='audit_binfile.so' type='astring' override='true'/> Is "audit_binfile.so" the filename? I would expect that to be the value of a property like "name". Why isn't it? Would all the values on this property be ignored? > <property name='attributes' type='astring' override='true'> > <astring_list> > <value_node value='p_minfree=20'/> > <value_node > value='p_dir=/var/audit,/var1/audit,/var2/audit'/> > </astring_list> > </property> Yes, I think it would be easier for generic configuration tools if each of these attributes were a separate property. If the value lists are expected to retain order, then that may need to be delt with specially. > <property name='enabled' type='boolean' override='true'> > <boolean_list> > <value_node value='true'/> > </boolean_list> > </property> Might as well use propval for this, eh? David
