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 A1769C433EF for ; Tue, 15 Mar 2022 23:48:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352617AbiCOXtK (ORCPT ); Tue, 15 Mar 2022 19:49:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57480 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352611AbiCOXtI (ORCPT ); Tue, 15 Mar 2022 19:49:08 -0400 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3168E17A80 for ; Tue, 15 Mar 2022 16:47:55 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id qt6so814163ejb.11 for ; Tue, 15 Mar 2022 16:47:55 -0700 (PDT) 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=iNpw6JDKnJaStDEQbMYrPng7QK8NBZw/YfwumvcctfY=; b=ZGYr0lbTpqSXCrncIFe6/Lj89SdYYP4TM4gHBHfTsuM22VWEhR90xBr0C1R99ME+8O WuUpt+J+HcscaS/VYB7OXORa+KyLrSmn/Mrcvvt6KYnZFVLFwUJpuQfAYUQCdWc2/YmC c1DEzYLOugHUd+So11xTXTUU6/fPgsdRWf1ZFyJbCI8x/PNOCDd1BI2H6xVrnBBl1OWi 4DQNUnhE3cGOO4onK3IMkXzaOaQAnH/Av8MucrLgmSfb2zet0YzBCsp1FOF4E8p9MvfU iqlAsSWHXQXwpNCPne85eaW/uLZZjMV4Vl3cycxPg2a6wziEXORozYkE9cHbLLPZtLwW +aCg== 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=iNpw6JDKnJaStDEQbMYrPng7QK8NBZw/YfwumvcctfY=; b=Lz+KHoqX8gaE5CtVldfim15vz0w9JIT7YZZTGBGcKPhQGGF11evOKoLjpoGHBZr/NR OAkp8z7DB+Za+LT0dz/43hlIWXqId5XzWU021fM9GGtyUdhinjBTZyV7mCR/iKNpAOVK VdcJvnTVoc3V81q4FoBqqQgrgP/78AmoiRA33AdXENLkpTll9f+SSULGxdo97lCSUZo8 MJYMeQRfx2KH/gdBxuajNKBLoNCLLNJuqU9ozkijrV3amOZsKzAlEWWpE/kdff/UMBAY zOI0SS248XYblCI4yOj0CCd6HrvMo5an6jWhZGhfVAAogfnLClwaLXiofHyUcZt8b3CQ DEHg== X-Gm-Message-State: AOAM532qjqi+cukGNnADfRsbg8unV7BDk2skwB7r2V1qOYKPjKqaqO0r D0oHhSz/UBWA0E1xMxSElyaFyXZOuZ+HBmsAevgF X-Google-Smtp-Source: ABdhPJwMDlgE3Rds0dK2V8kz4+cLHiA+xeH+Eh7vcPSUa6dPbkcRxZpueixswjtw6dKgS/n9D+D+3VIT66j4Gb3g0zU= X-Received: by 2002:a17:907:97c1:b0:6da:bd15:cca0 with SMTP id js1-20020a17090797c100b006dabd15cca0mr24579091ejc.327.1647388073631; Tue, 15 Mar 2022 16:47:53 -0700 (PDT) MIME-Version: 1.0 References: <20220310234632.16194-1-casey@schaufler-ca.com> <20220310234632.16194-27-casey@schaufler-ca.com> In-Reply-To: <20220310234632.16194-27-casey@schaufler-ca.com> From: Paul Moore Date: Tue, 15 Mar 2022 19:47:42 -0400 Message-ID: Subject: Re: [PATCH v33 26/29] Audit: Add record for multiple task security contexts 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, stephen.smalley.work@gmail.com, 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 10, 2022 at 6:59 PM Casey Schaufler wrote: > > Create a new audit record AUDIT_MAC_TASK_CONTEXTS. > An example of the MAC_TASK_CONTEXTS (1420) record is: > > type=MAC_TASK_CONTEXTS[1420] > msg=audit(1600880931.832:113) > subj_apparmor=unconfined > subj_smack=_ > > When an audit event includes a AUDIT_MAC_TASK_CONTEXTS record > the "subj=" field in other records in the event will be "subj=?". > An AUDIT_MAC_TASK_CONTEXTS record is supplied when the system has > multiple security modules that may make access decisions based > on a subject security context. > > Functions are created to manage the skb list in the audit_buffer. > > Signed-off-by: Casey Schaufler > --- > include/uapi/linux/audit.h | 1 + > kernel/audit.c | 104 ++++++++++++++++++++++++++++++++----- > 2 files changed, 93 insertions(+), 12 deletions(-) > > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h > index 8eda133ca4c1..af0aaccfaf57 100644 > --- a/include/uapi/linux/audit.h > +++ b/include/uapi/linux/audit.h > @@ -143,6 +143,7 @@ > #define AUDIT_MAC_UNLBL_STCDEL 1417 /* NetLabel: del a static label */ > #define AUDIT_MAC_CALIPSO_ADD 1418 /* NetLabel: add CALIPSO DOI entry */ > #define AUDIT_MAC_CALIPSO_DEL 1419 /* NetLabel: del CALIPSO DOI entry */ > +#define AUDIT_MAC_TASK_CONTEXTS 1420 /* Multiple LSM task contexts */ > > #define AUDIT_FIRST_KERN_ANOM_MSG 1700 > #define AUDIT_LAST_KERN_ANOM_MSG 1799 > diff --git a/kernel/audit.c b/kernel/audit.c > index 4713e66a12af..ad825af203cf 100644 > --- a/kernel/audit.c > +++ b/kernel/audit.c > @@ -2147,8 +2147,65 @@ void audit_log_key(struct audit_buffer *ab, char *key) > audit_log_format(ab, "(null)"); > } > > +/* > + * A brief note on aux record management. > + * > + * Aux records are allocated and added to the skb list of > + * the "main" record. The ab->skb is reset to point to the > + * aux record on its creation. When the aux record in complete ^^ "is" > + * ab->skb has to be reset to point to the "main" record. > + * This allows the audit_log_ functions to be ignorant of > + * which kind of record it is logging to. It also avoids adding > + * special data for aux records. > + */ It might be good to move the above comment into the audit_buffer_aux_new() comment header (below) so it does not get misplaced. > +/** > + * audit_buffer_aux_new - Add an aux record buffer to the skb list > + * @ab: audit_buffer > + * @type: message type > + * > + * On success ab->skb will point to the new aux record. > + * Returns 0 on success, -ENOMEM should allocation fail. > + */ > +static int audit_buffer_aux_new(struct audit_buffer *ab, int type) ... > @@ -2157,16 +2214,44 @@ int audit_log_task_context(struct audit_buffer *ab) > if (!lsmblob_is_set(&blob)) > return 0; > > - error = security_secid_to_secctx(&blob, &context, LSMBLOB_FIRST); > + if (!lsm_multiple_contexts()) { > + error = security_secid_to_secctx(&blob, &context, > + LSMBLOB_FIRST); > + if (error) { > + if (error != -EINVAL) > + goto error_path; > + return 0; > + } > > - if (error) { > - if (error != -EINVAL) > + audit_log_format(ab, " subj=%s", context.context); > + security_release_secctx(&context); > + } else { > + /* Multiple LSMs provide contexts. Include an aux record. */ > + audit_log_format(ab, " subj=?"); > + error = audit_buffer_aux_new(ab, AUDIT_MAC_TASK_CONTEXTS); > + if (error) > goto error_path; > - return 0; > + for (i = 0; i < LSMBLOB_ENTRIES; i++) { > + if (blob.secid[i] == 0) > + continue; > + error = security_secid_to_secctx(&blob, &context, i); > + if (error) { > + if (error != -EINVAL) > + audit_panic("error in audit_log_task_context"); > + audit_log_format(ab, "%ssubj_%s=?", > + i ? " " : "", > + lsm_slot_to_name(i)); I wonder if it might be better to record the "subj_smack=?" field before checking @error and potentially calling audit_panic(). In practice it likely shouldn't matter, I feel better if we at least record the subject information before we call the wildcard that is audit_panic(). > + } else { > + audit_log_format(ab, "%ssubj_%s=%s", > + i ? " " : "", > + lsm_slot_to_name(i), > + context.context); > + security_release_secctx(&context); > + } > + } > + audit_buffer_aux_end(ab); > } > > - audit_log_format(ab, " subj=%s", context.context); > - security_release_secctx(&context); > return 0; > > error_path: > @@ -2382,13 +2467,8 @@ int audit_signal_info(int sig, struct task_struct *t) > } > > /** > - * __audit_log_end - end one audit record > + * __audit_log_end - send one audit record If we want to be very nit-picky here, "end" is more correct than "send". First, audit_log_end() doesn't actually send the record, it just queues the record for the kauditd_thread which then attempts to send it. Second, there is no guarantee that the record will actually be sent at this point, although it would be nice if that were true :) > * @skb: the buffer to send > - * > - * We can not do a netlink send inside an irq context because it blocks (last > - * arg, flags, is not set to MSG_DONTWAIT), so the audit buffer is placed on a > - * queue and a kthread is scheduled to remove them from the queue outside the > - * irq context. May be called in any context. > */ This should probably be moved to patch 25/29 as it has more to do with the __audit_log_end() introduction than this patch. -- 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.133.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 36D24C433F5 for ; Tue, 15 Mar 2022 23:48:04 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-258-kKH22YgqPIiWKgXZLHWB0g-1; Tue, 15 Mar 2022 19:47:59 -0400 X-MC-Unique: kKH22YgqPIiWKgXZLHWB0g-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 572A8185A79C; Tue, 15 Mar 2022 23:47:58 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 465FD40D2820; Tue, 15 Mar 2022 23:47:58 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id EFC1919451EC; Tue, 15 Mar 2022 23:47:57 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id D6B7319452D2 for ; Tue, 15 Mar 2022 23:47:56 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id C847940D2821; Tue, 15 Mar 2022 23:47:56 +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 C423A40D2820 for ; Tue, 15 Mar 2022 23:47:56 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-2.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 AD9DB85A5A8 for ; Tue, 15 Mar 2022 23:47:56 +0000 (UTC) Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-278-ITRc7Vn9MNKdBuy6J3wCcw-1; Tue, 15 Mar 2022 19:47:55 -0400 X-MC-Unique: ITRc7Vn9MNKdBuy6J3wCcw-1 Received: by mail-ej1-f44.google.com with SMTP id r13so866795ejd.5 for ; Tue, 15 Mar 2022 16:47:54 -0700 (PDT) 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=iNpw6JDKnJaStDEQbMYrPng7QK8NBZw/YfwumvcctfY=; b=Ll6RP0d+Fa0RqIkBEtg8yLrTxRRYuXKDgxeM519ZT1XAJU3xadTAQKI90+etdniXoH xYcG7kWxL802yhH/EnIVq/hKhdOKUhCDEDcTYlU8Hi8ezBGJOCTaur50xfYOcNIefVLW xY++9XoZ4ESsMMnW34Kbnfx+FYwt0c5MGCybjk/hJkNTruPmM3mZWplXQQw5cbhH4uOL mS0gGRPovnCTdRWs0SYJyQGqMBiJcWyq2IUOEMEPeMMmWUSzphBqD0+1y/KDnFRSDqJS kxx2TCHKzU66nw1GgSB1KLlME9Rucch3eWFF+AkY0hSIsuM6rDwk5PijYHGmhggxQpMh 60sw== X-Gm-Message-State: AOAM533htTzruCAodO5jS409k4BEfFTnlZlN0ctMlJGsNML9l8BhzV7w PTuiOf+ZwLVk/0ui37fk0C7NsPJXwQweBp0NLRSXPdVe0g== X-Google-Smtp-Source: ABdhPJwMDlgE3Rds0dK2V8kz4+cLHiA+xeH+Eh7vcPSUa6dPbkcRxZpueixswjtw6dKgS/n9D+D+3VIT66j4Gb3g0zU= X-Received: by 2002:a17:907:97c1:b0:6da:bd15:cca0 with SMTP id js1-20020a17090797c100b006dabd15cca0mr24579091ejc.327.1647388073631; Tue, 15 Mar 2022 16:47:53 -0700 (PDT) MIME-Version: 1.0 References: <20220310234632.16194-1-casey@schaufler-ca.com> <20220310234632.16194-27-casey@schaufler-ca.com> In-Reply-To: <20220310234632.16194-27-casey@schaufler-ca.com> From: Paul Moore Date: Tue, 15 Mar 2022 19:47:42 -0400 Message-ID: Subject: Re: [PATCH v33 26/29] Audit: Add record for multiple task security contexts 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-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Errors-To: linux-audit-bounces@redhat.com Sender: "Linux-audit" X-Scanned-By: MIMEDefang 2.84 on 10.11.54.2 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 10, 2022 at 6:59 PM Casey Schaufler wrote: > > Create a new audit record AUDIT_MAC_TASK_CONTEXTS. > An example of the MAC_TASK_CONTEXTS (1420) record is: > > type=MAC_TASK_CONTEXTS[1420] > msg=audit(1600880931.832:113) > subj_apparmor=unconfined > subj_smack=_ > > When an audit event includes a AUDIT_MAC_TASK_CONTEXTS record > the "subj=" field in other records in the event will be "subj=?". > An AUDIT_MAC_TASK_CONTEXTS record is supplied when the system has > multiple security modules that may make access decisions based > on a subject security context. > > Functions are created to manage the skb list in the audit_buffer. > > Signed-off-by: Casey Schaufler > --- > include/uapi/linux/audit.h | 1 + > kernel/audit.c | 104 ++++++++++++++++++++++++++++++++----- > 2 files changed, 93 insertions(+), 12 deletions(-) > > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h > index 8eda133ca4c1..af0aaccfaf57 100644 > --- a/include/uapi/linux/audit.h > +++ b/include/uapi/linux/audit.h > @@ -143,6 +143,7 @@ > #define AUDIT_MAC_UNLBL_STCDEL 1417 /* NetLabel: del a static label */ > #define AUDIT_MAC_CALIPSO_ADD 1418 /* NetLabel: add CALIPSO DOI entry */ > #define AUDIT_MAC_CALIPSO_DEL 1419 /* NetLabel: del CALIPSO DOI entry */ > +#define AUDIT_MAC_TASK_CONTEXTS 1420 /* Multiple LSM task contexts */ > > #define AUDIT_FIRST_KERN_ANOM_MSG 1700 > #define AUDIT_LAST_KERN_ANOM_MSG 1799 > diff --git a/kernel/audit.c b/kernel/audit.c > index 4713e66a12af..ad825af203cf 100644 > --- a/kernel/audit.c > +++ b/kernel/audit.c > @@ -2147,8 +2147,65 @@ void audit_log_key(struct audit_buffer *ab, char *key) > audit_log_format(ab, "(null)"); > } > > +/* > + * A brief note on aux record management. > + * > + * Aux records are allocated and added to the skb list of > + * the "main" record. The ab->skb is reset to point to the > + * aux record on its creation. When the aux record in complete ^^ "is" > + * ab->skb has to be reset to point to the "main" record. > + * This allows the audit_log_ functions to be ignorant of > + * which kind of record it is logging to. It also avoids adding > + * special data for aux records. > + */ It might be good to move the above comment into the audit_buffer_aux_new() comment header (below) so it does not get misplaced. > +/** > + * audit_buffer_aux_new - Add an aux record buffer to the skb list > + * @ab: audit_buffer > + * @type: message type > + * > + * On success ab->skb will point to the new aux record. > + * Returns 0 on success, -ENOMEM should allocation fail. > + */ > +static int audit_buffer_aux_new(struct audit_buffer *ab, int type) ... > @@ -2157,16 +2214,44 @@ int audit_log_task_context(struct audit_buffer *ab) > if (!lsmblob_is_set(&blob)) > return 0; > > - error = security_secid_to_secctx(&blob, &context, LSMBLOB_FIRST); > + if (!lsm_multiple_contexts()) { > + error = security_secid_to_secctx(&blob, &context, > + LSMBLOB_FIRST); > + if (error) { > + if (error != -EINVAL) > + goto error_path; > + return 0; > + } > > - if (error) { > - if (error != -EINVAL) > + audit_log_format(ab, " subj=%s", context.context); > + security_release_secctx(&context); > + } else { > + /* Multiple LSMs provide contexts. Include an aux record. */ > + audit_log_format(ab, " subj=?"); > + error = audit_buffer_aux_new(ab, AUDIT_MAC_TASK_CONTEXTS); > + if (error) > goto error_path; > - return 0; > + for (i = 0; i < LSMBLOB_ENTRIES; i++) { > + if (blob.secid[i] == 0) > + continue; > + error = security_secid_to_secctx(&blob, &context, i); > + if (error) { > + if (error != -EINVAL) > + audit_panic("error in audit_log_task_context"); > + audit_log_format(ab, "%ssubj_%s=?", > + i ? " " : "", > + lsm_slot_to_name(i)); I wonder if it might be better to record the "subj_smack=?" field before checking @error and potentially calling audit_panic(). In practice it likely shouldn't matter, I feel better if we at least record the subject information before we call the wildcard that is audit_panic(). > + } else { > + audit_log_format(ab, "%ssubj_%s=%s", > + i ? " " : "", > + lsm_slot_to_name(i), > + context.context); > + security_release_secctx(&context); > + } > + } > + audit_buffer_aux_end(ab); > } > > - audit_log_format(ab, " subj=%s", context.context); > - security_release_secctx(&context); > return 0; > > error_path: > @@ -2382,13 +2467,8 @@ int audit_signal_info(int sig, struct task_struct *t) > } > > /** > - * __audit_log_end - end one audit record > + * __audit_log_end - send one audit record If we want to be very nit-picky here, "end" is more correct than "send". First, audit_log_end() doesn't actually send the record, it just queues the record for the kauditd_thread which then attempts to send it. Second, there is no guarantee that the record will actually be sent at this point, although it would be nice if that were true :) > * @skb: the buffer to send > - * > - * We can not do a netlink send inside an irq context because it blocks (last > - * arg, flags, is not set to MSG_DONTWAIT), so the audit buffer is placed on a > - * queue and a kthread is scheduled to remove them from the queue outside the > - * irq context. May be called in any context. > */ This should probably be moved to patch 25/29 as it has more to do with the __audit_log_end() introduction than this patch. -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit