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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4686C433EF for ; Fri, 4 Mar 2022 14:43:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239936AbiCDOok (ORCPT ); Fri, 4 Mar 2022 09:44:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48894 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239928AbiCDOof (ORCPT ); Fri, 4 Mar 2022 09:44:35 -0500 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 764F41BD06F for ; Fri, 4 Mar 2022 06:43:47 -0800 (PST) Received: by mail-ej1-x632.google.com with SMTP id bg10so17975079ejb.4 for ; Fri, 04 Mar 2022 06:43:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9EdPYiVYFEGT7WXfdTQ+DM8Rd0Oojjp9HvMnxorUW0w=; b=2j4G/eCC5cV6nb3yTMvSO4aNKmommilMbdTyKZIgLCh6pbC0rCz0DMiqWj6OV3ivwN yFepQ49oQyQm0bvgi0cqP5Ipc7SrYCUGLYXQjM91bSqh2D1AX5tAE6Buc5MMQLjzqBVV sQ0hHlSbXynWvtz3J6lkHx2XbwAHOBT5nfATFDiPjxeb6nvrP4uURtDtR03NCEh7ayHW F6x65vtBMZWhuzj1JiuJS5pKPOuA7iU3/OAkiwoLOmlU3Q/jPcjs1VLp/eOMHxIhWyQC 47jSjsq7S2TrP6pxOJGMEGDuz9/FizoFlMz0PvFNDhJeyGBejzD71WEoLr4LkyDgAm0m BYtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9EdPYiVYFEGT7WXfdTQ+DM8Rd0Oojjp9HvMnxorUW0w=; b=Uaq/GlmaAm26fYMuJsk1pX5CaDCbkysKauPQgz7PqXUAg4iN/ETirhYLZjX/5rDbbx 10b6V9bPImNAoYqCC5TnB0HkmNqKac84WYo/fBcgyZEQpLrDwW6GXHT1lymKijT0C3l0 Tkt2mxsZhwO2gGLlEk2obhmGKzJKcstSoWgLqbtICmHEGq3GBkTmb52bGuJ1ImvvMG72 5YxFyN/SYtzW8D0ECthEMXF3uU+/ql5DkRsAB6Jh5faFiQ52blMvdU+W+fHMspJMyN3D PCBD1ZgTYlIV/RvqsPnDCORz7G9MRieyc5BHdzR7AJNh6O41nUUIC0WTtkem7a3bdC/x 53+Q== X-Gm-Message-State: AOAM533aZagy/aQ7NkoxuEhreSuXbeXTbpBg9NxXGeArUhHVhyvbh+3y o1y+sRSWsmFXlXf0hGaYgzcn4hw+i1344YFi62RP X-Google-Smtp-Source: ABdhPJwYUPmHIXmuKyRCCCuUwU1LnQ4xS2DnqMVUc3W2/V05vUsnDQ9LEnCVCgEeQJeBjV1s2lpXWERkfieRwSRzXkc= X-Received: by 2002:a17:907:da6:b0:6da:8f3f:d563 with SMTP id go38-20020a1709070da600b006da8f3fd563mr6651337ejc.112.1646405025870; Fri, 04 Mar 2022 06:43:45 -0800 (PST) MIME-Version: 1.0 References: <20220202235323.23929-1-casey@schaufler-ca.com> <20220202235323.23929-25-casey@schaufler-ca.com> <0bbd2d61-415f-08f2-251e-2dd6b8991d6a@schaufler-ca.com> In-Reply-To: <0bbd2d61-415f-08f2-251e-2dd6b8991d6a@schaufler-ca.com> From: Paul Moore Date: Fri, 4 Mar 2022 09:43:34 -0500 Message-ID: Subject: Re: [PATCH v32 24/28] Audit: Add framework for auxiliary records To: Casey Schaufler Cc: casey.schaufler@intel.com, jmorris@namei.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, linux-audit@redhat.com, keescook@chromium.org, john.johansen@canonical.com, penguin-kernel@i-love.sakura.ne.jp, sds@tycho.nsa.gov, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 3, 2022 at 9:13 PM Casey Schaufler wrote: > On 3/3/2022 3:36 PM, Paul Moore wrote: > > Adding a new aux record would involve calling some private audit > > function (no one outside of the audit subsystem should need access) > > that would allocate a new skb similar to what we do in > > audit_buffer_alloc() and add it to the end of the sk_buff_head list > > via skb_queue_tail() and resetting audit_buffer::skb to point to the > > newly allocated skb. > > Good naming may be tricky as we need to indicate that a new buffer is > being allocated for an attached aux record and that the buffer to which > it's being attached is going to temporarily be in a curious state. > audit_buffer_add_aux() seems wordy, but it's what I'll start with lacking > a better suggestion. I agree that it will leave the audit_buffer in an odd state, at least with the current definition of the audit_buffer. However, this is mitigated by the restriction that the only callers should be within the audit subsystem. Here is some quick pseudo-code mockup of what I'm thinking: /* on success, ab->skb will point to the new aux record */ static int audit_buffer_aux_new(struct audit_buffer *ab, int type) { WARN_ON(ab->skb != skb_peek(&ab->skb_list)); ab->skb = nlmsg_new(AUDIT_BUFSIZ, ab->gfp_mask); if (!ab->skb) goto err; if (!nlmsg_put(ab->skb, 0, 0, type, 0, 0)) goto err; skb_queue_tail(&ab->skb_list); return 0; err: kfree_skb(&ab->skb); ab->skb = skb_peek(&ab->skb_list); return -ENOMEM; } /* restores the "main" record into ab->skb */ static void audit_buffer_aux_end(struct audit_buffer *ab) { ab->skb = skb_peek(&ab->skb_list); } /* free the current aux record and reset ab->skb to the "main" */ static void audit_buffer_aux_cancel(struct audit_buffer *ab) { if (ab->skb != skb_peek_tail(&ab->skb_list)) { BUG(); return; } ab->skb = skb_peek(&ab->skb_list); kfree_skb(skb_dequeue_tail(&ab->skb_list)); } -- paul-moore.com 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 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D2A7FC433FE for ; Fri, 4 Mar 2022 14:44:27 +0000 (UTC) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-133-W4iWsfS3MN2sputw4zAqlw-1; Fri, 04 Mar 2022 09:44:23 -0500 X-MC-Unique: W4iWsfS3MN2sputw4zAqlw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 96FDE80205C; Fri, 4 Mar 2022 14:44:19 +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 BCAB91059104; Fri, 4 Mar 2022 14:44:18 +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 0AB6D1809CB2; Fri, 4 Mar 2022 14:44:17 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 224Ehmhl009775 for ; Fri, 4 Mar 2022 09:43:48 -0500 Received: by smtp.corp.redhat.com (Postfix) id 58CC540C1244; Fri, 4 Mar 2022 14:43:48 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast07.extmail.prod.ext.rdu2.redhat.com [10.11.55.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 54CB2404779C for ; Fri, 4 Mar 2022 14:43:48 +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 383173C01C1E for ; Fri, 4 Mar 2022 14:43:48 +0000 (UTC) Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-183-JhVyoVqKNya4OSjyNLhDNw-2; Fri, 04 Mar 2022 09:43:46 -0500 X-MC-Unique: JhVyoVqKNya4OSjyNLhDNw-2 Received: by mail-ej1-f53.google.com with SMTP id gb39so17927055ejc.1 for ; Fri, 04 Mar 2022 06:43:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9EdPYiVYFEGT7WXfdTQ+DM8Rd0Oojjp9HvMnxorUW0w=; b=whBDMnXdO2StZ69a1uUwSN6bnQwkBddcP08XKIAbL89d5e35HauOsWfBjuroKxgU4D M3p1PlrG8hkro8ZsdgrQxCtsq/hm9Kvx77Vn5ThNxxgfB3gEYtierysljaqZuKmwYP6R joDnqO7LySnKHd+lji9Fkk7wAePceC3mxYddMI0Tb+OAdGKTIkRHLEAdgq8IGOvryai5 EdIRgOxEvckFxMCKtsfvN/E0Q5NlSbLdsKTv2kCKen4tRJLuD7TGPcqq05RN/rDQo/Py xJscl1R6h0SBNZMKlkvDNoS8JFwLHraD7yhdXPtaTE3ep0RfwJpB83GI3GN54XJA4Mq4 9HaA== X-Gm-Message-State: AOAM5318+zKRuN4eJDvLWAbEQsR/W8WV/xTf4A0pzp2uzTuq/Vso+6s6 CPA8b8v+Rz8clutQT6iUlmcr2IR4zd9u+rLgQtitOoSfkS+y X-Google-Smtp-Source: ABdhPJwYUPmHIXmuKyRCCCuUwU1LnQ4xS2DnqMVUc3W2/V05vUsnDQ9LEnCVCgEeQJeBjV1s2lpXWERkfieRwSRzXkc= X-Received: by 2002:a17:907:da6:b0:6da:8f3f:d563 with SMTP id go38-20020a1709070da600b006da8f3fd563mr6651337ejc.112.1646405025870; Fri, 04 Mar 2022 06:43:45 -0800 (PST) MIME-Version: 1.0 References: <20220202235323.23929-1-casey@schaufler-ca.com> <20220202235323.23929-25-casey@schaufler-ca.com> <0bbd2d61-415f-08f2-251e-2dd6b8991d6a@schaufler-ca.com> In-Reply-To: <0bbd2d61-415f-08f2-251e-2dd6b8991d6a@schaufler-ca.com> From: Paul Moore Date: Fri, 4 Mar 2022 09:43:34 -0500 Message-ID: Subject: Re: [PATCH v32 24/28] Audit: Add framework for auxiliary records 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.84 on 10.11.54.2 X-loop: linux-audit@redhat.com Cc: john.johansen@canonical.com, selinux@vger.kernel.org, jmorris@namei.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-audit@redhat.com, casey.schaufler@intel.com, sds@tycho.nsa.gov 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.22 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, Mar 3, 2022 at 9:13 PM Casey Schaufler wrote: > On 3/3/2022 3:36 PM, Paul Moore wrote: > > Adding a new aux record would involve calling some private audit > > function (no one outside of the audit subsystem should need access) > > that would allocate a new skb similar to what we do in > > audit_buffer_alloc() and add it to the end of the sk_buff_head list > > via skb_queue_tail() and resetting audit_buffer::skb to point to the > > newly allocated skb. > > Good naming may be tricky as we need to indicate that a new buffer is > being allocated for an attached aux record and that the buffer to which > it's being attached is going to temporarily be in a curious state. > audit_buffer_add_aux() seems wordy, but it's what I'll start with lacking > a better suggestion. I agree that it will leave the audit_buffer in an odd state, at least with the current definition of the audit_buffer. However, this is mitigated by the restriction that the only callers should be within the audit subsystem. Here is some quick pseudo-code mockup of what I'm thinking: /* on success, ab->skb will point to the new aux record */ static int audit_buffer_aux_new(struct audit_buffer *ab, int type) { WARN_ON(ab->skb != skb_peek(&ab->skb_list)); ab->skb = nlmsg_new(AUDIT_BUFSIZ, ab->gfp_mask); if (!ab->skb) goto err; if (!nlmsg_put(ab->skb, 0, 0, type, 0, 0)) goto err; skb_queue_tail(&ab->skb_list); return 0; err: kfree_skb(&ab->skb); ab->skb = skb_peek(&ab->skb_list); return -ENOMEM; } /* restores the "main" record into ab->skb */ static void audit_buffer_aux_end(struct audit_buffer *ab) { ab->skb = skb_peek(&ab->skb_list); } /* free the current aux record and reset ab->skb to the "main" */ static void audit_buffer_aux_cancel(struct audit_buffer *ab) { if (ab->skb != skb_peek_tail(&ab->skb_list)) { BUG(); return; } ab->skb = skb_peek(&ab->skb_list); kfree_skb(skb_dequeue_tail(&ab->skb_list)); } -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit