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 BCCBDC4320A for ; Tue, 24 Aug 2021 14:45:45 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.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 64DAF61220 for ; Tue, 24 Aug 2021 14:45:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 64DAF61220 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-12-2noh_bwCOhmLjvM9INWakg-1; Tue, 24 Aug 2021 10:45:43 -0400 X-MC-Unique: 2noh_bwCOhmLjvM9INWakg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 86785192CC47; Tue, 24 Aug 2021 14:45:39 +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 E64E5620DE; Tue, 24 Aug 2021 14:45:38 +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 3E9334A713; Tue, 24 Aug 2021 14:45:38 +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 17OEjZmi005762 for ; Tue, 24 Aug 2021 10:45:35 -0400 Received: by smtp.corp.redhat.com (Postfix) id 8384E2138CE9; Tue, 24 Aug 2021 14:45:35 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast01.extmail.prod.ext.rdu2.redhat.com [10.11.55.17]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7E7AD2138CEA for ; Tue, 24 Aug 2021 14:45:31 +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-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8B58E866DFB for ; Tue, 24 Aug 2021 14:45:31 +0000 (UTC) Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-174-K6bbX7hlOMe1K9dBc22j4g-1; Tue, 24 Aug 2021 10:45:28 -0400 X-MC-Unique: K6bbX7hlOMe1K9dBc22j4g-1 Received: by mail-ed1-f48.google.com with SMTP id d6so32165474edt.7 for ; Tue, 24 Aug 2021 07:45:27 -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=NGYM+nSaUU+WoSwLMVnhosx4OKbywoUeevoN8omCjXI=; b=fKOviRKFqd5YVluP+mQx5YD5gM79AGx2DuCTumTY+pD8huJssKaY04Oe8TN2ukhWlB ssoOF6dedAmC8ecSpRV8dA1TCYSK6QhAMlAX3Pha1Y1OAUzaPuw4ju1xMvoqVIc9D58r l3WBx5ZoZrSCuNu8i8nllb+1Bytm4jBVaBATrJO/6W6+JnCh8UomNFCQFfGVdlDJfvXm Ne4kByo08mjToSx9gyGOm/MNWEvur6DmZVcFDAdOTQIKWBRX4ZLaSmuFafW4NxqEBsI0 MSzlF+N4ogtf7n5l191o8b/gB1O+955IJjM6uHeLWZsuMcx3KeVZ2lL61/x8ggDu1i27 VY6Q== X-Gm-Message-State: AOAM531LfEuQ5OpKC/eq8F+ldbsndZ1fYWi1HW1sOteQG0mzyjmKJ+VM TLOP5PeAlLadojM1Fp/DGr2HZyV0Myyb0mcy6gNo X-Google-Smtp-Source: ABdhPJzUQNFZ76OJidu5ZnOAPqidwPTAgucoSeldGoH3rBmrNnTDQK/YtmgsG9PpDDQGvmE36qPj2R6wKLqMgCCH3ZY= X-Received: by 2002:a05:6402:1246:: with SMTP id l6mr43168604edw.12.1629816326536; Tue, 24 Aug 2021 07:45:26 -0700 (PDT) MIME-Version: 1.0 References: <20210722004758.12371-1-casey@schaufler-ca.com> <20210722004758.12371-23-casey@schaufler-ca.com> <3ebad75f-1887-bb31-db23-353bfc9c0b4a@schaufler-ca.com> <062ba5f9-e4e8-31f4-7815-826f44b35654@schaufler-ca.com> <6f219a4d-8686-e35a-6801-eb66f98c8032@schaufler-ca.com> <93d97b1e-d3ea-0fe0-f0c2-62db09d01889@schaufler-ca.com> In-Reply-To: From: Paul Moore Date: Tue, 24 Aug 2021 10:45:15 -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, James Morris , 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.11 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 20, 2021 at 7:48 PM Casey Schaufler wrote: > > On 8/20/2021 12:06 PM, Paul Moore wrote: > >> Unless you explicitly enable audit on the kernel cmdline, e.g. > >> "audit=1", processes started before userspace enables audit will not > >> have a properly allocated audit_context; see the "if > >> (likely(!audit_ever_enabled))" check at the top of audit_alloc() for > >> the reason why. > > I found a hack-around that no one will like. I changed that check to be > > (likely(!audit_ever_enabled) && !lsm_multiple_contexts()) > > It probably introduces a memory leak and/or performance degradation, > but it has the desired affect. I can't speak for everyone, but I know I don't like that as a solution ;) I imagine such a change would also draw the ire of the never-audit crowd and the distros themselves. However, I understand the need to just get *something* in place so you can continue to test/develop; it's fine to keep that for now, but I'm going to be very disappointed if that line finds its way into the next posted patchset revision. I'm very much open to ideas but my gut feeling is that the end solution is going to be changes to audit_log_start() and audit_log_end(). In my mind the primary reason for this hunch is that support for multiple LSMs[*] needs to be transparent to the various callers in the kernel; this means the existing audit pattern of ... audit_log_start(...); audit_log_format(...); audit_log_end(...); ... should be preserved and be unchanged from what it is now. We've already talked in some general terms about what such changes might look like, but to summarize the previous discussions, I think we would need to think about the following things: * Adding a timestamp/serial field to the audit_buffer struct, it could even be in a union with the audit_context pointer as we would never need both at the same time: if the audit_context ptr is non-NULL you use that, otherwise you use the timestamp. The audit_buffer timestamp would not eliminate the need for the timestamp info in the audit_context struct for what I hope are obvious reasons. * Additional logic in audit_log_end() to generate additional ancillary records for LSM labels. This will likely mean storing the message "type" passed to audit_log_start() in the audit_record struct and using that information in audit_log_end() to decide if a LSM ancillary record is needed. Logistically this would likely mean converting the existing audit_log_end() function into a static/private __audit_log_end() and converting audit_log_end() into something like this: void audit_log_end(ab) { __audit_log_end(ab); // rm the ab cleanup from __audit_log_end if (ab->anc_mlsm) { // generate the multiple lsm record } audit_buffer_free(ab); } * Something else that I'm surely forgetting :) At the end of all this we may find that the "local" audit_context concept is no longer needed. It was originally created to deal with grouping ancillary records with non-syscall records into a single event; while what we are talking about above is different, I believe that our likely solution will also work to solve the original "local" audit_context use case as well. We'll have to see how this goes. [*] I expect that the audit container ID work will have similar issues and need a similar solution, I'm surprised it hasn't come up yet. -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit