On 2020-06-01 20:12, Paul Moore wrote:
On Mon, Jun 1, 2020 at 6:58 PM Richard Guy Briggs
<rgb(a)redhat.com> wrote:
> On 2020-06-01 12:10, Paul Moore wrote:
> > On Thu, May 28, 2020 at 9:44 PM Richard Guy Briggs <rgb(a)redhat.com>
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.
Yup, I agree, a compile time check to make sure they aren't out of sync.
paul moore
- RGB
--
Richard Guy Briggs <rgb(a)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