On Mon, Jun 1, 2020 at 6:58 PM Richard Guy Briggs <rgb@xxxxxxxxxx> wrote:
> On 2020-06-01 12:10, Paul Moore wrote:
> > On Thu, May 28, 2020 at 9:44 PM Richard Guy Briggs <rgb@xxxxxxxxxx> wrote:
...
> > > diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
> > > index 4471393da6d8..7a386eca6e04 100644
> > > --- a/net/netfilter/nf_tables_api.c
> > > +++ b/net/netfilter/nf_tables_api.c
> > > @@ -12,6 +12,7 @@
> > > #include <linux/netlink.h>
> > > #include <linux/vmalloc.h>
> > > #include <linux/rhashtable.h>
> > > +#include <linux/audit.h>
> > > #include <linux/netfilter.h>
> > > #include <linux/netfilter/nfnetlink.h>
> > > #include <linux/netfilter/nf_tables.h>
> > > @@ -693,6 +694,14 @@ static void nf_tables_table_notify(const struct nft_ctx *ctx, int event)
> > > {
> > > struct sk_buff *skb;
> > > int err;
> > > + char *buf = kasprintf(GFP_KERNEL, "%s:%llu;?:0",
> > > + ctx->table->name, ctx->table->handle);
> > > +
> > > + audit_log_nfcfg(buf,
> > > + ctx->family,
> > > + ctx->table->use,
> > > + audit_nftcfgs[event].op);
> >
> > As an example, the below would work, yes?
> >
> > audit_log_nfcfg(...,
> > (event == NFT_MSG_NEWTABLE ?
> > AUDIT_NFT_OP_TABLE_REGISTER :
> > AUDIT_NFT_OP_TABLE_UNREGISTER)
>
> Ok, I see what you are getting at now... Yes, it could be done this
> way, but it seems noisier to me.
I'll admit it is not as clean, but it doesn't hide the mapping between
the netfilter operation and the audit operation which hopefully makes
it clear to those modifying the netfilter/nf_tables/etc. code that
there is an audit impact. I'm basically trying to make sure the code
is as robust as possible in the face of subsystem changes beyond the
audit subsystem.
--
paul moore
www.paul-moore.com
