From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9393DC433E1 for ; Mon, 18 May 2020 14:41:26 +0000 (UTC) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3B98F207C4 for ; Mon, 18 May 2020 14:41:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="M8hbaPlf" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3B98F207C4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=paul-moore.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-audit-bounces@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589812885; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=iJi5x9ekTbzPCrDRsP33ZUc6evuicKEHs3UK6zl2H4Y=; b=M8hbaPlfdyhwelX3hlGSRoGXbOpWuJ+k+fK9CPDXdmcgj/kYuC2AKM5cL0gwhLsFbU9jsX 1jW+pweEk451hG6bP4b4ZdewFmB/xk15UYRBNsq2WHGBPXv1Ttw4DhfntJfyGrLgypyavS 7eogc3uQFHgeJOmw+sErkN7lZAgJZ9g= 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-192-sOkJlwcAMIOeygkmVC512Q-1; Mon, 18 May 2020 10:41:23 -0400 X-MC-Unique: sOkJlwcAMIOeygkmVC512Q-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B6668846363; Mon, 18 May 2020 14:41:19 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BF5636EA2B; Mon, 18 May 2020 14:41:15 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 5CB394ED59; Mon, 18 May 2020 14:41:12 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 04IEf9vW020507 for ; Mon, 18 May 2020 10:41:09 -0400 Received: by smtp.corp.redhat.com (Postfix) id 4CE5942ADC; Mon, 18 May 2020 14:41:09 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast06.extmail.prod.ext.rdu2.redhat.com [10.11.55.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3A9D842AB3 for ; Mon, 18 May 2020 14:41:07 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 37C9C1801235 for ; Mon, 18 May 2020 14:41:07 +0000 (UTC) Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-324-t0ydeSQrN2yckOjge1kzvA-1; Mon, 18 May 2020 10:41:04 -0400 X-MC-Unique: t0ydeSQrN2yckOjge1kzvA-1 Received: by mail-ed1-f67.google.com with SMTP id d24so728978eds.11 for ; Mon, 18 May 2020 07:41:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y82Wa/YXfbo2pFIdBdGJ5l3oNnVnkoqZdsw/qlj3M4k=; b=VSlrYlO9kGEbUepUvhpgG2nTMnLhjG1e/iF7vvM1V34+2FNyWZJ5psiDQjJrpqoTj7 gypWju9kWL1yaLfIaGC5YPqLCbVni89/8Ki9DW0EDoSX8F8VNwyBJlhgEAvRV0oXPcI3 IoDYJp3LSl74DhEGRPYIV/JaQf5ep8+aehG8pFwAR9WphMm4OH68DnVJOkdunEDIFFlK t8N45+zn1CLEbHdfOU7RPuzhXekGrhJ93+pjby7263OZ/Ku6iRncyC3neY1HaLzrGEET o8HItm6tofyQKwFJwzERKRm0t0wBcfooj7aDrwbEhxxhLbSWuhmf7gH647xWMFZwYxzL t4lA== X-Gm-Message-State: AOAM533fPj9B6gn+BRtunlpFACQgaxriq2euMHFYQHPFbwWe6PWQj5LD bnatl90ypELsYwjrTPUgagHI7PATSRlw4lZUv1Qv X-Google-Smtp-Source: ABdhPJyHfxZF3XvBBGLabJM0/+o/cd616yVwBWifbH+ohTirews3dIdk9TsgbL7HFPKM75iLATnYzm6t2UWOCMa2+zo= X-Received: by 2002:aa7:c887:: with SMTP id p7mr13686147eds.269.1589812862499; Mon, 18 May 2020 07:41:02 -0700 (PDT) MIME-Version: 1.0 References: <20200517141515.qqx3jx5ulb2546tx@madcap2.tricolour.ca> <20200518003920.e6vyzhvadyi5wdjd@madcap2.tricolour.ca> In-Reply-To: <20200518003920.e6vyzhvadyi5wdjd@madcap2.tricolour.ca> From: Paul Moore Date: Mon, 18 May 2020 10:40:51 -0400 Message-ID: Subject: Re: [PATCH ghak25 v4 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister To: Richard Guy Briggs X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-loop: linux-audit@redhat.com Cc: fw@strlen.de, LKML , Linux-Audit Mailing List , netfilter-devel@vger.kernel.org, ebiederm@xmission.com, twoerner@redhat.com, Eric Paris , tgraf@infradead.org X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sun, May 17, 2020 at 8:40 PM Richard Guy Briggs wrote: > On 2020-05-17 17:50, Paul Moore wrote: > > On Sun, May 17, 2020 at 10:15 AM Richard Guy Briggs wrote: > > > On 2020-04-28 18:25, Paul Moore wrote: > > > > On Wed, Apr 22, 2020 at 5:40 PM 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) > > > > > > > > [I'm going to comment up here instead of in the code because it is a > > > > bit easier for everyone to see what the actual impact might be on the > > > > records.] > > > > > > > > Steve wants subject info in this case, okay, but let's try to trim out > > > > some of the fields which simply don't make sense in this record; I'm > > > > thinking of fields that are unset/empty in the kernel case and are > > > > duplicates of other records in the userspace/syscall case. I think > > > > that means we can drop "tty", "ses", "comm", and "exe" ... yes? > > > > > > > > While "auid" is a potential target for removal based on the > > > > dup-or-unset criteria, I think it falls under Steve's request for > > > > subject info here, even if it is garbage in this case. > > > > > > Can you explain why auid falls under this criteria but ses does not if > > > both are unset? > > > > "While "auid" is a potential target for removal based on the > > dup-or-unset criteria, I think it falls under Steve's request for > > subject info here, even if it is garbage in this case." > > > > It's a concession to Steve. As I mentioned previously, I think the > > subject info is bogus in this case; either it is valid and we get it > > from the SYSCALL record or it simply isn't present in any meaningful > > way. > > Sorry for being so dense. I still don't follow your explanation. You've > repeated the same paragraph that didn't make sense to me the first time. > > What definition of "subject info" are you working with? The subject is generally the task which is causing the event to occur, "subject info" would be any such attribute which describes the subject; examples include LSM label, the various UIDs/GIDs, etc.. Think "current->cred" and you on the right track. > I had assumed > it was the set of fields that contain information that came from that > task's struct task_struct. Some of those fields contain information > that isn't helpful. Why not remove them all rather than keep one that > still contains no useful information? Once again - and I don't know how else to explain this to you - I think it is pointless to record the subject info in this record as we either have that info from other records in the event or there is no valid subject info to record. As you state in the commit description: "Some table unregister actions seem to be initiated by the kernel to garbage collect unused tables that are not initiated by any userspace actions." > Or is it a matter of keeping one > key field that contains no useful information that proves that the rest > is bogus? Steve said that daemons leave no useful information in auid > as well, so I don't see how keeping this field helps us. My > understanding is that the subj field's "...:kernel_t:..." is the key > here and that pid and comm give us a bit more of a clue that it is a > kernel thread. Is that correct? What use does including auid serve > here? As I've mentioned in the thread above, including the auid was done as a concession to Steve, I don't think it serves any useful purpose. -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit