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 3BA6DC433EF for ; Thu, 3 Mar 2022 23:36:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235240AbiCCXhV (ORCPT ); Thu, 3 Mar 2022 18:37:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33912 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229507AbiCCXhQ (ORCPT ); Thu, 3 Mar 2022 18:37:16 -0500 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 84EE11688FF for ; Thu, 3 Mar 2022 15:36:29 -0800 (PST) Received: by mail-ej1-x630.google.com with SMTP id d10so13930873eje.10 for ; Thu, 03 Mar 2022 15:36:29 -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=nb52pq5dwlw/x2u3OPYN+2SF0B5k1laAEuKkJVbBr4o=; b=rJI2DXVkWPj5uDVV0a8h5IZT2qmRhjPy258S2ixfFAGCehG0NCvnOlSViiq6a1MhOo mzLWojJ/hVPjpgDAqqdV7MT+jyulaMBvHAq7ga/tjZ2AXvzf9VxNNddJoZgHsrKHRT83 HxRzOFKI2w7lc/5qrh9Fls1oUYcxI52mfYK1+Vi7xwLm5ZN9TJsvdWC5tK9qdX88u4Jr htOrf1pbbdADBOa5eozZpLpTeMhBwA2OKENPEhcnKPk/bGvqTIXeefXHR2CaZdSL4Do6 FFnSFbh73hVAy9UwZWt7wVHs5XBvmCLekoLpCC9XwpFLuf+EkOtrtwd56DEg8YjlFtDo QkUg== 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=nb52pq5dwlw/x2u3OPYN+2SF0B5k1laAEuKkJVbBr4o=; b=MzLTl0nXrojbjjuJkiawF9A3OaPpXv2gDiyDwOyHmJOIZxVWomjaN6VeBxyKB3SHLR ctHhehbJBh1ZXyGpp90JEtL/qwa/ijsnLglxpBETafhEXbHliLzvbV+mELzIDpdLwd92 vikVH/HHpQZCmmGqlzQ4bpX3ovkoZtfQb36yEGT0eq/Slr/L8iptQL09ATBr4fS7IWXi n/UYbC4Yq6JFUDclVUOh5Xb+oe4i/7z71zTzwUoc6cS+lfd8eej4MxXUPPzPQ0s24Lom /eOxc1ucBvv56fyY72xJoPsHP4DblCYRkxzLzY0zHRCs3xppMTmbvLA+M/U5PtcOVnPu shZA== X-Gm-Message-State: AOAM533LgkMEzkC06NqyuCcQO1qTvYQLeCehbe7PTaKCTE3EMjhEx6wQ c6HHcjAHjcbfFqof11xI0sX87ss808S2MThuEc1w X-Google-Smtp-Source: ABdhPJxKEAyDYNVXQ2OKTY1WIHVsrCxubx7bpOujfmBHDjh52hmHm4rYHPPHBUaDP2eSDbwDexxPo3qbkEM9473s3os= X-Received: by 2002:a17:907:1b09:b0:6d8:faa8:4a06 with SMTP id mp9-20020a1709071b0900b006d8faa84a06mr9031911ejc.701.1646350588003; Thu, 03 Mar 2022 15:36:28 -0800 (PST) MIME-Version: 1.0 References: <20220202235323.23929-1-casey@schaufler-ca.com> <20220202235323.23929-27-casey@schaufler-ca.com> In-Reply-To: <20220202235323.23929-27-casey@schaufler-ca.com> From: Paul Moore Date: Thu, 3 Mar 2022 18:36:17 -0500 Message-ID: Subject: Re: [PATCH v32 26/28] Audit: Add record for multiple object 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, 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 Wed, Feb 2, 2022 at 7:23 PM Casey Schaufler wrote: > > Create a new audit record AUDIT_MAC_OBJ_CONTEXTS. > An example of the MAC_OBJ_CONTEXTS (1421) record is: > > type=MAC_OBJ_CONTEXTS[1421] > msg=audit(1601152467.009:1050): > obj_selinux=unconfined_u:object_r:user_home_t:s0 > > When an audit event includes a AUDIT_MAC_OBJ_CONTEXTS record > the "obj=" field in other records in the event will be "obj=?". > An AUDIT_MAC_OBJ_CONTEXTS record is supplied when the system has > multiple security modules that may make access decisions based > on an object security context. > > Signed-off-by: Casey Schaufler > --- > include/linux/audit.h | 5 ++++ > include/uapi/linux/audit.h | 1 + > kernel/audit.c | 59 ++++++++++++++++++++++++++++++++++++++ > kernel/auditsc.c | 37 ++++-------------------- > 4 files changed, 70 insertions(+), 32 deletions(-) ... > diff --git a/kernel/audit.c b/kernel/audit.c > index e8744e80ef21..3b9ce617b150 100644 > --- a/kernel/audit.c > +++ b/kernel/audit.c > @@ -2199,6 +2200,43 @@ int audit_log_task_context(struct audit_buffer *ab) > } > EXPORT_SYMBOL(audit_log_task_context); > > +void audit_log_object_context(struct audit_buffer *ab, struct lsmblob *blob) > +{ > + struct audit_context_entry *ace; > + struct lsmcontext context; > + int error; > + > + if (!lsm_multiple_contexts()) { > + error = security_secid_to_secctx(blob, &context, LSMBLOB_FIRST); > + if (error) { > + if (error != -EINVAL) > + goto error_path; > + return; > + } > + audit_log_format(ab, " obj=%s", context.context); > + security_release_secctx(&context); > + } else { > + /* > + * If there is more than one security module that has a > + * object "context" it's necessary to put the object data > + * into a separate record to maintain compatibility. > + */ I know this is nitpicky, but I'm going to say it anyway ... the separate record isn't purely for compatibility reasons, it's for size reasons. There is a fear that multiple LSM labels could blow past the record size limit when combined with other fields, so putting them in their own dedicated record gives us more room. If that wasn't the case we could just tack them on the end of existing records. However, converting the existing "obj=" field into "obj=?" when multiple LSM labels are present *is* a compatibility nod as it allows existing userspace tooling that expects a single "obj=" field to continue to work. > + audit_log_format(ab, " obj=?"); > + ace = kzalloc(sizeof(*ace), ab->gfp_mask); > + if (!ace) > + goto error_path; > + INIT_LIST_HEAD(&ace->list); > + ace->type = AUDIT_MAC_OBJ_CONTEXTS; > + ace->lsm_objs = *blob; > + list_add(&ace->list, &ab->aux_records); > + } > + return; > + > +error_path: > + audit_panic("error in audit_log_object_context"); > +} > +EXPORT_SYMBOL(audit_log_object_context); > + -- 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 F1334C433F5 for ; Thu, 3 Mar 2022 23:36:45 +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-54-UeHqus67OoO95Ge4CZNrKw-1; Thu, 03 Mar 2022 18:36:41 -0500 X-MC-Unique: UeHqus67OoO95Ge4CZNrKw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 17204824FA7; Thu, 3 Mar 2022 23:36:38 +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 690B15E279; Thu, 3 Mar 2022 23:36:37 +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 7212A4A701; Thu, 3 Mar 2022 23:36:35 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 223NaVfl006321 for ; Thu, 3 Mar 2022 18:36:31 -0500 Received: by smtp.corp.redhat.com (Postfix) id 121991457F05; Thu, 3 Mar 2022 23:36:31 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast05.extmail.prod.ext.rdu2.redhat.com [10.11.55.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0DF4C1457F04 for ; Thu, 3 Mar 2022 23:36:31 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.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 E8DFA803DDA for ; Thu, 3 Mar 2022 23:36:30 +0000 (UTC) Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-584-otQHXHifOKeonifiCSbzlg-1; Thu, 03 Mar 2022 18:36:29 -0500 X-MC-Unique: otQHXHifOKeonifiCSbzlg-1 Received: by mail-ej1-f51.google.com with SMTP id dr20so13939640ejc.6 for ; Thu, 03 Mar 2022 15:36:29 -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=nb52pq5dwlw/x2u3OPYN+2SF0B5k1laAEuKkJVbBr4o=; b=xyGO63oa4Ii7qJpTQjF1JVDQN++xkjKe4vo5gngPESB4a8DSKZSVwcOUA6vwY6VcHc i1s52xNKNWzCh+SP0vVWQI6tNeLWAnra3RXNvDgZ8tXxl6VCfd1NekvhzeP/w0nhzx/D VUZUwL7d1dMg4CBpWb7YAE0/FPHifUrUSaJUkrprf2gk+nfrYDJmnCnmAz63P7IccBKX bK3f4ugjeTr4EBC71Q67pJHo+RSLxe5jfi0021dGwxxAzccUu0bhhrzv/GMgw5XGab05 QGYfVLyaK99CnWDlP8GEuQYpF5oXO1tFUeN4po3yGWN6tk+CBJi93zcW4qI83cCAVzaZ JMfg== X-Gm-Message-State: AOAM533B0r6Iz0MZoEiy9PIG9uT82CcaNEUHVKUKGJAhBTRb8d+FkB+g 7IEWTFp618c8v3re2b002Ow1swr8+kQY6FRVwnHq X-Google-Smtp-Source: ABdhPJxKEAyDYNVXQ2OKTY1WIHVsrCxubx7bpOujfmBHDjh52hmHm4rYHPPHBUaDP2eSDbwDexxPo3qbkEM9473s3os= X-Received: by 2002:a17:907:1b09:b0:6d8:faa8:4a06 with SMTP id mp9-20020a1709071b0900b006d8faa84a06mr9031911ejc.701.1646350588003; Thu, 03 Mar 2022 15:36:28 -0800 (PST) MIME-Version: 1.0 References: <20220202235323.23929-1-casey@schaufler-ca.com> <20220202235323.23929-27-casey@schaufler-ca.com> In-Reply-To: <20220202235323.23929-27-casey@schaufler-ca.com> From: Paul Moore Date: Thu, 3 Mar 2022 18:36:17 -0500 Message-ID: Subject: Re: [PATCH v32 26/28] Audit: Add record for multiple object 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.85 on 10.11.54.7 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.79 on 10.5.11.14 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 Wed, Feb 2, 2022 at 7:23 PM Casey Schaufler wrote: > > Create a new audit record AUDIT_MAC_OBJ_CONTEXTS. > An example of the MAC_OBJ_CONTEXTS (1421) record is: > > type=MAC_OBJ_CONTEXTS[1421] > msg=audit(1601152467.009:1050): > obj_selinux=unconfined_u:object_r:user_home_t:s0 > > When an audit event includes a AUDIT_MAC_OBJ_CONTEXTS record > the "obj=" field in other records in the event will be "obj=?". > An AUDIT_MAC_OBJ_CONTEXTS record is supplied when the system has > multiple security modules that may make access decisions based > on an object security context. > > Signed-off-by: Casey Schaufler > --- > include/linux/audit.h | 5 ++++ > include/uapi/linux/audit.h | 1 + > kernel/audit.c | 59 ++++++++++++++++++++++++++++++++++++++ > kernel/auditsc.c | 37 ++++-------------------- > 4 files changed, 70 insertions(+), 32 deletions(-) ... > diff --git a/kernel/audit.c b/kernel/audit.c > index e8744e80ef21..3b9ce617b150 100644 > --- a/kernel/audit.c > +++ b/kernel/audit.c > @@ -2199,6 +2200,43 @@ int audit_log_task_context(struct audit_buffer *ab) > } > EXPORT_SYMBOL(audit_log_task_context); > > +void audit_log_object_context(struct audit_buffer *ab, struct lsmblob *blob) > +{ > + struct audit_context_entry *ace; > + struct lsmcontext context; > + int error; > + > + if (!lsm_multiple_contexts()) { > + error = security_secid_to_secctx(blob, &context, LSMBLOB_FIRST); > + if (error) { > + if (error != -EINVAL) > + goto error_path; > + return; > + } > + audit_log_format(ab, " obj=%s", context.context); > + security_release_secctx(&context); > + } else { > + /* > + * If there is more than one security module that has a > + * object "context" it's necessary to put the object data > + * into a separate record to maintain compatibility. > + */ I know this is nitpicky, but I'm going to say it anyway ... the separate record isn't purely for compatibility reasons, it's for size reasons. There is a fear that multiple LSM labels could blow past the record size limit when combined with other fields, so putting them in their own dedicated record gives us more room. If that wasn't the case we could just tack them on the end of existing records. However, converting the existing "obj=" field into "obj=?" when multiple LSM labels are present *is* a compatibility nod as it allows existing userspace tooling that expects a single "obj=" field to continue to work. > + audit_log_format(ab, " obj=?"); > + ace = kzalloc(sizeof(*ace), ab->gfp_mask); > + if (!ace) > + goto error_path; > + INIT_LIST_HEAD(&ace->list); > + ace->type = AUDIT_MAC_OBJ_CONTEXTS; > + ace->lsm_objs = *blob; > + list_add(&ace->list, &ab->aux_records); > + } > + return; > + > +error_path: > + audit_panic("error in audit_log_object_context"); > +} > +EXPORT_SYMBOL(audit_log_object_context); > + -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit