Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp4213172ybh; Tue, 17 Mar 2020 14:33:03 -0700 (PDT) X-Google-Smtp-Source: ADFU+vs3VzswyYefbAG7+ybs86MfOAONdo0iWHphgVNYbfOZV3uHQS2NLwN/xieuffiweMUt7WcY X-Received: by 2002:aca:b60a:: with SMTP id g10mr750852oif.102.1584480783381; Tue, 17 Mar 2020 14:33:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584480783; cv=none; d=google.com; s=arc-20160816; b=HMUb/s1Tg15Xyu6gNQHDSj9ItSiNlZeczvCRCqiJI83HtNp/cbajQRJw1Az5NzByon 0IAgmTzEDl9mxhnwJXSGIo8XyEwUBlimQYvecAxi5uOLder24b2U5v7isOs5Z7T7C4pO BcSvvQl9XFjr4j3ExjU709hsRYjA2XB7mc8V+nsWmUcUO1uXXyd8pzozZ24WM+nuNVqi v9xJdUBDzirjRazToXh1DyDaAkSfRmhF3RXELpitsLdnAI5nE5y8gy/SvCg03C6QyB1B wGgnpihyo4ctEEohNuwKSzURMhx3XmT1vwLEEXRA7GJcrFr7O33DjUy6sYNLl0yJwmVJ NxWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature; bh=2WVvdeTWNDlkBf1UYF7ufANAKZfT3CWdgizs+joyuIg=; b=qjWzsUhaeMnPTp7bmLIwvp3nIKHDxdzIX6VSt4I223f1mnCNSyqLiRDYLXRoL/+WOt W0KmbNUxHyfhoOTXB1EL7rvDFn31qeeR9eSgF+cLtQTtvukOkp2jcDgs4PV2FvR6Urvs 0pECu7enHik1OZdwLM+E6BmofDTjjgr/5xuQxetH8O7keZPWImc8rwwia2+6xRZLBx7W 2BfbV1cfuyLDsizxCLFNHedw9nfAmyDTJj/2SzSjnvxPPqw3TQTqYuHrW40jSEYcJqb0 jqoWA+BQa0CfcyL2G8bSfdgJ7cRIwqWWflkv+U5QbXvE2AyxtJXL4+cb+HdjkFqu/HeR Atfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dFpf16B8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t144si2109780oie.129.2020.03.17.14.32.49; Tue, 17 Mar 2020 14:33:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dFpf16B8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726980AbgCQVbT (ORCPT + 99 others); Tue, 17 Mar 2020 17:31:19 -0400 Received: from us-smtp-delivery-74.mimecast.com ([216.205.24.74]:43867 "EHLO us-smtp-delivery-74.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726971AbgCQVbT (ORCPT ); Tue, 17 Mar 2020 17:31:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1584480678; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=2WVvdeTWNDlkBf1UYF7ufANAKZfT3CWdgizs+joyuIg=; b=dFpf16B8LGsFUT12EXAyNxjQXhwQtYpirb3l7C7uOmXA75Be9vpUy1KFFUx1U6fDP1qi/V uJbv7ih0K0ITRLd/fcpTszoI9CcCvAaY2pbjr/4JdvJoFQ/82bQhj+InlITLfzVFd/YnBp Ou6ET91YhsLc8w9ftjP0FWrTY3MHbBk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-15-1LYPfGhpNeeDHQCKnLc0Jw-1; Tue, 17 Mar 2020 17:31:14 -0400 X-MC-Unique: 1LYPfGhpNeeDHQCKnLc0Jw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 063B218B647D; Tue, 17 Mar 2020 21:31:13 +0000 (UTC) Received: from madcap2.tricolour.ca (unknown [10.36.110.5]) by smtp.corp.redhat.com (Postfix) with ESMTP id 28DB619C58; Tue, 17 Mar 2020 21:31:00 +0000 (UTC) From: Richard Guy Briggs To: Linux-Audit Mailing List , LKML , netfilter-devel@vger.kernel.org Cc: Paul Moore , sgrubb@redhat.com, omosnace@redhat.com, fw@strlen.de, twoerner@redhat.com, eparis@parisplace.org, ebiederm@xmission.com, tgraf@infradead.org, Richard Guy Briggs Subject: [PATCH ghak25 v3 0/3] Address NETFILTER_CFG issues Date: Tue, 17 Mar 2020 17:30:21 -0400 Message-Id: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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