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=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 D8104C4338F for ; Fri, 13 Aug 2021 15:32:04 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5D6D360F91 for ; Fri, 13 Aug 2021 15:32:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5D6D360F91 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=paul-moore.com Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=redhat.com 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-479-Ogr5MwqUNHStKWzAn5pOwA-1; Fri, 13 Aug 2021 11:32:02 -0400 X-MC-Unique: Ogr5MwqUNHStKWzAn5pOwA-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 E5C138799E0; Fri, 13 Aug 2021 15:31:57 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 523CE5FC23; Fri, 13 Aug 2021 15:31:57 +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 F00B3181A0F1; Fri, 13 Aug 2021 15:31:54 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 17DFVolZ006317 for ; Fri, 13 Aug 2021 11:31:50 -0400 Received: by smtp.corp.redhat.com (Postfix) id 57BB72051B0F; Fri, 13 Aug 2021 15:31:50 +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 146122051B80 for ; Fri, 13 Aug 2021 15:31:46 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id EC9311801387 for ; Fri, 13 Aug 2021 15:31:45 +0000 (UTC) Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-557-lPucQBjrPW2vVY-EA4-3yw-1; Fri, 13 Aug 2021 11:31:42 -0400 X-MC-Unique: lPucQBjrPW2vVY-EA4-3yw-1 Received: by mail-ej1-f50.google.com with SMTP id w5so19000533ejq.2 for ; Fri, 13 Aug 2021 08:31:42 -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=Ve/K1nImq2PU8YYguMvzsx7Eg1JRHGri3AQYtcGqZkk=; b=kO0nQH044lb6lpVhq7mq2IZ8pS/aY22uYl/m6PqNMG/jy1PdTOiP+l3pwM7R0r+ixy A1Nv8f7d6LGXHr1xLTPoUJ25hdCl4IlfktgvtJLC0aIK87GvPyNtl0t+DmEiBN7JRNTZ h5uzWKIccrRnPga/cUNMtCItJ9vBkWVOL0gl29g3W+62ySTx1eboBBPVOZBaOo2EGJMy v3K45r9AHP6arswqUrj3sshhHf+TQO0ro/MVtaCOdFnprOI/yjlrCUW+KJunMP9kXur1 zb7D9tm+lti4ODrSvvf6T5LVaH+K1PNh9lWRNaxJe8e9AP9/59M60qcy6e0fZ3GSeLld rh3A== X-Gm-Message-State: AOAM533TlPvjcxfCL2nnuUl0FGe/5r4hnefIO9Ggf3+a5ybvfzkVvK/W WYXM8GzfXriWm21iWMJGrMFFNk7dymRvktawQ0i3G0xr2cLq2W4= X-Google-Smtp-Source: ABdhPJzfrHtFxvKIOhIj5PBhYgIqJ6sQ5tzuGe8s7VbPSm9n5/yDFmEYvaONAeu2nk3S1lzGZWCurubpcxiodux0rLw= X-Received: by 2002:a17:906:779a:: with SMTP id s26mr3083213ejm.106.1628868701160; Fri, 13 Aug 2021 08:31:41 -0700 (PDT) MIME-Version: 1.0 References: <20210722004758.12371-1-casey@schaufler-ca.com> <20210722004758.12371-23-casey@schaufler-ca.com> In-Reply-To: From: Paul Moore Date: Fri, 13 Aug 2021 11:31:30 -0400 Message-ID: Subject: Re: [PATCH v28 22/25] Audit: Add record for multiple process LSM attributes To: Casey Schaufler X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-loop: linux-audit@redhat.com Cc: john.johansen@canonical.com, selinux@vger.kernel.org, netdev@vger.kernel.org, James Morris , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-audit@redhat.com, casey.schaufler@intel.com, Stephen Smalley 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.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=linux-audit-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, Aug 12, 2021 at 6:38 PM Casey Schaufler wrote: > On 8/12/2021 1:59 PM, Paul Moore wrote: > > On Wed, Jul 21, 2021 at 9:12 PM Casey Schaufler wrote: > >> Create a new audit record type to contain the subject information > >> when there are multiple security modules that require such data. ... > > The local > > audit context is a hack that is made necessary by the fact that we > > have to audit things which happen outside the scope of an executing > > task, e.g. the netfilter audit hooks, it should *never* be used when > > there is a valid task_struct. > > In the existing audit code a "current context" is only needed for > syscall events, so that's the only case where it's allocated. Would > you suggest that I track down the non-syscall events that include > subj= fields and add allocate a "current context" for them? I looked > into doing that, and it wouldn't be simple. This is why the "local context" was created. Prior to these stacking additions, and the audit container ID work, we never needed to group multiple audit records outside of a syscall context into a single audit event so passing a NULL context into audit_log_start() was reasonable. The local context was designed as a way to generate a context for use in a local function scope to group multiple records, however, for reasons I'll get to below I'm now wondering if the local context approach is really workable ... > > Hopefully that makes sense? > > Yes, it makes sense. Methinks you may believe that the current context > is available more regularly than it actually is. > > I instrumented the audit event functions with: > > WARN_ONCE(audit_context, "%s has context\n", __func__); > WARN_ONCE(!audit_context, "%s lacks context\n", __func__); > > I only used local contexts where the 2nd WARN_ONCE was hit. What does your audit config look like? Both the kernel command line and the output of 'auditctl -l' would be helpful. I'm beginning to suspect that you have the default we-build-audit-into-the-kernel-because-product-management-said-we-have-to-but-we-don't-actually-enable-it-at-runtime audit configuration that is de rigueur for many distros these days. If that is the case, there are many cases where you would not see a NULL current->audit_context simply because the config never allocated one, see kernel/auditsc.c:audit_alloc(). If that is the case, I'm honestly a little surprised we didn't realize that earlier, especially given all the work/testing that Richard has done with the audit container ID bits, but then again he surely had a proper audit config during his testing so it wouldn't have appeared. Good times. Regardless, assuming that is the case we probably need to find an alternative to the local context approach as it currently works. For reasons we already talked about, we don't want to use a local audit_context if there is the possibility for a proper current->audit_context, but we need to do *something* so that we can group these multiple events into a single record. Since this is just occurring to me now I need a bit more time to think on possible solutions - all good ideas are welcome - but the first thing that pops into my head is that we need to augment audit_log_end() to potentially generated additional, associated records similar to what we do on syscall exit in audit_log_exit(). Of course the audit_log_end() changes would be much more limited than audit_log_exit(), just the LSM subject and audit container ID info, and even then we might want to limit that to cases where the ab->ctx value is NULL and let audit_log_exit() handle it otherwise. We may need to store the event type in the audit_buffer during audit_log_start() so that we can later use that in audit_log_end() to determine what additional records are needed. Regardless, let's figure out why all your current->audit_context values are NULL first (report back on your audit config please), I may be worrying about a hypothetical that isn't real. -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit