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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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.