On Thu, Aug 02, 2007 at 04:51:04PM -0700, David Bustos wrote:
>
> > - 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?
You're right.
Design doc for smf (Greenline[1]) mentions property group names to be
[provider],name.
What I want to achieve:
- ability to have several plugins which can be easily distinguished and
enabled/disabled.
- plugins can be implemented by 3rd party so we need to avoid name conflicts.
- auditd does not know all possible plugin implementation so it has to find
easily which property group describes a plugin and which properties are
plugin specific
Maybe we can use something like:
<property_group name='SUNW,audit_plugin' type='application'>
<propval name='binfile' type='astring'/>
<propval file='audit_binfile.so' type='astring'/>
...
But then several property groups will have the same name.
>
> > - 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?
It is more or less matter of whether we prefer unification of plugin properties.
Some properties are common to all plugins, like 'name', 'enabled'. The rest,
plugin specific, could be all handled by 'attributes' property. But that to
rather obscure way of managing them via svccfg.
>
>
> 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?
>
Yeah.
Here is the relevant part of the proposed manifest:
<property_group name='config' type='application'>
<propval name='flags' type='astring' value='' />
<propval name='naflags' type='astring' value='lo' />
<propval name='policy' type='astring' value='+cnt' />
<propval name='read_authorization' type='astring'
value='solaris.audit.config' />
</property_group>
<property_group name='binfile' type='SUNW,audit_plugin'>
<propval name='name' type='astring' value='audit_binfile.so' />
<propval name='enabled' type='boolean' value='true' />
<propval name='p_minfree' type='count' value='20' />
<property name='p_dir' type='astring'>
<astring_list>
<value_node value='/var/audit'/>
</astring_list>
</property>
<propval name='read_authorization' type='astring'
value='solaris.audit.config' />
</property_group>
<property_group name='syslog' type='SUNW,audit_plugin'>
<propval name='name' type='astring' value='audit_syslog.so' />
<propval name='enabled' type='boolean' value='true' />
<propval name='p_flags' type='astring' value='all' />
<propval name='read_authorization' type='astring'
value='solaris.audit.config' />
</property_group>
<property_group name='remote' type='SUNW,audit_plugin'>
<propval name='name' type='astring' value='audit_remote.so' />
<propval name='enabled' type='boolean' value='true' />
<property name='p_hosts' type='astring'>
<astring_list>
<value_node value='audit-host1'/>
<value_node value='audit-host2'/>
</astring_list>
</property>
<propval name='p_retries' type='count' value='3' />
<propval name='p_timeout' type='count' value='5' />
<propval name='read_authorization' type='astring'
value='solaris.audit.config' />
</property_group>
-tomas
[1] http://sac.sfbay/PSARC/2002/547/commit.materials/design-document.pdf
