* [PATCH ghak25 v3 0/3] Address NETFILTER_CFG issues @ 2020-03-17 21:30 Richard Guy Briggs 2020-03-17 21:30 ` [PATCH ghak25 v3 1/3] audit: tidy and extend netfilter_cfg x_tables and ebtables logging Richard Guy Briggs ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Richard Guy Briggs @ 2020-03-17 21:30 UTC (permalink / raw) To: Linux-Audit Mailing List, LKML, netfilter-devel Cc: Richard Guy Briggs, fw, ebiederm, twoerner, eparis, tgraf There were questions about the presence and cause of unsolicited syscall events in the logs containing NETFILTER_CFG records and sometimes unaccompanied NETFILTER_CFG records. During testing at least the following list of events trigger NETFILTER_CFG records and the syscalls related (There may be more events that will trigger this message type.): init_module, finit_module: modprobe delete_module: rmmod setsockopt: iptables-restore, ip6tables-restore, ebtables-restore unshare: (h?)ostnamed, updatedb clone: libvirtd kernel threads garbage collecting empty ebtables The syscall events unsolicited by any audit rule were found to be caused by a missing !audit_dummy_context() check before issuing a NETFILTER_CFG record. In fact, since this is a configuration change it is required, and we always want the accompanying syscall record even with no rules present, so this has been addressed by ghak120. The vast majority of unaccompanied records are caused by the fedora default rule: "-a never,task" and the occasional early startup one is I believe caused by the iptables filter table module hard linked into the kernel rather than a loadable module. A couple of other factors should help eliminate unaccompanied records which include commit cb74ed278f80 ("audit: always enable syscall auditing when supported and audit is enabled") which makes sure that when audit is enabled, so automatically is syscall auditing, and ghak66 which addressed initializing audit before PID 1. Ebtables module initialization to register tables doesn't generate records because it was never hooked in to audit. Recommend adding audit hooks to log this covered by ghak43 covered by patch 1. Table unregistration was never logged, which is now covered by ghak44 in patch 2. Unaccompanied records were caused by kernel threads automatically unregistering empty ebtables, which necessitates adding subject credentials covered in patch 3. Seemingly duplicate records are not actually exact duplicates that are caused by netfilter table initialization in different network namespaces from the same syscall. Recommend adding the network namespace ID (proc inode and dev) to the record to make this obvious (address later with ghak79 after nsid patches). See: https://github.com/linux-audit/audit-kernel/issues/25 See: https://github.com/linux-audit/audit-kernel/issues/35 See: https://github.com/linux-audit/audit-kernel/issues/43 See: https://github.com/linux-audit/audit-kernel/issues/44 Changelog: v3 - rebase on v5.6-rc1 audit/next - change audit_nf_cfg to audit_log_nfcfg - squash 2,3,4,5 to 1 and update patch descriptions - add subject credentials to cover garbage collecting kernel threads v2 - Rebase (audit/next 5.5-rc1) to get audit_context access and ebt_register_table ret code - Split x_tables and ebtables updates - Check audit_dummy_context - Store struct audit_nfcfg params in audit_context, abstract to audit_nf_cfg() call - Restore back to "table, family, entries" from "family, table, entries" - Log unregistration of tables - Add "op=" at the end of the AUDIT_NETFILTER_CFG record - Defer nsid patch (ghak79) to once nsid patchset upstreamed (ghak32) - Add ghak refs - Ditch NETFILTER_CFGSOLO record Richard Guy Briggs (3): audit: tidy and extend netfilter_cfg x_tables and ebtables logging netfilter: add audit table unregister actions audit: add subj creds to NETFILTER_CFG record to cover async unregister include/linux/audit.h | 20 +++++++++++++++++++ kernel/auditsc.c | 43 +++++++++++++++++++++++++++++++++++++++++ net/bridge/netfilter/ebtables.c | 14 ++++++-------- net/netfilter/x_tables.c | 14 +++++--------- 4 files changed, 74 insertions(+), 17 deletions(-) -- 1.8.3.1 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH ghak25 v3 1/3] audit: tidy and extend netfilter_cfg x_tables and ebtables logging 2020-03-17 21:30 [PATCH ghak25 v3 0/3] Address NETFILTER_CFG issues Richard Guy Briggs @ 2020-03-17 21:30 ` Richard Guy Briggs 2020-03-18 21:54 ` Paul Moore 2020-03-17 21:30 ` [PATCH ghak25 v3 2/3] netfilter: add audit table unregister actions Richard Guy Briggs 2020-03-17 21:30 ` [PATCH ghak25 v3 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister Richard Guy Briggs 2 siblings, 1 reply; 14+ messages in thread From: Richard Guy Briggs @ 2020-03-17 21:30 UTC (permalink / raw) To: Linux-Audit Mailing List, LKML, netfilter-devel Cc: Richard Guy Briggs, fw, ebiederm, twoerner, eparis, tgraf NETFILTER_CFG record generation was inconsistent for x_tables and ebtables configuration changes. The call was needlessly messy and there were supporting records missing at times while they were produced when not requested. Simplify the logging call into a new audit_log_nfcfg call. Honour the audit_enabled setting while more consistently recording information including supporting records by tidying up dummy checks. Add an op= field that indicates the operation being performed (register or replace). Here is the enhanced sample record: type=NETFILTER_CFG msg=audit(1580905834.919:82970): table=filter family=2 entries=83 op=replace Generate audit NETFILTER_CFG records on ebtables table registration. Previously this was being done for x_tables registration and replacement operations and ebtables table replacement only. See: https://github.com/linux-audit/audit-kernel/issues/25 See: https://github.com/linux-audit/audit-kernel/issues/35 See: https://github.com/linux-audit/audit-kernel/issues/43 Signed-off-by: Richard Guy Briggs <rgb@redhat.com> --- include/linux/audit.h | 19 +++++++++++++++++++ kernel/auditsc.c | 24 ++++++++++++++++++++++++ net/bridge/netfilter/ebtables.c | 12 ++++-------- net/netfilter/x_tables.c | 12 +++--------- 4 files changed, 50 insertions(+), 17 deletions(-) diff --git a/include/linux/audit.h b/include/linux/audit.h index f9ceae57ca8d..f4aed2b9be8d 100644 --- a/include/linux/audit.h +++ b/include/linux/audit.h @@ -94,6 +94,11 @@ struct audit_ntp_data { struct audit_ntp_data {}; #endif +enum audit_nfcfgop { + AUDIT_XT_OP_REGISTER, + AUDIT_XT_OP_REPLACE, +}; + extern int is_audit_feature_set(int which); extern int __init audit_register_class(int class, unsigned *list); @@ -379,6 +384,8 @@ extern int __audit_log_bprm_fcaps(struct linux_binprm *bprm, extern void __audit_fanotify(unsigned int response); extern void __audit_tk_injoffset(struct timespec64 offset); extern void __audit_ntp_log(const struct audit_ntp_data *ad); +extern void __audit_log_nfcfg(const char *name, u8 af, unsigned int nentries, + enum audit_nfcfgop op); static inline void audit_ipc_obj(struct kern_ipc_perm *ipcp) { @@ -514,6 +521,13 @@ static inline void audit_ntp_log(const struct audit_ntp_data *ad) __audit_ntp_log(ad); } +static inline void audit_log_nfcfg(const char *name, u8 af, unsigned int nentries, + enum audit_nfcfgop op) +{ + if (audit_enabled) + __audit_log_nfcfg(name, af, nentries, op); +} + extern int audit_n_rules; extern int audit_signals; #else /* CONFIG_AUDITSYSCALL */ @@ -646,6 +660,11 @@ static inline void audit_ntp_log(const struct audit_ntp_data *ad) static inline void audit_ptrace(struct task_struct *t) { } + +static inline void audit_log_nfcfg(const char *name, u8 af, unsigned int nentries, + enum audit_nfcfgop op) +{ } + #define audit_n_rules 0 #define audit_signals 0 #endif /* CONFIG_AUDITSYSCALL */ diff --git a/kernel/auditsc.c b/kernel/auditsc.c index 814406a35db1..f4e342125dd9 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -130,6 +130,16 @@ struct audit_tree_refs { struct audit_chunk *c[31]; }; +struct audit_nfcfgop_tab { + enum audit_nfcfgop op; + const char *s; +}; + +const struct audit_nfcfgop_tab audit_nfcfgs[] = { + { AUDIT_XT_OP_REGISTER, "register" }, + { AUDIT_XT_OP_REPLACE, "replace" }, +}; + static int audit_match_perm(struct audit_context *ctx, int mask) { unsigned n; @@ -2542,6 +2552,20 @@ void __audit_ntp_log(const struct audit_ntp_data *ad) audit_log_ntp_val(ad, "adjust", AUDIT_NTP_ADJUST); } +void __audit_log_nfcfg(const char *name, u8 af, unsigned int nentries, + enum audit_nfcfgop op) +{ + struct audit_buffer *ab; + + ab = audit_log_start(audit_context(), GFP_KERNEL, AUDIT_NETFILTER_CFG); + if (!ab) + return; + audit_log_format(ab, "table=%s family=%u entries=%u op=%s", + name, af, nentries, audit_nfcfgs[op].s); + audit_log_end(ab); +} +EXPORT_SYMBOL_GPL(__audit_log_nfcfg); + static void audit_log_task(struct audit_buffer *ab) { kuid_t auid, uid; diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c index e1256e03a9a8..55f9409c3ee0 100644 --- a/net/bridge/netfilter/ebtables.c +++ b/net/bridge/netfilter/ebtables.c @@ -1046,14 +1046,8 @@ static int do_replace_finish(struct net *net, struct ebt_replace *repl, vfree(table); vfree(counterstmp); -#ifdef CONFIG_AUDIT - if (audit_enabled) { - audit_log(audit_context(), GFP_KERNEL, - AUDIT_NETFILTER_CFG, - "table=%s family=%u entries=%u", - repl->name, AF_BRIDGE, repl->nentries); - } -#endif + audit_log_nfcfg(repl->name, AF_BRIDGE, repl->nentries, + AUDIT_XT_OP_REPLACE); return ret; free_unlock: @@ -1223,6 +1217,8 @@ int ebt_register_table(struct net *net, const struct ebt_table *input_table, *res = NULL; } + audit_log_nfcfg(repl->name, AF_BRIDGE, repl->nentries, + AUDIT_XT_OP_REGISTER); return ret; free_unlock: mutex_unlock(&ebt_mutex); diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c index e27c6c5ba9df..db5cbcf43748 100644 --- a/net/netfilter/x_tables.c +++ b/net/netfilter/x_tables.c @@ -1408,15 +1408,9 @@ struct xt_table_info * } } -#ifdef CONFIG_AUDIT - if (audit_enabled) { - audit_log(audit_context(), GFP_KERNEL, - AUDIT_NETFILTER_CFG, - "table=%s family=%u entries=%u", - table->name, table->af, private->number); - } -#endif - + audit_log_nfcfg(table->name, table->af, private->number, + !private->number ? AUDIT_XT_OP_REGISTER : + AUDIT_XT_OP_REPLACE); return private; } EXPORT_SYMBOL_GPL(xt_replace_table); -- 1.8.3.1 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH ghak25 v3 1/3] audit: tidy and extend netfilter_cfg x_tables and ebtables logging 2020-03-17 21:30 ` [PATCH ghak25 v3 1/3] audit: tidy and extend netfilter_cfg x_tables and ebtables logging Richard Guy Briggs @ 2020-03-18 21:54 ` Paul Moore 2020-03-18 22:00 ` Richard Guy Briggs 0 siblings, 1 reply; 14+ messages in thread From: Paul Moore @ 2020-03-18 21:54 UTC (permalink / raw) To: Richard Guy Briggs Cc: fw, LKML, Linux-Audit Mailing List, netfilter-devel, ebiederm, twoerner, Eric Paris, tgraf On Tue, Mar 17, 2020 at 5:31 PM Richard Guy Briggs <rgb@redhat.com> wrote: > > NETFILTER_CFG record generation was inconsistent for x_tables and > ebtables configuration changes. The call was needlessly messy and there > were supporting records missing at times while they were produced when > not requested. Simplify the logging call into a new audit_log_nfcfg > call. Honour the audit_enabled setting while more consistently > recording information including supporting records by tidying up dummy > checks. > > Add an op= field that indicates the operation being performed (register > or replace). > > Here is the enhanced sample record: > type=NETFILTER_CFG msg=audit(1580905834.919:82970): table=filter family=2 entries=83 op=replace > > Generate audit NETFILTER_CFG records on ebtables table registration. > Previously this was being done for x_tables registration and replacement > operations and ebtables table replacement only. > > See: https://github.com/linux-audit/audit-kernel/issues/25 > See: https://github.com/linux-audit/audit-kernel/issues/35 > See: https://github.com/linux-audit/audit-kernel/issues/43 > > Signed-off-by: Richard Guy Briggs <rgb@redhat.com> > --- > include/linux/audit.h | 19 +++++++++++++++++++ > kernel/auditsc.c | 24 ++++++++++++++++++++++++ > net/bridge/netfilter/ebtables.c | 12 ++++-------- > net/netfilter/x_tables.c | 12 +++--------- > 4 files changed, 50 insertions(+), 17 deletions(-) > > diff --git a/include/linux/audit.h b/include/linux/audit.h > index f9ceae57ca8d..f4aed2b9be8d 100644 > --- a/include/linux/audit.h > +++ b/include/linux/audit.h > @@ -94,6 +94,11 @@ struct audit_ntp_data { > struct audit_ntp_data {}; > #endif > > +enum audit_nfcfgop { > + AUDIT_XT_OP_REGISTER, > + AUDIT_XT_OP_REPLACE, > +}; > + > extern int is_audit_feature_set(int which); > > extern int __init audit_register_class(int class, unsigned *list); > @@ -379,6 +384,8 @@ extern int __audit_log_bprm_fcaps(struct linux_binprm *bprm, > extern void __audit_fanotify(unsigned int response); > extern void __audit_tk_injoffset(struct timespec64 offset); > extern void __audit_ntp_log(const struct audit_ntp_data *ad); > +extern void __audit_log_nfcfg(const char *name, u8 af, unsigned int nentries, > + enum audit_nfcfgop op); > > static inline void audit_ipc_obj(struct kern_ipc_perm *ipcp) > { > @@ -514,6 +521,13 @@ static inline void audit_ntp_log(const struct audit_ntp_data *ad) > __audit_ntp_log(ad); > } > > +static inline void audit_log_nfcfg(const char *name, u8 af, unsigned int nentries, > + enum audit_nfcfgop op) > +{ > + if (audit_enabled) > + __audit_log_nfcfg(name, af, nentries, op); Do we want a dummy check here too? Or do we always want to generate this record (assuming audit is enabled) because it is a configuration related record? -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH ghak25 v3 1/3] audit: tidy and extend netfilter_cfg x_tables and ebtables logging 2020-03-18 21:54 ` Paul Moore @ 2020-03-18 22:00 ` Richard Guy Briggs 2020-03-18 22:09 ` Paul Moore 0 siblings, 1 reply; 14+ messages in thread From: Richard Guy Briggs @ 2020-03-18 22:00 UTC (permalink / raw) To: Paul Moore Cc: fw, LKML, Linux-Audit Mailing List, netfilter-devel, ebiederm, twoerner, Eric Paris, tgraf On 2020-03-18 17:54, Paul Moore wrote: > On Tue, Mar 17, 2020 at 5:31 PM Richard Guy Briggs <rgb@redhat.com> wrote: > > > > NETFILTER_CFG record generation was inconsistent for x_tables and > > ebtables configuration changes. The call was needlessly messy and there > > were supporting records missing at times while they were produced when > > not requested. Simplify the logging call into a new audit_log_nfcfg > > call. Honour the audit_enabled setting while more consistently > > recording information including supporting records by tidying up dummy > > checks. > > > > Add an op= field that indicates the operation being performed (register > > or replace). > > > > Here is the enhanced sample record: > > type=NETFILTER_CFG msg=audit(1580905834.919:82970): table=filter family=2 entries=83 op=replace > > > > Generate audit NETFILTER_CFG records on ebtables table registration. > > Previously this was being done for x_tables registration and replacement > > operations and ebtables table replacement only. > > > > See: https://github.com/linux-audit/audit-kernel/issues/25 > > See: https://github.com/linux-audit/audit-kernel/issues/35 > > See: https://github.com/linux-audit/audit-kernel/issues/43 > > > > Signed-off-by: Richard Guy Briggs <rgb@redhat.com> > > --- > > include/linux/audit.h | 19 +++++++++++++++++++ > > kernel/auditsc.c | 24 ++++++++++++++++++++++++ > > net/bridge/netfilter/ebtables.c | 12 ++++-------- > > net/netfilter/x_tables.c | 12 +++--------- > > 4 files changed, 50 insertions(+), 17 deletions(-) > > > > diff --git a/include/linux/audit.h b/include/linux/audit.h > > index f9ceae57ca8d..f4aed2b9be8d 100644 > > --- a/include/linux/audit.h > > +++ b/include/linux/audit.h > > @@ -94,6 +94,11 @@ struct audit_ntp_data { > > struct audit_ntp_data {}; > > #endif > > > > +enum audit_nfcfgop { > > + AUDIT_XT_OP_REGISTER, > > + AUDIT_XT_OP_REPLACE, > > +}; > > + > > extern int is_audit_feature_set(int which); > > > > extern int __init audit_register_class(int class, unsigned *list); > > @@ -379,6 +384,8 @@ extern int __audit_log_bprm_fcaps(struct linux_binprm *bprm, > > extern void __audit_fanotify(unsigned int response); > > extern void __audit_tk_injoffset(struct timespec64 offset); > > extern void __audit_ntp_log(const struct audit_ntp_data *ad); > > +extern void __audit_log_nfcfg(const char *name, u8 af, unsigned int nentries, > > + enum audit_nfcfgop op); > > > > static inline void audit_ipc_obj(struct kern_ipc_perm *ipcp) > > { > > @@ -514,6 +521,13 @@ static inline void audit_ntp_log(const struct audit_ntp_data *ad) > > __audit_ntp_log(ad); > > } > > > > +static inline void audit_log_nfcfg(const char *name, u8 af, unsigned int nentries, > > + enum audit_nfcfgop op) > > +{ > > + if (audit_enabled) > > + __audit_log_nfcfg(name, af, nentries, op); > > Do we want a dummy check here too? Or do we always want to generate > this record (assuming audit is enabled) because it is a configuration > related record? This is an audit configuration change, so it is mandatory unless there is a rule that excludes it. I talked about this in the cover letter, but perhaps my wording wasn't as clear as it could have been. audit_dummy_context was deliberately removed to make this record delivered by default. > paul moore - 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://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH ghak25 v3 1/3] audit: tidy and extend netfilter_cfg x_tables and ebtables logging 2020-03-18 22:00 ` Richard Guy Briggs @ 2020-03-18 22:09 ` Paul Moore 0 siblings, 0 replies; 14+ messages in thread From: Paul Moore @ 2020-03-18 22:09 UTC (permalink / raw) To: Richard Guy Briggs Cc: fw, LKML, Linux-Audit Mailing List, netfilter-devel, ebiederm, twoerner, Eric Paris, tgraf On Wed, Mar 18, 2020 at 6:00 PM Richard Guy Briggs <rgb@redhat.com> wrote: > On 2020-03-18 17:54, Paul Moore wrote: > > On Tue, Mar 17, 2020 at 5:31 PM Richard Guy Briggs <rgb@redhat.com> wrote: > > > > > > NETFILTER_CFG record generation was inconsistent for x_tables and > > > ebtables configuration changes. The call was needlessly messy and there > > > were supporting records missing at times while they were produced when > > > not requested. Simplify the logging call into a new audit_log_nfcfg > > > call. Honour the audit_enabled setting while more consistently > > > recording information including supporting records by tidying up dummy > > > checks. > > > > > > Add an op= field that indicates the operation being performed (register > > > or replace). > > > > > > Here is the enhanced sample record: > > > type=NETFILTER_CFG msg=audit(1580905834.919:82970): table=filter family=2 entries=83 op=replace > > > > > > Generate audit NETFILTER_CFG records on ebtables table registration. > > > Previously this was being done for x_tables registration and replacement > > > operations and ebtables table replacement only. > > > > > > See: https://github.com/linux-audit/audit-kernel/issues/25 > > > See: https://github.com/linux-audit/audit-kernel/issues/35 > > > See: https://github.com/linux-audit/audit-kernel/issues/43 > > > > > > Signed-off-by: Richard Guy Briggs <rgb@redhat.com> > > > --- > > > include/linux/audit.h | 19 +++++++++++++++++++ > > > kernel/auditsc.c | 24 ++++++++++++++++++++++++ > > > net/bridge/netfilter/ebtables.c | 12 ++++-------- > > > net/netfilter/x_tables.c | 12 +++--------- > > > 4 files changed, 50 insertions(+), 17 deletions(-) > > > > > > diff --git a/include/linux/audit.h b/include/linux/audit.h > > > index f9ceae57ca8d..f4aed2b9be8d 100644 > > > --- a/include/linux/audit.h > > > +++ b/include/linux/audit.h > > > @@ -94,6 +94,11 @@ struct audit_ntp_data { > > > struct audit_ntp_data {}; > > > #endif > > > > > > +enum audit_nfcfgop { > > > + AUDIT_XT_OP_REGISTER, > > > + AUDIT_XT_OP_REPLACE, > > > +}; > > > + > > > extern int is_audit_feature_set(int which); > > > > > > extern int __init audit_register_class(int class, unsigned *list); > > > @@ -379,6 +384,8 @@ extern int __audit_log_bprm_fcaps(struct linux_binprm *bprm, > > > extern void __audit_fanotify(unsigned int response); > > > extern void __audit_tk_injoffset(struct timespec64 offset); > > > extern void __audit_ntp_log(const struct audit_ntp_data *ad); > > > +extern void __audit_log_nfcfg(const char *name, u8 af, unsigned int nentries, > > > + enum audit_nfcfgop op); > > > > > > static inline void audit_ipc_obj(struct kern_ipc_perm *ipcp) > > > { > > > @@ -514,6 +521,13 @@ static inline void audit_ntp_log(const struct audit_ntp_data *ad) > > > __audit_ntp_log(ad); > > > } > > > > > > +static inline void audit_log_nfcfg(const char *name, u8 af, unsigned int nentries, > > > + enum audit_nfcfgop op) > > > +{ > > > + if (audit_enabled) > > > + __audit_log_nfcfg(name, af, nentries, op); > > > > Do we want a dummy check here too? Or do we always want to generate > > this record (assuming audit is enabled) because it is a configuration > > related record? > > This is an audit configuration change, so it is mandatory unless there > is a rule that excludes it. I talked about this in the cover letter, > but perhaps my wording wasn't as clear as it could have been. Yes, it wasn't clear to me what your goals were. In general I think this patchset looks okay, but it's -rc6 so this should wait for the next cycle; it will also give the netdev/netfilter folks a chance to comment on this latest revision. -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH ghak25 v3 2/3] netfilter: add audit table unregister actions 2020-03-17 21:30 [PATCH ghak25 v3 0/3] Address NETFILTER_CFG issues Richard Guy Briggs 2020-03-17 21:30 ` [PATCH ghak25 v3 1/3] audit: tidy and extend netfilter_cfg x_tables and ebtables logging Richard Guy Briggs @ 2020-03-17 21:30 ` Richard Guy Briggs 2020-03-17 21:30 ` [PATCH ghak25 v3 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister Richard Guy Briggs 2 siblings, 0 replies; 14+ messages in thread From: Richard Guy Briggs @ 2020-03-17 21:30 UTC (permalink / raw) To: Linux-Audit Mailing List, LKML, netfilter-devel Cc: Richard Guy Briggs, fw, ebiederm, twoerner, eparis, tgraf Audit the action of unregistering ebtables and x_tables. See: https://github.com/linux-audit/audit-kernel/issues/44 Signed-off-by: Richard Guy Briggs <rgb@redhat.com> --- include/linux/audit.h | 1 + kernel/auditsc.c | 5 +++-- net/bridge/netfilter/ebtables.c | 2 ++ net/netfilter/x_tables.c | 2 ++ 4 files changed, 8 insertions(+), 2 deletions(-) diff --git a/include/linux/audit.h b/include/linux/audit.h index f4aed2b9be8d..17427c41cc29 100644 --- a/include/linux/audit.h +++ b/include/linux/audit.h @@ -97,6 +97,7 @@ struct audit_ntp_data { enum audit_nfcfgop { AUDIT_XT_OP_REGISTER, AUDIT_XT_OP_REPLACE, + AUDIT_XT_OP_UNREGISTER, }; extern int is_audit_feature_set(int which); diff --git a/kernel/auditsc.c b/kernel/auditsc.c index f4e342125dd9..dbb056feccb9 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -136,8 +136,9 @@ struct audit_nfcfgop_tab { }; const struct audit_nfcfgop_tab audit_nfcfgs[] = { - { AUDIT_XT_OP_REGISTER, "register" }, - { AUDIT_XT_OP_REPLACE, "replace" }, + { AUDIT_XT_OP_REGISTER, "register" }, + { AUDIT_XT_OP_REPLACE, "replace" }, + { AUDIT_XT_OP_UNREGISTER, "unregister" }, }; static int audit_match_perm(struct audit_context *ctx, int mask) diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c index 55f9409c3ee0..b3a2e6ea516c 100644 --- a/net/bridge/netfilter/ebtables.c +++ b/net/bridge/netfilter/ebtables.c @@ -1124,6 +1124,8 @@ static void __ebt_unregister_table(struct net *net, struct ebt_table *table) mutex_lock(&ebt_mutex); list_del(&table->list); mutex_unlock(&ebt_mutex); + audit_log_nfcfg(table->name, AF_BRIDGE, table->private->nentries, + AUDIT_XT_OP_UNREGISTER); EBT_ENTRY_ITERATE(table->private->entries, table->private->entries_size, ebt_cleanup_entry, net, NULL); if (table->private->nentries) diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c index db5cbcf43748..e43720a7783b 100644 --- a/net/netfilter/x_tables.c +++ b/net/netfilter/x_tables.c @@ -1472,6 +1472,8 @@ void *xt_unregister_table(struct xt_table *table) private = table->private; list_del(&table->list); mutex_unlock(&xt[table->af].mutex); + audit_log_nfcfg(table->name, table->af, private->number, + AUDIT_XT_OP_UNREGISTER); kfree(table); return private; -- 1.8.3.1 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH ghak25 v3 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister 2020-03-17 21:30 [PATCH ghak25 v3 0/3] Address NETFILTER_CFG issues Richard Guy Briggs 2020-03-17 21:30 ` [PATCH ghak25 v3 1/3] audit: tidy and extend netfilter_cfg x_tables and ebtables logging Richard Guy Briggs 2020-03-17 21:30 ` [PATCH ghak25 v3 2/3] netfilter: add audit table unregister actions Richard Guy Briggs @ 2020-03-17 21:30 ` Richard Guy Briggs 2020-03-18 13:11 ` Richard Guy Briggs 2 siblings, 1 reply; 14+ messages in thread From: Richard Guy Briggs @ 2020-03-17 21:30 UTC (permalink / raw) To: Linux-Audit Mailing List, LKML, netfilter-devel Cc: Richard Guy Briggs, fw, ebiederm, twoerner, eparis, tgraf Some table unregister actions seem to be initiated by the kernel to garbage collect unused tables that are not initiated by any userspace actions. It was found to be necessary to add the subject credentials to cover this case to reveal the source of these actions. A sample record: type=NETFILTER_CFG msg=audit(2020-03-11 21:25:21.491:269) : table=nat family=bridge entries=0 op=unregister pid=153 uid=root auid=unset tty=(none) ses=unset subj=system_u:system_r:kernel_t:s0 comm=kworker/u4:2 exe=(null) Signed-off-by: Richard Guy Briggs <rgb@redhat.com> --- kernel/auditsc.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/kernel/auditsc.c b/kernel/auditsc.c index dbb056feccb9..6c233076dfb7 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -2557,12 +2557,30 @@ void __audit_log_nfcfg(const char *name, u8 af, unsigned int nentries, enum audit_nfcfgop op) { struct audit_buffer *ab; + const struct cred *cred; + struct tty_struct *tty; + char comm[sizeof(current->comm)]; ab = audit_log_start(audit_context(), GFP_KERNEL, AUDIT_NETFILTER_CFG); if (!ab) return; audit_log_format(ab, "table=%s family=%u entries=%u op=%s", name, af, nentries, audit_nfcfgs[op].s); + + cred = current_cred(); + tty = audit_get_tty(); + audit_log_format(ab, " pid=%u uid=%u auid=%u tty=%s ses=%u", + task_pid_nr(current), + from_kuid(&init_user_ns, cred->uid), + from_kuid(&init_user_ns, audit_get_loginuid(current)), + tty ? tty_name(tty) : "(none)", + audit_get_sessionid(current)); + audit_put_tty(tty); + audit_log_task_context(ab); /* subj= */ + audit_log_format(ab, " comm="); + audit_log_untrustedstring(ab, get_task_comm(comm, current)); + audit_log_d_path_exe(ab, current->mm); /* exe= */ + audit_log_end(ab); } EXPORT_SYMBOL_GPL(__audit_log_nfcfg); -- 1.8.3.1 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH ghak25 v3 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister 2020-03-17 21:30 ` [PATCH ghak25 v3 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister Richard Guy Briggs @ 2020-03-18 13:11 ` Richard Guy Briggs 2020-03-18 21:22 ` Paul Moore 0 siblings, 1 reply; 14+ messages in thread From: Richard Guy Briggs @ 2020-03-18 13:11 UTC (permalink / raw) To: Linux-Audit Mailing List, LKML, netfilter-devel Cc: twoerner, eparis, fw, ebiederm, tgraf On 2020-03-17 17:30, Richard Guy Briggs wrote: > Some table unregister actions seem to be initiated by the kernel to > garbage collect unused tables that are not initiated by any userspace > actions. It was found to be necessary to add the subject credentials to > cover this case to reveal the source of these actions. A sample record: > > type=NETFILTER_CFG msg=audit(2020-03-11 21:25:21.491:269) : table=nat family=bridge entries=0 op=unregister pid=153 uid=root auid=unset tty=(none) ses=unset subj=system_u:system_r:kernel_t:s0 comm=kworker/u4:2 exe=(null) Given the precedent set by bpf unload, I'd really rather drop this patch that adds subject credentials. Similarly with ghak25's subject credentials, but they were already present and that would change an existing record format, so it isn't quite as justifiable in that case. > Signed-off-by: Richard Guy Briggs <rgb@redhat.com> > --- > kernel/auditsc.c | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c > index dbb056feccb9..6c233076dfb7 100644 > --- a/kernel/auditsc.c > +++ b/kernel/auditsc.c > @@ -2557,12 +2557,30 @@ void __audit_log_nfcfg(const char *name, u8 af, unsigned int nentries, > enum audit_nfcfgop op) > { > struct audit_buffer *ab; > + const struct cred *cred; > + struct tty_struct *tty; > + char comm[sizeof(current->comm)]; > > ab = audit_log_start(audit_context(), GFP_KERNEL, AUDIT_NETFILTER_CFG); > if (!ab) > return; > audit_log_format(ab, "table=%s family=%u entries=%u op=%s", > name, af, nentries, audit_nfcfgs[op].s); > + > + cred = current_cred(); > + tty = audit_get_tty(); > + audit_log_format(ab, " pid=%u uid=%u auid=%u tty=%s ses=%u", > + task_pid_nr(current), > + from_kuid(&init_user_ns, cred->uid), > + from_kuid(&init_user_ns, audit_get_loginuid(current)), > + tty ? tty_name(tty) : "(none)", > + audit_get_sessionid(current)); > + audit_put_tty(tty); > + audit_log_task_context(ab); /* subj= */ > + audit_log_format(ab, " comm="); > + audit_log_untrustedstring(ab, get_task_comm(comm, current)); > + audit_log_d_path_exe(ab, current->mm); /* exe= */ > + > audit_log_end(ab); > } > EXPORT_SYMBOL_GPL(__audit_log_nfcfg); > -- > 1.8.3.1 > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit - 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://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH ghak25 v3 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister 2020-03-18 13:11 ` Richard Guy Briggs @ 2020-03-18 21:22 ` Paul Moore 2020-03-18 21:33 ` Richard Guy Briggs 0 siblings, 1 reply; 14+ messages in thread From: Paul Moore @ 2020-03-18 21:22 UTC (permalink / raw) To: Richard Guy Briggs Cc: fw, LKML, Linux-Audit Mailing List, netfilter-devel, ebiederm, twoerner, Eric Paris, tgraf On Wed, Mar 18, 2020 at 9:12 AM Richard Guy Briggs <rgb@redhat.com> wrote: > On 2020-03-17 17:30, Richard Guy Briggs wrote: > > Some table unregister actions seem to be initiated by the kernel to > > garbage collect unused tables that are not initiated by any userspace > > actions. It was found to be necessary to add the subject credentials to > > cover this case to reveal the source of these actions. A sample record: > > > > type=NETFILTER_CFG msg=audit(2020-03-11 21:25:21.491:269) : table=nat family=bridge entries=0 op=unregister pid=153 uid=root auid=unset tty=(none) ses=unset subj=system_u:system_r:kernel_t:s0 comm=kworker/u4:2 exe=(null) > > Given the precedent set by bpf unload, I'd really rather drop this patch > that adds subject credentials. > > Similarly with ghak25's subject credentials, but they were already > present and that would change an existing record format, so it isn't > quite as justifiable in that case. Your comments have me confused - do you want this patch (v3 3/3) considered for merging or no? -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH ghak25 v3 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister 2020-03-18 21:22 ` Paul Moore @ 2020-03-18 21:33 ` Richard Guy Briggs 2020-04-17 21:53 ` Paul Moore 0 siblings, 1 reply; 14+ messages in thread From: Richard Guy Briggs @ 2020-03-18 21:33 UTC (permalink / raw) To: Paul Moore Cc: fw, LKML, Linux-Audit Mailing List, netfilter-devel, ebiederm, twoerner, Eric Paris, tgraf On 2020-03-18 17:22, Paul Moore wrote: > On Wed, Mar 18, 2020 at 9:12 AM Richard Guy Briggs <rgb@redhat.com> wrote: > > On 2020-03-17 17:30, Richard Guy Briggs wrote: > > > Some table unregister actions seem to be initiated by the kernel to > > > garbage collect unused tables that are not initiated by any userspace > > > actions. It was found to be necessary to add the subject credentials to > > > cover this case to reveal the source of these actions. A sample record: > > > > > > type=NETFILTER_CFG msg=audit(2020-03-11 21:25:21.491:269) : table=nat family=bridge entries=0 op=unregister pid=153 uid=root auid=unset tty=(none) ses=unset subj=system_u:system_r:kernel_t:s0 comm=kworker/u4:2 exe=(null) > > > > Given the precedent set by bpf unload, I'd really rather drop this patch > > that adds subject credentials. > > > > Similarly with ghak25's subject credentials, but they were already > > present and that would change an existing record format, so it isn't > > quite as justifiable in that case. > > Your comments have me confused - do you want this patch (v3 3/3) > considered for merging or no? I would like it considered for merging if you think it will be required to provide enough information about the event that happenned. In the bpf unload case, there is a program number to provide a link to a previous load action. In this case, we won't know for sure what caused the table to be unloaded if the number of entries was empty. I'm still trying to decide if it matters. For the sake of caution I think it should be included. I don't like it, but I think it needs to be included. > paul moore - 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://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH ghak25 v3 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister 2020-03-18 21:33 ` Richard Guy Briggs @ 2020-04-17 21:53 ` Paul Moore 2020-04-21 15:15 ` Steve Grubb 2020-04-21 20:19 ` Richard Guy Briggs 0 siblings, 2 replies; 14+ messages in thread From: Paul Moore @ 2020-04-17 21:53 UTC (permalink / raw) To: Richard Guy Briggs Cc: fw, LKML, Linux-Audit Mailing List, netfilter-devel, ebiederm, twoerner, Eric Paris, tgraf On Wed, Mar 18, 2020 at 5:33 PM Richard Guy Briggs <rgb@redhat.com> wrote: > On 2020-03-18 17:22, Paul Moore wrote: > > On Wed, Mar 18, 2020 at 9:12 AM Richard Guy Briggs <rgb@redhat.com> wrote: > > > On 2020-03-17 17:30, Richard Guy Briggs wrote: > > > > Some table unregister actions seem to be initiated by the kernel to > > > > garbage collect unused tables that are not initiated by any userspace > > > > actions. It was found to be necessary to add the subject credentials to > > > > cover this case to reveal the source of these actions. A sample record: > > > > > > > > type=NETFILTER_CFG msg=audit(2020-03-11 21:25:21.491:269) : table=nat family=bridge entries=0 op=unregister pid=153 uid=root auid=unset tty=(none) ses=unset subj=system_u:system_r:kernel_t:s0 comm=kworker/u4:2 exe=(null) > > > > > > Given the precedent set by bpf unload, I'd really rather drop this patch > > > that adds subject credentials. > > > > > > Similarly with ghak25's subject credentials, but they were already > > > present and that would change an existing record format, so it isn't > > > quite as justifiable in that case. > > > > Your comments have me confused - do you want this patch (v3 3/3) > > considered for merging or no? > > I would like it considered for merging if you think it will be required > to provide enough information about the event that happenned. In the > bpf unload case, there is a program number to provide a link to a > previous load action. In this case, we won't know for sure what caused > the table to be unloaded if the number of entries was empty. I'm still > trying to decide if it matters. For the sake of caution I think it > should be included. I don't like it, but I think it needs to be > included. I'm in the middle of building patches 1/3 and 2/3, assuming all goes well I'll merge them into audit/next (expect mail soon), however I'm going back and forth on this patch. Like you I kinda don't like it, and with both of us not in love with this patch I have to ask if there is certification requirement for this? I know about the generic subj/obj requirements, but in the case where there is no associated task/syscall/etc. information it isn't like the extra fields supplied in this patch are going to have much information in that regard; it's really the *absence* of that information which is telling. Which brings me to wonder if simply the lack of any associated records in this event is enough? Before when we weren't associating records into a single event it would have been a problem, but the way things currently are, if there are no other records (and you have configured that) then I think you have everything you need to know. Thoughts? -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH ghak25 v3 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister 2020-04-17 21:53 ` Paul Moore @ 2020-04-21 15:15 ` Steve Grubb 2020-04-21 18:54 ` Richard Guy Briggs 2020-04-21 20:19 ` Richard Guy Briggs 1 sibling, 1 reply; 14+ messages in thread From: Steve Grubb @ 2020-04-21 15:15 UTC (permalink / raw) To: linux-audit Cc: Richard Guy Briggs, fw, LKML, netfilter-devel, ebiederm, twoerner, Eric Paris, tgraf On Friday, April 17, 2020 5:53:47 PM EDT Paul Moore wrote: > On Wed, Mar 18, 2020 at 5:33 PM Richard Guy Briggs <rgb@redhat.com> wrote: > > On 2020-03-18 17:22, Paul Moore wrote: > > > On Wed, Mar 18, 2020 at 9:12 AM Richard Guy Briggs <rgb@redhat.com> wrote: > > > > On 2020-03-17 17:30, Richard Guy Briggs wrote: > > > > > Some table unregister actions seem to be initiated by the kernel to > > > > > garbage collect unused tables that are not initiated by any > > > > > userspace actions. It was found to be necessary to add the subject > > > > > credentials to cover this case to reveal the source of these > > > > > actions. A sample record: > > > > > type=NETFILTER_CFG msg=audit(2020-03-11 21:25:21.491:269) : > > > > > table=nat family=bridge entries=0 op=unregister pid=153 uid=root > > > > > auid=unset tty=(none) ses=unset > > > > > subj=system_u:system_r:kernel_t:s0 comm=kworker/u4:2 exe=(null) If this is the kernel, why is pid not 0? And if pid is 0, then isn't exe=/boot/vmlinuz-X.Y.Z-blah? > > > > Given the precedent set by bpf unload, I'd really rather drop this > > > > patch that adds subject credentials. <snip> > I'm in the middle of building patches 1/3 and 2/3, assuming all goes > well I'll merge them into audit/next (expect mail soon), however I'm > going back and forth on this patch. Like you I kinda don't like it, > and with both of us not in love with this patch I have to ask if there > is certification requirement for this? Yes, any change to information flow must be auditable. > I know about the generic > subj/obj requirements, but in the case where there is no associated > task/syscall/etc. information it isn't like the extra fields supplied > in this patch are going to have much information in that regard; it's > really the *absence* of that information which is telling. Exactly. But if someone does a search based on the fields, they need to be able to find this record. For example, suppose I want to know what actions have been performed by kernel_t, I can run a search and find this event. > Which brings me to wonder if simply the lack of any associated records in > this event is enough? Before when we weren't associating records into > a single event it would have been a problem, but the way things > currently are, if there are no other records (and you have configured > that) then I think you have everything you need to know. > > Thoughts? You can't search on the absense of information. There are some fields that have meaning. It's OK if they are unset. It happens for daemons, too. But we don't remove the fields because of it. It tells part of the story. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH ghak25 v3 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister 2020-04-21 15:15 ` Steve Grubb @ 2020-04-21 18:54 ` Richard Guy Briggs 0 siblings, 0 replies; 14+ messages in thread From: Richard Guy Briggs @ 2020-04-21 18:54 UTC (permalink / raw) To: Steve Grubb Cc: fw, LKML, linux-audit, netfilter-devel, ebiederm, twoerner, Eric Paris, tgraf On 2020-04-21 11:15, Steve Grubb wrote: > On Friday, April 17, 2020 5:53:47 PM EDT Paul Moore wrote: > > On Wed, Mar 18, 2020 at 5:33 PM Richard Guy Briggs <rgb@redhat.com> wrote: > > > On 2020-03-18 17:22, Paul Moore wrote: > > > > On Wed, Mar 18, 2020 at 9:12 AM Richard Guy Briggs <rgb@redhat.com> > wrote: > > > > > On 2020-03-17 17:30, Richard Guy Briggs wrote: > > > > > > Some table unregister actions seem to be initiated by the kernel to > > > > > > garbage collect unused tables that are not initiated by any > > > > > > userspace actions. It was found to be necessary to add the subject > > > > > > credentials to cover this case to reveal the source of these > > > > > > actions. A sample record: > > > > > > type=NETFILTER_CFG msg=audit(2020-03-11 21:25:21.491:269) : > > > > > > table=nat family=bridge entries=0 op=unregister pid=153 uid=root > > > > > > auid=unset tty=(none) ses=unset > > > > > > subj=system_u:system_r:kernel_t:s0 comm=kworker/u4:2 exe=(null) > > If this is the kernel, why is pid not 0? And if pid is 0, then isn't > exe=/boot/vmlinuz-X.Y.Z-blah? It isn't PID 0 because it is a kernel thread. > > > > > Given the precedent set by bpf unload, I'd really rather drop this > > > > > patch that adds subject credentials. > > <snip> > > > I'm in the middle of building patches 1/3 and 2/3, assuming all goes > > well I'll merge them into audit/next (expect mail soon), however I'm > > going back and forth on this patch. Like you I kinda don't like it, > > and with both of us not in love with this patch I have to ask if there > > is certification requirement for this? > > Yes, any change to information flow must be auditable. > > > I know about the generic > > subj/obj requirements, but in the case where there is no associated > > task/syscall/etc. information it isn't like the extra fields supplied > > in this patch are going to have much information in that regard; it's > > really the *absence* of that information which is telling. > > Exactly. But if someone does a search based on the fields, they need to be > able to find this record. For example, suppose I want to know what actions > have been performed by kernel_t, I can run a search and find this event. > > > Which brings me to wonder if simply the lack of any associated records in > > this event is enough? Before when we weren't associating records into > > a single event it would have been a problem, but the way things > > currently are, if there are no other records (and you have configured > > that) then I think you have everything you need to know. > > > > Thoughts? > > You can't search on the absense of information. There are some fields that > have meaning. It's OK if they are unset. It happens for daemons, too. But we > don't remove the fields because of it. It tells part of the story. > > -Steve > > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit - 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://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH ghak25 v3 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister 2020-04-17 21:53 ` Paul Moore 2020-04-21 15:15 ` Steve Grubb @ 2020-04-21 20:19 ` Richard Guy Briggs 1 sibling, 0 replies; 14+ messages in thread From: Richard Guy Briggs @ 2020-04-21 20:19 UTC (permalink / raw) To: Paul Moore Cc: fw, LKML, Linux-Audit Mailing List, netfilter-devel, ebiederm, twoerner, Eric Paris, tgraf On 2020-04-17 17:53, Paul Moore wrote: > On Wed, Mar 18, 2020 at 5:33 PM Richard Guy Briggs <rgb@redhat.com> wrote: > > On 2020-03-18 17:22, Paul Moore wrote: > > > On Wed, Mar 18, 2020 at 9:12 AM Richard Guy Briggs <rgb@redhat.com> wrote: > > > > On 2020-03-17 17:30, Richard Guy Briggs wrote: > > > > > Some table unregister actions seem to be initiated by the kernel to > > > > > garbage collect unused tables that are not initiated by any userspace > > > > > actions. It was found to be necessary to add the subject credentials to > > > > > cover this case to reveal the source of these actions. A sample record: > > > > > > > > > > type=NETFILTER_CFG msg=audit(2020-03-11 21:25:21.491:269) : table=nat family=bridge entries=0 op=unregister pid=153 uid=root auid=unset tty=(none) ses=unset subj=system_u:system_r:kernel_t:s0 comm=kworker/u4:2 exe=(null) > > > > > > > > Given the precedent set by bpf unload, I'd really rather drop this patch > > > > that adds subject credentials. > > > > > > > > Similarly with ghak25's subject credentials, but they were already > > > > present and that would change an existing record format, so it isn't > > > > quite as justifiable in that case. > > > > > > Your comments have me confused - do you want this patch (v3 3/3) > > > considered for merging or no? > > > > I would like it considered for merging if you think it will be required > > to provide enough information about the event that happenned. In the > > bpf unload case, there is a program number to provide a link to a > > previous load action. In this case, we won't know for sure what caused > > the table to be unloaded if the number of entries was empty. I'm still > > trying to decide if it matters. For the sake of caution I think it > > should be included. I don't like it, but I think it needs to be > > included. > > I'm in the middle of building patches 1/3 and 2/3, assuming all goes > well I'll merge them into audit/next (expect mail soon), however I'm > going back and forth on this patch. Like you I kinda don't like it, > and with both of us not in love with this patch I have to ask if there > is certification requirement for this? I know about the generic > subj/obj requirements, but in the case where there is no associated > task/syscall/etc. information it isn't like the extra fields supplied > in this patch are going to have much information in that regard; it's > really the *absence* of that information which is telling. Which > brings me to wonder if simply the lack of any associated records in > this event is enough? Before when we weren't associating records into > a single event it would have been a problem, but the way things > currently are, if there are no other records (and you have configured > that) then I think you have everything you need to know. > > Thoughts? I'm good dropping that third patch, but Steve's perspective is more authoritative here. I'll respin patch 1/3 and 2/3 to fix the checkpatch.pl errors if you prefer (was erroneously mentioned in ghak28 feedback). > paul moore - 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://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-04-21 20:20 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-17 21:30 [PATCH ghak25 v3 0/3] Address NETFILTER_CFG issues Richard Guy Briggs 2020-03-17 21:30 ` [PATCH ghak25 v3 1/3] audit: tidy and extend netfilter_cfg x_tables and ebtables logging Richard Guy Briggs 2020-03-18 21:54 ` Paul Moore 2020-03-18 22:00 ` Richard Guy Briggs 2020-03-18 22:09 ` Paul Moore 2020-03-17 21:30 ` [PATCH ghak25 v3 2/3] netfilter: add audit table unregister actions Richard Guy Briggs 2020-03-17 21:30 ` [PATCH ghak25 v3 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister Richard Guy Briggs 2020-03-18 13:11 ` Richard Guy Briggs 2020-03-18 21:22 ` Paul Moore 2020-03-18 21:33 ` Richard Guy Briggs 2020-04-17 21:53 ` Paul Moore 2020-04-21 15:15 ` Steve Grubb 2020-04-21 18:54 ` Richard Guy Briggs 2020-04-21 20:19 ` Richard Guy Briggs
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).