[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210211220930.GC2766@breakpoint.cc>
Date: Thu, 11 Feb 2021 23:09:30 +0100
From: Florian Westphal <fw@...len.de>
To: Richard Guy Briggs <rgb@...hat.com>
Cc: Paul Moore <paul@...l-moore.com>, Phil Sutter <phil@....cc>,
Linux-Audit Mailing List <linux-audit@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
netfilter-devel@...r.kernel.org, sgrubb@...hat.com,
Ondrej Mosnacek <omosnace@...hat.com>, fw@...len.de,
twoerner@...hat.com, Eric Paris <eparis@...isplace.org>,
tgraf@...radead.org
Subject: Re: [PATCH ghak124 v3] audit: log nftables configuration change
events
Richard Guy Briggs <rgb@...hat.com> wrote:
> > > I personally would notify once per transaction. This is easy and quick.
>
> This was the goal. iptables was atomic. nftables appears to no longer
> be so. If I have this wrong, please show how that works.
nftables transactions are atomic, either the entire batch takes effect or not
at all.
The audit_log_nfcfg() calls got added to the the nft monitor infra which
is designed to allow userspace to follow the entire content of the
transaction log.
So, if its just a 'something was changed' event that is needed all of
them can be removed. ATM the audit_log_nfcfg() looks like this:
/* step 3. Start new generation, rules_gen_X now in use. */
net->nft.gencursor = nft_gencursor_next(net);
list_for_each_entry_safe(trans, next, &net->nft.commit_list, list) {
switch (trans->msg_type) {
case NFT_MSG_NEWTABLE:
audit_log_nfcfg();
...
case NFT_MSG_...
audit_log_nfcfg();
..
}
which gives an audit_log for every single change in the batch.
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.
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.
Powered by blists - more mailing lists