Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp435727ybz; Tue, 21 Apr 2020 11:56:47 -0700 (PDT) X-Google-Smtp-Source: APiQypLDqY0a/0pWu3VDg/1RXQd06dfxmb2Dj7tNADtqv5ng0bcKAW3jsVLpshZD+e57w8zWOPLE X-Received: by 2002:a17:906:7f0c:: with SMTP id d12mr22300148ejr.40.1587495407635; Tue, 21 Apr 2020 11:56:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587495407; cv=none; d=google.com; s=arc-20160816; b=dDTFbMR5CHzuV8vf0TBxU2HllW289EBjuo/AX5kw6YBhyvk6nP3ily7rC4ps2123kO JtVWb0WlY2HVFWNDaHKqmdL+4aHUSea4Q4g+PfwysOrvU6Rr9q4JQgeNcx/MgK9O5mbK wjOPKtO+FAFDJ8Mt1cYYQQ3OH/18PZnEp+2HBm8bNig+2R5oPMS0CQGvNjjqj5J20tFt 4CHvMmV5RDX3JHSWL/c70rwl71hufe6cxwnCd2QQlC8EE8cPfNkRZA2yDDmC4TIXf7eU Hik2f0kRo/Ky+32yQvMVGb+GQCQULOKMOse6L57N0UGm+Erf8FjAc/MCORU2c7ZIvNSm yccg== 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=MrU2HNJZTQBPSn2z8yAKMiwd+9c1Olx+Jq2ydnHE1vM=; b=yyGMu2mRuTxnnLCbyOiFxPu8EtccdM7cDuCkwKF+6kCY01wz794HZvKgfb7ax039Tv /gVfQVbWnOD5o6YxAhgIFgLACAR4G63b/5l2cm/YVRwTn59qkmJoU6O+Tgg6Ci3XYXxg zyTkV57RuGUhwuXF0R96p5z5Mddds5FLb7cxuIPYww+Gt62QGTbh9RLbbGZSXc3sB6L7 m4gQPiZHSBUejGh48guu7/z8wRvBMmEKUvHKqXyxQbUBle41A8+V6hpK1NpuXnV04wyg E/X3tYhWPcIbKvt5jSpK/wg50/rma15845TvnkIAfd0y/b40biufKIy7A3dvUnErAogk CC0w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=MA5GTdLk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id u22si2021001eja.142.2020.04.21.11.56.23; Tue, 21 Apr 2020 11:56:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=MA5GTdLk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1726001AbgDUSyl (ORCPT + 99 others); Tue, 21 Apr 2020 14:54:41 -0400 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:46942 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725870AbgDUSyl (ORCPT ); Tue, 21 Apr 2020 14:54:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587495278; 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=MrU2HNJZTQBPSn2z8yAKMiwd+9c1Olx+Jq2ydnHE1vM=; b=MA5GTdLk/icqwNSbDV6VbGrESZfdKtB4Wx43GM6vHaIdABLilkeTvGjVV26iBWVVHzwTMs t+vu7ncqEIhzBtQU1HPWiOe9aylsAClmr2zI6UTYvQ3uGN0OC97Z+yy4o4M9dwmwRY3uhx /tXA1sFnzsaZxbDXsgWkhNqkCRQWhjc= 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-465-7PWAMLsjMYaygNzxcEJMOg-1; Tue, 21 Apr 2020 14:54:34 -0400 X-MC-Unique: 7PWAMLsjMYaygNzxcEJMOg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 44AC01083E80; Tue, 21 Apr 2020 18:54:33 +0000 (UTC) Received: from madcap2.tricolour.ca (unknown [10.3.128.9]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7C5471001B30; Tue, 21 Apr 2020 18:54:25 +0000 (UTC) Date: Tue, 21 Apr 2020 14:54:22 -0400 From: Richard Guy Briggs To: Steve Grubb Cc: linux-audit@redhat.com, fw@strlen.de, LKML , netfilter-devel@vger.kernel.org, ebiederm@xmission.com, twoerner@redhat.com, Eric Paris , tgraf@infradead.org Subject: Re: [PATCH ghak25 v3 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister Message-ID: <20200421185422.ziu2ejdvuofg5fu5@madcap2.tricolour.ca> References: <20200318213327.ow22q6nnjn3ijq6v@madcap2.tricolour.ca> <2156032.xcGZvdN1jG@x2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2156032.xcGZvdN1jG@x2> User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 wrote: > > > On 2020-03-18 17:22, Paul Moore wrote: > > > > On Wed, Mar 18, 2020 at 9:12 AM Richard Guy Briggs > 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. > > > > > 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 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