Re: [PATCH ghak124 v3] audit: log nftables configuration change events

[Richard Guy Briggs <rgb@redhat.com>]

On 2021-02-18 09:22, Florian Westphal wrote:
> Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 2021-02-11 23:09, Florian Westphal wrote:
> > > So, if just a summary is needed a single audit_log_nfcfg()
> > > after 'step 3' and outside of the list_for_each_entry_safe() is all
> > > that is needed.
> > 
> > Ok, so it should not matter if it is before or after that
> > list_for_each_entry_safe(), which could be used to collect that summary.
> 
> Right, it won't matter.
> 
> > > If a summary is wanted as well one could fe. count the number of
> > > transaction types in the batch, e.g. table adds, chain adds, rule
> > > adds etc. and then log a summary count instead.
> > 
> > The current fields are "table", "family", "entries", "op".
> > 
> > Could one batch change more than one table?  (I think it could?)
> 
> Yes.

Ok, listing all tables involved in one commit with deduplication will be
a bit of a nuisance.

> > It appears it can change more than one family.
> > "family" is currently a single integer, so that might need to be changed
> > to a list, or something to indicate multi-family.
> 
> Yes, it can also affect different families.
> 
> > Listing all the ops seems a bit onerous.  Is there a hierarchy to the
> > ops and if so, are they in that order in a batch or in nf_tables_commit()?
> 
> No.  There is a hierarchy, e.g. you can't add a chain without first
> adding a table, BUT in case the table was already created by an earlier
> transaction it can also be stand-alone.

Ok, so there could be a stand-alone chain mod with one table, then a
table add of a different one with a "higher ranking" op...

> > It seems I'd need to filter out the NFT_MSG_GET_* ops.
> 
> No need, the GET ops do not cause changes and will not trigger a
> generation id change.

Ah, so it could trigger on generation change.  Would GET ops be included
in any other change, such that it would be desirable to filter them out
to reduce noise in that single log line if it is attempted to list all
the change ops?  It almost sounds like it would be better to do one
audit log line for each table for each family, and possibly for each op
to avoid the need to change userspace.  This would already be a
significant improvement picking the highest ranking op.

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635