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 9256EC4338F for ; Fri, 13 Aug 2021 20:44:25 +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 22BEA6109E for ; Fri, 13 Aug 2021 20:44:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 22BEA6109E 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-261-0W-kpslnM3eH8nwv8nUKQw-1; Fri, 13 Aug 2021 16:44:22 -0400 X-MC-Unique: 0W-kpslnM3eH8nwv8nUKQw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 08CA18015C7; Fri, 13 Aug 2021 20:44: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 8CFA660939; Fri, 13 Aug 2021 20:44:17 +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 28BB74BB7C; Fri, 13 Aug 2021 20:44:16 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 17DKhZMr010826 for ; Fri, 13 Aug 2021 16:43:36 -0400 Received: by smtp.corp.redhat.com (Postfix) id CB54E20B6644; Fri, 13 Aug 2021 20:43:35 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast03.extmail.prod.ext.rdu2.redhat.com [10.11.55.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C695220C17BB for ; Fri, 13 Aug 2021 20:43:33 +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 4E81C801005 for ; Fri, 13 Aug 2021 20:43:33 +0000 (UTC) Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-401-vdWkhzOEMmql1jVZ9AX1sw-1; Fri, 13 Aug 2021 16:43:31 -0400 X-MC-Unique: vdWkhzOEMmql1jVZ9AX1sw-1 Received: by mail-ed1-f51.google.com with SMTP id g21so3388390edw.4 for ; Fri, 13 Aug 2021 13:43:30 -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=iRAplBayhxWymKoWiC0WoyTJpbQvWuYgJ79F91VPsGY=; b=GXGFMjcRR59mOqpz8GjkGReuckE+Y3dct1rtHTyuWsj54VdBWANPjFShsUpBPHHnFS TQOW8SV733IIhoT7Mx2oU+rcuBKvIjwt094WiUi5MXd7PIXz2IrJPq3Eh67NhnpaabCD e+L0rKdBvi9LrEwJmVcJaSCqDFY7Pbr5I9FgQSLqmBLFKE8L9+1ypQu8rPvs0sC0NRM/ 80CaFtFr4yA2OShWJGbs5YwIMepwgF26u1Evm8wWU7HfzmDNB9LUJC+l46iw8ji1lSMH LG0B90OKuQM23mAs9d1U9d3V/w9d59gIhSddFPPBkHgY0UPdVq4gXUi4eI6MTrVPE6Px ADAw== X-Gm-Message-State: AOAM532Gz/B2TtZlGyxsc0NF2ExdupTvuqpTA8Sw/vKG/a8T1ivmeRMo ep7ilnSveE8lakLR0uaC6gWDEjwv7uTkLmnVYEfo X-Google-Smtp-Source: ABdhPJzuZlbMX/SZdVH8AI8TEUryb01jMYyYASTBqkbdK5gus1OBuQz4ggC/DrTs2bokQflB8Rq6ia+jQ/0sJBH4L2c= X-Received: by 2002:aa7:d982:: with SMTP id u2mr5423505eds.164.1628887409671; Fri, 13 Aug 2021 13:43:29 -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 16:43:18 -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.4 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.13 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 Fri, Aug 13, 2021 at 2:48 PM Casey Schaufler wrote: > On 8/13/2021 8:31 AM, Paul Moore wrote: > > 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 ... > > I haven't found a place where it didn't work. What is the concern? The concern is that use of a local context can destroy any hopes of linking with other related records, e.g. SYSCALL and PATH records, to form a single cohesive event. If the current task_struct is valid for a given function invocation then we *really* should be using current's audit_context. However, based on our discussion here it would seem that we may have some issues where current->audit_context is not being managed correctly. I'm not surprised, but I will admit to being disappointed. > > What does your audit config look like? Both the kernel command line > > and the output of 'auditctl -l' would be helpful. > > On the fedora system: > > BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.14.0-rc5stack+ > root=/dev/mapper/fedora-root ro resume=/dev/mapper/fedora-swap > rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap lsm.debug > > -a always,exit -F arch=b64 -S bpf -F key=testsuite-1628714321-EtlWIphW > > On the Ubuntu system: > > BOOT_IMAGE=/boot/vmlinuz-5.14.0-rc1stack+ > root=UUID=39c25777-d413-4c2e-948c-dfa2bf259049 ro lsm.debug > > No rules The Fedora system looks to have some audit-testsuite leftovers, but that shouldn't have an impact on what we are discussing; in both cases I would expect current->audit_context to be allocated and non-NULL. > > 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. > > Yes, but I've also fiddled about with it so as to get better event coverage. > I've run the audit-testsuite, which has got to fiddle about with the audit > configuration. Yes, it looks like my hunch was wrong. > > 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(). > > I assume you mean that I *would* see a NULL current->audit_context > in the "event not enabled" case. Yep, typo. > > 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. > > I tried a couple things, but neither was satisfactory. > > > 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(). > > I looked into that. You need a place to save the timestamp > that doesn't disappear. That's the role the audit_context plays > now. Yes, I've spent a few hours staring at the poorly planned struct that is audit_context ;) Regardless, the obvious place for such a thing is audit_buffer; we can stash whatever we need in there. > > 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 > > That's what's maddening, and why I implemented audit_alloc_for_lsm(). > They aren't all NULL. Sometimes current->audit_context is NULL, > sometimes it isn't, for the same event. I thought it might be a > question of the netlink interface being treated specially, but > that doesn't explain all the cases. Your netlink changes are exactly what made me think, "this is obviously wrong", but now I'm wondering if a previously held assumption of "current is valid and points to the calling process" in the case of the kernel servicing netlink messages sent from userspace. Or rather, perhaps that assumption is still true but something is causing current->audit_context to be NULL in that case. Friday the 13th indeed. -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit