On Wed, May 24, 2017 at 2:09 PM, Richard Guy Briggs <r...@redhat.com> wrote: > On 2017-05-24 19:36, Pablo Neira Ayuso wrote: >> On Thu, May 18, 2017 at 01:21:49PM -0400, Richard Guy Briggs wrote: >> > There were syscall events unsolicited by any audit rule caused by a missing >> > !audit_dummy_context() check before creating an >> > iptables/ip6tables/arptables/ebtables NETFILTER_CFG record. Check >> > !audit_dummy_context() before creating the NETFILTER_CFG record. >> > >> > The vast majority of observed 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. The !audit_dummy_context() check above should avoid >> > them. Audit only when there is an existing syscall audit rule, otherwise >> > issue >> > a standalone record only on table modification rather than empty table >> > creation. >> > >> > Add subject attributes to the new standalone NETFILTER_CFGSOLO record using >> > a newly exported audit_log_task(). >> >> This new NETFILTER_CFGSOLO looks like audit infra is missing some way >> to export a revision / context to userspace? It's duplicating quite a >> bit of the code from what I can see in this patch. > > Interesting you brought that up. I did another revision that stores > this information in a struct audit_context and greatly simplifies the > code in netfilter and re-uses code in audit itself, which may be a > better way to go, but that idea needed to settle a bit more before > seeing peer review. > > I'm also having doubts about two record types.
Richard and I had a discussion about this a week (or two?) ago and I'm currently of the opinion that two record types are a mistake. I agree that we need to add the audit_dummy_context() check but the other changes in this patch I'm less excited about. -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
