All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: Linux-Audit Mailing List <linux-audit@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	netfilter-devel@vger.kernel.org, Paul Moore <paul@paul-moore.com>,
	omosnace@redhat.com, fw@strlen.de, twoerner@redhat.com,
	eparis@parisplace.org, tgraf@infradead.org
Subject: Re: [PATCH ghak124 v3] audit: log nftables configuration change events
Date: Thu, 04 Jun 2020 14:51:54 -0400	[thread overview]
Message-ID: <2190308.cDvYnDs5iT@x2> (raw)
In-Reply-To: <20200604175756.d3x5fy4k4urilgbp@madcap2.tricolour.ca>

On Thursday, June 4, 2020 1:57:56 PM EDT Richard Guy Briggs wrote:
> > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > index 468a23390457..3a9100e95fda 100644
> > > --- a/kernel/auditsc.c
> > > +++ b/kernel/auditsc.c
> > > @@ -75,6 +75,7 @@
> > > #include <linux/uaccess.h>
> > > #include <linux/fsnotify_backend.h>
> > > #include <uapi/linux/limits.h>
> > > +#include <uapi/linux/netfilter/nf_tables.h>
> > > 
> > > #include "audit.h"
> > > 
> > > @@ -136,9 +137,26 @@ struct audit_nfcfgop_tab {
> > > };
> > > 
> > > static const struct audit_nfcfgop_tab audit_nfcfgs[] = {
> > > -       { AUDIT_XT_OP_REGISTER,         "register"      },
> > > -       { AUDIT_XT_OP_REPLACE,          "replace"       },
> > > -       { AUDIT_XT_OP_UNREGISTER,       "unregister"    },
> > > +       { AUDIT_XT_OP_REGISTER,                 "xt_register"
> > 
> > },
> > 
> > > +       { AUDIT_XT_OP_REPLACE,                  "xt_replace"           
> > >    }, +       { AUDIT_XT_OP_UNREGISTER,               "xt_unregister" 
> > >           }, +       { AUDIT_NFT_OP_TABLE_REGISTER,         
> > > "nft_register_table"> 
> > },
> > 
> > > +       { AUDIT_NFT_OP_TABLE_UNREGISTER,        "nft_unregister_table" 
> > >    }, +       { AUDIT_NFT_OP_CHAIN_REGISTER,         
> > > "nft_register_chain"> 
> > },
> > 
> > > +       { AUDIT_NFT_OP_CHAIN_UNREGISTER,        "nft_unregister_chain" 
> > >    }, +       { AUDIT_NFT_OP_RULE_REGISTER,          
> > > "nft_register_rule"> 
> > },
> > 
> > > +       { AUDIT_NFT_OP_RULE_UNREGISTER,         "nft_unregister_rule"
> > 
> > },
> > 
> > > +       { AUDIT_NFT_OP_SET_REGISTER,            "nft_register_set"
> > 
> > },
> > 
> > > +       { AUDIT_NFT_OP_SET_UNREGISTER,          "nft_unregister_set"
> > 
> > },
> > 
> > > +       { AUDIT_NFT_OP_SETELEM_REGISTER,        "nft_register_setelem" 
> > >    }, +       { AUDIT_NFT_OP_SETELEM_UNREGISTER,     
> > > "nft_unregister_setelem"   }, +       { AUDIT_NFT_OP_GEN_REGISTER,    
> > >        "nft_register_gen"         }, +       {
> > > AUDIT_NFT_OP_OBJ_REGISTER,            "nft_register_obj"         }, + 
> > >      { AUDIT_NFT_OP_OBJ_UNREGISTER,          "nft_unregister_obj"     
> > >  }, +       { AUDIT_NFT_OP_OBJ_RESET,               "nft_reset_obj"   
> > >         }, +       { AUDIT_NFT_OP_FLOWTABLE_REGISTER,     
> > > "nft_register_flowtable"   }, +       {
> > > AUDIT_NFT_OP_FLOWTABLE_UNREGISTER,    "nft_unregister_flowtable" }, + 
> > >      { AUDIT_NFT_OP_INVALID,                 "nft_invalid"
> > 
> > },
> > 
> > > };
> > 
> > I still don't like the event format because it doesn't give complete
> > subject information. However, I thought I'd comment on this string
> > table. Usually it's sufficient to log the number and then have the
> > string table in user space which looks it up during interpretation.
> 
> That is a good idea that would help reduce kernel cycles and netlink
> bandwidth, but the format was set in 2011 so it is a bit late to change
> that now:
>         fbabf31e4d48 ("netfilter: create audit records for x_tables
> replaces")

Nothing searches/interprets that field name. So, you can redefine it by 
renaming it. Or just go with what you have. My preference is push that to 
user space. But not a showstopper "as is".

-Steve



WARNING: multiple messages have this Message-ID (diff)
From: Steve Grubb <sgrubb@redhat.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: fw@strlen.de, LKML <linux-kernel@vger.kernel.org>,
	Linux-Audit Mailing List <linux-audit@redhat.com>,
	netfilter-devel@vger.kernel.org, twoerner@redhat.com,
	eparis@parisplace.org, tgraf@infradead.org
Subject: Re: [PATCH ghak124 v3] audit: log nftables configuration change events
Date: Thu, 04 Jun 2020 14:51:54 -0400	[thread overview]
Message-ID: <2190308.cDvYnDs5iT@x2> (raw)
In-Reply-To: <20200604175756.d3x5fy4k4urilgbp@madcap2.tricolour.ca>

On Thursday, June 4, 2020 1:57:56 PM EDT Richard Guy Briggs wrote:
> > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > index 468a23390457..3a9100e95fda 100644
> > > --- a/kernel/auditsc.c
> > > +++ b/kernel/auditsc.c
> > > @@ -75,6 +75,7 @@
> > > #include <linux/uaccess.h>
> > > #include <linux/fsnotify_backend.h>
> > > #include <uapi/linux/limits.h>
> > > +#include <uapi/linux/netfilter/nf_tables.h>
> > > 
> > > #include "audit.h"
> > > 
> > > @@ -136,9 +137,26 @@ struct audit_nfcfgop_tab {
> > > };
> > > 
> > > static const struct audit_nfcfgop_tab audit_nfcfgs[] = {
> > > -       { AUDIT_XT_OP_REGISTER,         "register"      },
> > > -       { AUDIT_XT_OP_REPLACE,          "replace"       },
> > > -       { AUDIT_XT_OP_UNREGISTER,       "unregister"    },
> > > +       { AUDIT_XT_OP_REGISTER,                 "xt_register"
> > 
> > },
> > 
> > > +       { AUDIT_XT_OP_REPLACE,                  "xt_replace"           
> > >    }, +       { AUDIT_XT_OP_UNREGISTER,               "xt_unregister" 
> > >           }, +       { AUDIT_NFT_OP_TABLE_REGISTER,         
> > > "nft_register_table"> 
> > },
> > 
> > > +       { AUDIT_NFT_OP_TABLE_UNREGISTER,        "nft_unregister_table" 
> > >    }, +       { AUDIT_NFT_OP_CHAIN_REGISTER,         
> > > "nft_register_chain"> 
> > },
> > 
> > > +       { AUDIT_NFT_OP_CHAIN_UNREGISTER,        "nft_unregister_chain" 
> > >    }, +       { AUDIT_NFT_OP_RULE_REGISTER,          
> > > "nft_register_rule"> 
> > },
> > 
> > > +       { AUDIT_NFT_OP_RULE_UNREGISTER,         "nft_unregister_rule"
> > 
> > },
> > 
> > > +       { AUDIT_NFT_OP_SET_REGISTER,            "nft_register_set"
> > 
> > },
> > 
> > > +       { AUDIT_NFT_OP_SET_UNREGISTER,          "nft_unregister_set"
> > 
> > },
> > 
> > > +       { AUDIT_NFT_OP_SETELEM_REGISTER,        "nft_register_setelem" 
> > >    }, +       { AUDIT_NFT_OP_SETELEM_UNREGISTER,     
> > > "nft_unregister_setelem"   }, +       { AUDIT_NFT_OP_GEN_REGISTER,    
> > >        "nft_register_gen"         }, +       {
> > > AUDIT_NFT_OP_OBJ_REGISTER,            "nft_register_obj"         }, + 
> > >      { AUDIT_NFT_OP_OBJ_UNREGISTER,          "nft_unregister_obj"     
> > >  }, +       { AUDIT_NFT_OP_OBJ_RESET,               "nft_reset_obj"   
> > >         }, +       { AUDIT_NFT_OP_FLOWTABLE_REGISTER,     
> > > "nft_register_flowtable"   }, +       {
> > > AUDIT_NFT_OP_FLOWTABLE_UNREGISTER,    "nft_unregister_flowtable" }, + 
> > >      { AUDIT_NFT_OP_INVALID,                 "nft_invalid"
> > 
> > },
> > 
> > > };
> > 
> > I still don't like the event format because it doesn't give complete
> > subject information. However, I thought I'd comment on this string
> > table. Usually it's sufficient to log the number and then have the
> > string table in user space which looks it up during interpretation.
> 
> That is a good idea that would help reduce kernel cycles and netlink
> bandwidth, but the format was set in 2011 so it is a bit late to change
> that now:
>         fbabf31e4d48 ("netfilter: create audit records for x_tables
> replaces")

Nothing searches/interprets that field name. So, you can redefine it by 
renaming it. Or just go with what you have. My preference is push that to 
user space. But not a showstopper "as is".

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit


  reply	other threads:[~2020-06-04 18:52 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 [this message]
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
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=2190308.cDvYnDs5iT@x2 \
    --to=sgrubb@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=omosnace@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=rgb@redhat.com \
    --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: link
Be 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.