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=-6.6 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 94161C4338F for ; Tue, 24 Aug 2021 15:20:39 +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 1A2DD61265 for ; Tue, 24 Aug 2021 15:20:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1A2DD61265 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=schaufler-ca.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-400-33uXc8c9PX6atZNQyifYqQ-1; Tue, 24 Aug 2021 11:20:36 -0400 X-MC-Unique: 33uXc8c9PX6atZNQyifYqQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 440B8107B7C7; Tue, 24 Aug 2021 15:20:33 +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 47CF290A9; Tue, 24 Aug 2021 15:20:32 +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 E20064BB7C; Tue, 24 Aug 2021 15:20:30 +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 17OFKRFx009069 for ; Tue, 24 Aug 2021 11:20:27 -0400 Received: by smtp.corp.redhat.com (Postfix) id 99177D93D7; Tue, 24 Aug 2021 15:20:27 +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 94112176DC for ; Tue, 24 Aug 2021 15:20:23 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (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 6D531802A64 for ; Tue, 24 Aug 2021 15:20:23 +0000 (UTC) Received: from sonic314-26.consmr.mail.ne1.yahoo.com (sonic314-26.consmr.mail.ne1.yahoo.com [66.163.189.152]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-247-c5Phmi0pPJ6T0DZfRxotmA-1; Tue, 24 Aug 2021 11:20:21 -0400 X-MC-Unique: c5Phmi0pPJ6T0DZfRxotmA-1 X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1629818420; bh=3Bgf5nAE2e8Ykow5tPNKsycnXsReYkmVFEyprHkri1q=; h=X-Sonic-MF:Subject:To:From:Date:From:Subject; b=cz1Q0vYVs2UcVXokiwR7wIjIP8YwoRa3bHCEHzJxiJVwONy/gIse0RrDo6v3KnGGVPDPsQ/3b+NE6QEGsiEax/wyW5KqdcXXx3Ys/3G3tWMv7Ijs/nqHMt4kCGB11GO2jeyqpYG3vuVSPQMhJSWOwnqavD00cEeww9qAChJpctq7MpuNdFBMK5qZYNW//thPE8/8uqv+YCuA7NrKkuCL58rfFqeHI6MQ2M+T3L5Ay6pu1IUcft7HFWpcKTfXuXPb+fv8kanFoRH3IQbx5SRSr8u+l/wg8UczQF2PLrAPY+GFglvyGoaFxCyPTWEwGTs4OliFpwXTAIJPXyh4jhDtCA== X-YMail-OSG: pvtToPcVM1mLfz1wp0DEMllB0oqgcg8nhN75mUWsHIW54dg1PSRr4Y27LOfLpIp hLBKL1_8AnxEAbxD7LIzGJ_BR0UTl4N7B9yrYVghnoLR1LjQq7Ks41O780PZyN7drcw2YfxR.R7r H7d9vHrOI5HkTiuMi7UDqipvMeeaKm1JIkU0oSjDT0FVsuyBD_f0.A6udhTXkaI2o7g01IxC.V1H J44XGB46ym41Z3FSelIKCSf7FjsW_z5NpRXn.WjUWtbyTCX64bWMReW7V0miwD8JUWO2ulaePGjC 6RFAy2zwzsXjkpiRaSJAGbiAaR4QLwD5PysRPqVMMAArfSyDXOePjvtYFupsn4WNbgBZ.DOvOGXo G8BU9idxKKnN0c0PX_19dLDbkf0y3PMfNd3W4uCMi7Lz8PgYlcyXDSzc3nilu1sIliWTOxbO6rZO xSSccD3O6hkVXUDt3yo9XDZm0MlE6Gl_D1FjwH0oNsWdAwf0inccU5XIe6Itj_JTqxX641_bzwFA aUqcFTNhD8vHfMUnyUWMGOyylEPCcyHhroer_YGhy_fzzO1dMgsF_cNkOfEsabASzObC_aIzSR1H M1Jwax9PIWtEQi.NBtfYnCevsrzQ6OaVU3tCtp_7OEIPpQ15lY1RLI33FD6cUZYArnfxtl1c4f9d k8ckrfTCRtiriDt8WAy_QUmPdj.F.tDC0EsxZ5qjt72XNimZZy95DbKDD9KnaxvEf1rx.EHOuzUw 9j7bGOV.vlYBHiYqDIj7gGiAx9vEhOZDHxqM65a0fa2S29l1cIdyC0qufgPg1w5_U2RDfp.4XO1K Dcb2w73tpUB6BTzu14yF1t95VU7zCYz1.A32QgO35FG3f1_7U1QohAUN5WYK2_o9hFDLLm7z_gfj m3sYtdC92H9zFC.tpZaiQBT9.x_FTH6.M0dRKP6qvpEbRrHZwzLmpErYDkCCD7uElDPvufRWwcA. Yqog1gDyiz5CFuQtQV8lFNV0XbJfAZ7m0MxOmBA5h4X5FL6zUCbMiFyZBehEXfdyJT1Ags1.OyMu 8lsXHI7UKxB3mwDa4d.mI3m_l1FRcVRxejTZQ1jFQkNXmMZRn9_DOvJ7OA_mUu0KkXpKDkiqpiTW 7WCTyJuSyvTAIyJahwhw24m.tBw29nE2qwU0_Hb0GfReN7vtepCwebxEx0Lsp36YMbUC9_E0pg89 g8xseNG5m1QuszijqQmfW1ZSJuw2zp5SHoNNGBRpmCAJxV6eHXBW4_6wlO92U56dfDMPNa9ADPcs XVyUUVtXAyKORQIqAxNuN5c9cHc5a.cKIRVjvNxAppzsP7CQL8dQcsMIhPGcdRQ3DsQaPYbW9ayB 7fQZOOEEt2rkpL2IdoEVCsuH9ltEZxebUqn5jjZanPY50S84YhkOE6F8EfysylKGJXsaWNyfu.m3 _l_9U4HJoyTOduCuEMDjN7JgsJc57ILi1Dx7pLk1QinYTdbYVcz1hmkQm3MLUpHIZfjYb04cOi4o p5iWmZFsbsxwukzLzZQjIcjR4igEGUvzolgBoPNi2Qktzx30VrSQwhk25JFRR37e59NRhZIFdvRI rDhMOWncHwkVgLf3.NKKfDjv9o0MsJ3ToJ1oXT3nAVE2UTHFpJN3Qqut6SguN.ohdgwlX_WGyiSv 6z5EgjYtAiBHMt8PkxOY0Ri_6PpyTC4qU5MtfMjDWM8RC.lfGAr97PrJl27756rrmFaEPZsC3AoE 5lylI4_Gf0uKWx0g.pBSEOJEUoehEnZymNavsFOUsp_1Zv_ctHf4X.rd4JhYcs.U.sIu2gbiK_BN WBNMrB_fd6s9GIBH41DpnQLntAj5WtD5C_2GdN1s1Gjiu00PJBXGcYPb88mky3Wv9QukJe2ejuEC lpjHNwo3_cc8i4oIMNK8Yd1HImnVlqa_ebRibphEHyU1QC56LHtnwadXRQ5BLkaV5IS6nAweJSUQ huDPOvC3vOOTQzigNskhMWwv9orIL4Z4huqQZ_q7G_vpR5jgTzSacPYAMiSuVt8eOJHKm4LxivO2 V8mROfsVrSIpGx5dHxlpp5zlhnUnGXASGryvnrCvq_.r2bzjDVDxBd7Q0kUn9p7GACC9hOLgPtRY DPi0i7pefGilT7bcc2e89XlQk_OPSFjLCmb6A.EDRJh01.wjYxRq9Lx.x2fbecpr8W7Yba_xZQHY Pgvgetus8epw.zkmwvPZei0kU6kAjm4BmF1Z2EF25oqG83WWw.nbZNPr6IWlJg3GKEZmgN4QiloS Ukth1FOJW9g5Rk0qatOkYaJxQhW85x6HvtQ6OrGuJS40pDOVez3H_Vi.RtQY003f45rvz2zKFCg- - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Tue, 24 Aug 2021 15:20:20 +0000 Received: by kubenode549.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2f120471ee9629852333106d32263ef9; Tue, 24 Aug 2021 15:20:17 +0000 (UTC) Subject: Re: [PATCH v28 22/25] Audit: Add record for multiple process LSM attributes To: Paul Moore References: <20210722004758.12371-1-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> From: Casey Schaufler Message-ID: Date: Tue, 24 Aug 2021 08:20:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: 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.79 on 10.11.54.5 X-MIME-Autoconverted: from quoted-printable to 8bit by lists01.pubmisc.prod.ext.phx2.redhat.com id 17OFKRFx009069 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.84 on 10.5.11.23 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-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On 8/24/2021 7:45 AM, Paul Moore wrote: > 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. As I said, it's a hack-around that demonstrates the scope of the problem. Had you expressed enthusiastic approval for it I'd have been very surprised. > 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: I will give this a shot. > > * 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'll keep that in mind as I fiddle about. > [*] 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. Hmm. That effort has been quiet lately. Too quiet. -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit