Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp21771765ybl; Mon, 6 Jan 2020 10:56:34 -0800 (PST) X-Google-Smtp-Source: APXvYqyYcdMIzIlNVvkLT8p/I0SoIAjt/4R3cu9J8nLNnfMX2JqvVkMppiFH2YFskRfSgjkChF+i X-Received: by 2002:a05:6830:145:: with SMTP id j5mr112888977otp.242.1578336994584; Mon, 06 Jan 2020 10:56:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578336994; cv=none; d=google.com; s=arc-20160816; b=To/lsXSsSd7I5Z4F0pU8FsSydj+vQOFUD4mEj5vQQ4TXOUZND/OvyNqz+wiYc/SxdN 2dISsKOTVOw3fitypB9U/BBhzQVoeq3CgUksaMoo5gz82cxvlsdH38jEuH7pAZTj5/Cc nM0jZMhv28D/3vkLbCujsbOlTn+KedgKYImJyCvDKE7RdqZpSK7VD5cfRga6bGRS4Ps2 VUrLrgYZ63hR16srtbB/IJh35DTxSIBcQUioHAVWLxxi85ATg4gDZrt4bkmaKPX0wU1F 0fD8LToYr2Ga13gmHGw4xskyi5WQG/JFLstV/owJ/in6QmGvGxTZtAAorAC+R1EHTaTw BWrw== 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=zUi4N5K5yW5gkKkEx9fAnGxorkBR0dJVBcurzQJwTuk=; b=Iy+5m9kSO9Q635AmF9NRLnVtR+jh1eCC3Fp3fgsLmj3L6KMIW8BhKNQiNtRwW2+3dy pxXMVK/jXuTHb4k/MozysuFa+iC7ixdyGzBRo86sAob2zcx0QNtyS55J77nu16xanF9U 5K5uQR23z/8nn9H84Hch6hdHx6950xpKCZuXziI9ywdEm16MhgdihgJ5WVuu89WzUCza gBI23zexldzEKOjcGsRfcBYy0iB1M6myuUaec4ccC7NzoxyH0C6rOX3bCcugmMz+RoM7 qXR7Idmmtrcr8eg00EELyuoVJwCyc9DvXSeGcyKKTZw2yWezv/kezE9hQAYCHtGke+Qe 02wQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JwctZzld; 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 b25si33785834otp.212.2020.01.06.10.56.09; Mon, 06 Jan 2020 10:56:34 -0800 (PST) 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=JwctZzld; 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 S1726699AbgAFSyz (ORCPT + 99 others); Mon, 6 Jan 2020 13:54:55 -0500 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:35672 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726569AbgAFSyz (ORCPT ); Mon, 6 Jan 2020 13:54:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578336893; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=zUi4N5K5yW5gkKkEx9fAnGxorkBR0dJVBcurzQJwTuk=; b=JwctZzldfn+z8TO/cf0bY+nkf46HiQe/Ug5SvOjb5mk0pYY2UaOTH8sTWbxJxvhGDy0eRN oMipnJnesMaVwOzhhVJNAOVFGRi4A/PJ2gCL0tSx7YcrBYQhRCzCV+6sUejAzoVxAYEXG1 jcPYCXYAb9DwI2puyKv9VORD/qgOYws= 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-270-tlzUX1MoMjOHblyFlKcliA-1; Mon, 06 Jan 2020 13:54:50 -0500 X-MC-Unique: tlzUX1MoMjOHblyFlKcliA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 39AF5800D48; Mon, 6 Jan 2020 18:54:49 +0000 (UTC) Received: from madcap2.tricolour.ca (ovpn-112-34.phx2.redhat.com [10.3.112.34]) by smtp.corp.redhat.com (Postfix) with ESMTP id 76E3A5D9E5; Mon, 6 Jan 2020 18:54:40 +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 v2 0/9] Address NETFILTER_CFG issues Date: Mon, 6 Jan 2020 13:54:01 -0500 Message-Id: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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 setsockopt: iptables-restore, ip6tables-restore, ebtables-restore unshare: (h?)ostnamed clone: libvirtd The syscall events unsolicited by any audit rule were found to be caused by a missing !audit_dummy_context() check before creating a NETFILTER_CFG record and issuing the record immediately rather than saving the information to create the record at syscall exit. Check !audit_dummy_context() before creating the NETFILTER_CFG record. 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. The !audit_dummy_context() check above should avoid them. 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. Table unregistration was never logged, which is now covered. 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: 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 (9): netfilter: normalize x_table function declarations netfilter: normalize ebtables function declarations netfilter: normalize ebtables function declarations II audit: record nfcfg params netfilter: x_tables audit only on syscall rule netfilter: ebtables audit only on syscall rule netfilter: ebtables audit table registration netfilter: add audit operation field netfilter: audit table unregister actions include/linux/audit.h | 11 ++++ kernel/auditsc.c | 18 +++++ net/bridge/netfilter/ebtables.c | 142 ++++++++++++++++++++-------------------- net/netfilter/x_tables.c | 56 +++++++--------- 4 files changed, 124 insertions(+), 103 deletions(-) -- 1.8.3.1