Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp8365619ybl; Thu, 16 Jan 2020 15:26:12 -0800 (PST) X-Google-Smtp-Source: APXvYqwIVJoFpTkP7bcXSiBEmfb8iABg4xVdpMdlC/bnG+8L/7MATvqNDU8HvxelfRFoPzXTwB8p X-Received: by 2002:a9d:5545:: with SMTP id h5mr4202716oti.296.1579217172179; Thu, 16 Jan 2020 15:26:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579217172; cv=none; d=google.com; s=arc-20160816; b=C7pO+/TvYiSWMJ2xRcCg2nCmZ+mb3ZbcNeZJdCAsfAMqYGSEtYeGJEvIOCSEsO2LNg 4nSNqOyNi2U2hd0oajroUJGloUqxQIUjNV2OubzNkHBelAieJY2MumupaPwB1I96geNL /VY8qzH8nQVRmpuMQLLz8tjslptPqPXVvbb1cnJUYPucgxaSI3OC/oKSWVyvI/sDbYd1 +bceeUH/42QH1uF4IOj7Y5nYvdDLvhew7Xt/CcjYQ6pSwHQUIkdMjEHjDaolUGfDUB9r /LofYlKIEKzM3eWumfsNYXBhnxKyMM4I0QxnrYu6gHRW5uD27AAGIyUfOtG04mm1KYvu FMfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=OWaRr6h+fYNYUWtshSDDFH28gfR7IxTJvOjH91SRqww=; b=Crz2yMRY7557pm8dUn7ZhrSqnawg3YlPyeK8aHgxU4oyFo54iagNogd7kWIAl1XaLE DS7wrDX7IZdMy6RYQfWKUGafOlIb0CajoxxCahmjk4DMhhMLbqgv5AGNLTJWPTMO7MHy HEdrn7mxX2VAHGahTjwAtnVGe8ftsdxcqk6/3164z/3kgu92JUbjSDZh7D4ZPTd8ZaQk NR2qo8LCuC4ZxkVLP3yVEWdDQq9KSIN4cEzkCvo6zYw+VLaQw2kt2hk5kJVEqfu9c1cc MkdlZQgmW81aT2WbThFhXQqJzBQu2vOUVU194lX1pA5s3N2YHW3aUue1wi1kXkt3JD48 qD3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Mti82Zxl; 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 w16si12556158oih.154.2020.01.16.15.26.00; Thu, 16 Jan 2020 15:26:12 -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=Mti82Zxl; 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 S2388610AbgAPVUl (ORCPT + 99 others); Thu, 16 Jan 2020 16:20:41 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:48127 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729005AbgAPVUk (ORCPT ); Thu, 16 Jan 2020 16:20:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579209640; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=OWaRr6h+fYNYUWtshSDDFH28gfR7IxTJvOjH91SRqww=; b=Mti82Zxlnol8AC4xPAL4CuX28iBmgvYocu4H4SmFlvCFvJVO2Zne8/1m1nvhvT4Wsxupry b7531qL9Z27b7WRjaYsQOAN9q8/r9lMxUoQ5i0/TROWAQehBs3xs99iBILoXGsxHREulSQ mjme+KkZISr0PcoWzSE03pKfdfS6hsQ= 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-341-aRIPpYMsNemd0-_0kzL7SQ-1; Thu, 16 Jan 2020 16:20:38 -0500 X-MC-Unique: aRIPpYMsNemd0-_0kzL7SQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 114888017CC; Thu, 16 Jan 2020 21:20:36 +0000 (UTC) Received: from madcap2.tricolour.ca (ovpn-112-12.phx2.redhat.com [10.3.112.12]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5ED1B5C545; Thu, 16 Jan 2020 21:20:26 +0000 (UTC) Date: Thu, 16 Jan 2020 16:20:23 -0500 From: Richard Guy Briggs To: Paul Moore Cc: Pablo Neira Ayuso , Linux-Audit Mailing List , LKML , netfilter-devel@vger.kernel.org, sgrubb@redhat.com, omosnace@redhat.com, fw@strlen.de, twoerner@redhat.com, Eric Paris , ebiederm@xmission.com, tgraf@infradead.org Subject: Re: [PATCH ghak25 v2 0/9] Address NETFILTER_CFG issues Message-ID: <20200116212023.w2ylqqmf654hwuvq@madcap2.tricolour.ca> References: <20200116150518.gfmzixoqagmk77rw@salvia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-01-16 14:07, Paul Moore wrote: > On Thu, Jan 16, 2020 at 10:05 AM Pablo Neira Ayuso wrote: > > On Mon, Jan 06, 2020 at 01:54:01PM -0500, Richard Guy Briggs wrote: > > > 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 > > > > What tree is this batch targeted to? > > I believe Richard was targeting this for the audit tree. Yes, sorry Pablo, it is against audit/next based on v5.5-rc1 > paul moore - RGB -- Richard Guy Briggs 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