From: Richard Guy Briggs <rgb@redhat.com> To: Florian Westphal <fw@strlen.de> Cc: Phil Sutter <phil@nwl.cc>, LKML <linux-kernel@vger.kernel.org>, Linux-Audit Mailing List <linux-audit@redhat.com>, netfilter-devel@vger.kernel.org, twoerner@redhat.com, Eric Paris <eparis@parisplace.org>, tgraf@infradead.org Subject: Re: [PATCH ghak124 v3] audit: log nftables configuration change events Date: Thu, 18 Feb 2021 07:42:11 -0500 [thread overview] Message-ID: <20210218124211.GO3141668@madcap2.tricolour.ca> (raw) In-Reply-To: <20210218082207.GJ2766@breakpoint.cc> 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
WARNING: multiple messages have this Message-ID (diff)
From: Richard Guy Briggs <rgb@redhat.com> To: Florian Westphal <fw@strlen.de> Cc: Phil Sutter <phil@nwl.cc>, LKML <linux-kernel@vger.kernel.org>, Linux-Audit Mailing List <linux-audit@redhat.com>, netfilter-devel@vger.kernel.org, twoerner@redhat.com, Eric Paris <eparis@parisplace.org>, tgraf@infradead.org Subject: Re: [PATCH ghak124 v3] audit: log nftables configuration change events Date: Thu, 18 Feb 2021 07:42:11 -0500 [thread overview] Message-ID: <20210218124211.GO3141668@madcap2.tricolour.ca> (raw) In-Reply-To: <20210218082207.GJ2766@breakpoint.cc> 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 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2021-02-18 14:43 UTC|newest] Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-04 13:20 [PATCH ghak124 v3] audit: log nftables configuration change events Richard Guy Briggs 2020-06-04 13:20 ` Richard Guy Briggs 2020-06-04 17:03 ` Steve Grubb 2020-06-04 17:03 ` Steve Grubb 2020-06-04 17:57 ` Richard Guy Briggs 2020-06-04 17:57 ` Richard Guy Briggs 2020-06-04 18:51 ` Steve Grubb 2020-06-04 18:51 ` Steve Grubb 2020-06-24 0:34 ` Paul Moore 2020-06-24 0:34 ` Paul Moore 2020-06-24 10:03 ` Pablo Neira Ayuso 2020-06-24 10:03 ` Pablo Neira Ayuso 2020-06-24 12:34 ` Richard Guy Briggs 2020-06-24 12:34 ` Richard Guy Briggs 2020-06-24 13:03 ` Pablo Neira Ayuso 2020-06-24 13:03 ` Pablo Neira Ayuso 2020-06-24 13:26 ` Richard Guy Briggs 2020-06-24 13:26 ` Richard Guy Briggs 2021-02-11 15:16 ` Phil Sutter 2021-02-11 16:29 ` Paul Moore 2021-02-11 16:29 ` Paul Moore 2021-02-11 20:26 ` Richard Guy Briggs 2021-02-11 20:26 ` Richard Guy Briggs 2021-02-11 22:09 ` Florian Westphal 2021-02-17 23:41 ` Richard Guy Briggs 2021-02-17 23:41 ` Richard Guy Briggs 2021-02-18 8:22 ` Florian Westphal 2021-02-18 8:22 ` Florian Westphal 2021-02-18 12:42 ` Richard Guy Briggs [this message] 2021-02-18 12:42 ` Richard Guy Briggs 2021-02-18 12:52 ` Florian Westphal 2021-02-18 12:52 ` Florian Westphal 2021-02-18 13:28 ` Richard Guy Briggs 2021-02-18 13:28 ` Richard Guy Briggs 2021-02-18 13:41 ` Florian Westphal 2021-02-18 13:41 ` Florian Westphal 2021-02-18 21:20 ` Richard Guy Briggs 2021-02-18 21:20 ` Richard Guy Briggs 2021-02-18 22:42 ` Florian Westphal 2021-02-18 22:42 ` Florian Westphal 2021-02-19 6:26 ` Richard Guy Briggs 2021-02-19 6:26 ` Richard Guy Briggs 2021-02-19 19:25 ` Richard Guy Briggs 2021-02-19 19:25 ` Richard Guy Briggs 2021-02-12 20:48 ` Richard Guy Briggs 2021-02-12 20:48 ` Richard Guy Briggs 2021-02-11 21:02 ` Steve Grubb 2021-02-11 21:02 ` Steve Grubb 2021-02-12 12:11 ` Phil Sutter 2021-02-12 20:54 ` Richard Guy Briggs 2021-02-12 20:54 ` Richard Guy Briggs
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210218124211.GO3141668@madcap2.tricolour.ca \ --to=rgb@redhat.com \ --cc=eparis@parisplace.org \ --cc=fw@strlen.de \ --cc=linux-audit@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=netfilter-devel@vger.kernel.org \ --cc=phil@nwl.cc \ --cc=tgraf@infradead.org \ --cc=twoerner@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.