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 B82FAC433FE for ; Wed, 16 Mar 2022 01:08:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352892AbiCPBJ7 (ORCPT ); Tue, 15 Mar 2022 21:09:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39212 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348762AbiCPBJx (ORCPT ); Tue, 15 Mar 2022 21:09:53 -0400 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8000243EE2 for ; Tue, 15 Mar 2022 18:08:37 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id dr20so1127733ejc.6 for ; Tue, 15 Mar 2022 18:08:37 -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=c4yJTBFrYxfC9d71JFIt7TJ1Pyac9aie49haagZLT7M=; b=3gDlKTc4TJ5D37yFflHfb3SjMMeRE6vABJRAxukK3Wbi9sS86YcFxRL/T+d7J0y+rW kgf5CLNBMiGVhrblLVvXHsM4xVl8lKjQ2Aaxod5fquAk3Sw6F5Xo77feHzQfr6DzN6fA Vto75EWTlMCvkOmoXymTVFMduLDSYEg98V1xl56vheSaEh2N20EZF95fEFA50i+rkirG 19QNzBGD43yNleI5RahGLzuq54uKlRleHuHvG+1HDnXxei/ukuUKiWad494s+nR+G27I W3YSuzYNlf9Fr/gmNE+2DIP+I77g+dLK7bxpi8JFVbA6sfDc+0B7vwsGv9t5bllW1hFH K8vg== 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=c4yJTBFrYxfC9d71JFIt7TJ1Pyac9aie49haagZLT7M=; b=nxfvKlCQOWrnpJcXyWoBxEMjYQc7ZklRUkofvtXW3Na1BnqawaD5PvtytGT+ayYmrs X5OVlmIKsEUm8UDwIrh7uEmKcxLWY5VZs5qyvoaBPDskAJQWsgHYk1i3oU7+Yrm81pz/ TpzjJGKficaYjewjwKdAc0LHHe+9nEdZZZtfcAPN4PLyoNqActm3cbtCFBvykuAmCrQC ys0G6ECuBn3ta75HW5Re018CnanJVRBwRkix/W4cCOjoLshjl/C9Dj97LBXJnzILnVjU Xjp6ilimXipxXqtZPRB8E/dFL4spyjPjXWrIEsdLQFo46cyQf0JgJLLy2NNeE2N5IN1t UR+Q== X-Gm-Message-State: AOAM532Tq2iuXb8BSBqpiqkk1FL1k+3TEHOPUOlVHxuvMI0isvG9kfmq AmW7zy0FLbeW7BgwnQYZ5LzC8rihod2zmegkFxg1 X-Google-Smtp-Source: ABdhPJz+3ez8xrnU+3o745dhyZ/+LfaOfJ4CIyYsCJwxt1BoOAITZMIZnjbEyIlJbjF9qDPVb/2j1V8hj1Wa86guV90= X-Received: by 2002:a17:907:9803:b0:6db:ab21:738e with SMTP id ji3-20020a170907980300b006dbab21738emr17937334ejc.112.1647392915955; Tue, 15 Mar 2022 18:08:35 -0700 (PDT) MIME-Version: 1.0 References: <20220310234632.16194-1-casey@schaufler-ca.com> <20220310234632.16194-28-casey@schaufler-ca.com> <987800d2-797c-e780-60f5-0e499081572f@schaufler-ca.com> In-Reply-To: <987800d2-797c-e780-60f5-0e499081572f@schaufler-ca.com> From: Paul Moore Date: Tue, 15 Mar 2022 21:08:24 -0400 Message-ID: Subject: Re: [PATCH v33 27/29] 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, 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 Tue, Mar 15, 2022 at 8:23 PM Casey Schaufler wrote: > On 3/15/2022 4:47 PM, Paul Moore wrote: > > On Thu, Mar 10, 2022 at 7:01 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 | 47 +++++++++++++++++++++++ > >> kernel/auditsc.c | 79 ++++++++++++-------------------------- > >> 4 files changed, 77 insertions(+), 55 deletions(-) ... > >> @@ -1373,18 +1362,10 @@ static void show_special(struct audit_context *context, int *call_panic) > >> from_kgid(&init_user_ns, context->ipc.gid), > >> context->ipc.mode); > >> if (osid) { > >> - struct lsmcontext lsmcxt; > >> struct lsmblob blob; > >> > >> lsmblob_init(&blob, osid); > >> - if (security_secid_to_secctx(&blob, &lsmcxt, > >> - LSMBLOB_FIRST)) { > >> - audit_log_format(ab, " osid=%u", osid); > >> - *call_panic = 1; > >> - } else { > >> - audit_log_format(ab, " obj=%s", lsmcxt.context); > >> - security_release_secctx(&lsmcxt); > >> - } > >> + audit_log_object_context(ab, &blob); > > While we lose the "osid=X" in case of failure, the secid/SID is a > > private kernel value meaning it was always of questionable value. > > I could come up with a change to audit_log_object_context() that > would put out an osid= in the single security module case. I would > prefer not to if that would be acceptable. What I think you have right now is fine. I thought others might point out the field differences so I was trying to say that the existing code really isn't very useful in case of error, there is no practical way for someone in userspace to do anything meaningful with an osid/secid/SID value as they are transient kernel-private values. My apologies for the confusion. -- 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 F1FB3C4332F for ; Wed, 16 Mar 2022 01:08:46 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-357-kwf-xLCIPPm7-Pi3qN952w-1; Tue, 15 Mar 2022 21:08:42 -0400 X-MC-Unique: kwf-xLCIPPm7-Pi3qN952w-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 0D3A61C05B04; Wed, 16 Mar 2022 01:08:41 +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 6589540FF409; Wed, 16 Mar 2022 01:08:40 +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 110A619451EC; Wed, 16 Mar 2022 01:08:40 +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 294B919452D2 for ; Wed, 16 Mar 2022 01:08:39 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 1854B40FF40C; Wed, 16 Mar 2022 01:08:39 +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 1435040FF40B for ; Wed, 16 Mar 2022 01:08:39 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (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 EF60E811E78 for ; Wed, 16 Mar 2022 01:08:38 +0000 (UTC) Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-637-8o4hzwGmN9OjC_zhqtkLZQ-1; Tue, 15 Mar 2022 21:08:37 -0400 X-MC-Unique: 8o4hzwGmN9OjC_zhqtkLZQ-1 Received: by mail-ej1-f52.google.com with SMTP id qa43so1075429ejc.12 for ; Tue, 15 Mar 2022 18:08:37 -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=c4yJTBFrYxfC9d71JFIt7TJ1Pyac9aie49haagZLT7M=; b=q2TVH7oyQsHrfG3kdhUIVy5deJm3pfKyqHZj0emcDZMDZIqR1JSY2XY0bzO2NH/Q63 SkziVSmAIetxYkMj86p5pKqwFXXf19z2ukgjHXsopIj/NVOu8Owo4jPXhGbzekAxTs/4 b62yaD3cpS6jFokAN9Mn4TkEFS8OqrrhexUrcdEnY6PVKbQgyu0iI2gZAHFz9jZuDJRo 8hM0eHKKmFkJnh21nWAZMDkKw/x6diDFunal5JCZZ+0a4LsjH+E3hL/Ay3HS08XvIdsx qHmzkySPMm5oNE4GLbAyp6W8GZAF8FEyvWdb/GIgYWtYa9GhBztbInRB8gwTo5gFRJDw 6KJQ== X-Gm-Message-State: AOAM530R2FjXk6NtVNR8Sq4aUnLS8sRaGShQc2dLEuF/L9bT74+BmkB+ uvBAheP4dr8fPHNnk8X1x4HsU6CWV/rkqLxhBYSq X-Google-Smtp-Source: ABdhPJz+3ez8xrnU+3o745dhyZ/+LfaOfJ4CIyYsCJwxt1BoOAITZMIZnjbEyIlJbjF9qDPVb/2j1V8hj1Wa86guV90= X-Received: by 2002:a17:907:9803:b0:6db:ab21:738e with SMTP id ji3-20020a170907980300b006dbab21738emr17937334ejc.112.1647392915955; Tue, 15 Mar 2022 18:08:35 -0700 (PDT) MIME-Version: 1.0 References: <20220310234632.16194-1-casey@schaufler-ca.com> <20220310234632.16194-28-casey@schaufler-ca.com> <987800d2-797c-e780-60f5-0e499081572f@schaufler-ca.com> In-Reply-To: <987800d2-797c-e780-60f5-0e499081572f@schaufler-ca.com> From: Paul Moore Date: Tue, 15 Mar 2022 21:08:24 -0400 Message-ID: Subject: Re: [PATCH v33 27/29] 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.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 Tue, Mar 15, 2022 at 8:23 PM Casey Schaufler wrote: > On 3/15/2022 4:47 PM, Paul Moore wrote: > > On Thu, Mar 10, 2022 at 7:01 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 | 47 +++++++++++++++++++++++ > >> kernel/auditsc.c | 79 ++++++++++++-------------------------- > >> 4 files changed, 77 insertions(+), 55 deletions(-) ... > >> @@ -1373,18 +1362,10 @@ static void show_special(struct audit_context *context, int *call_panic) > >> from_kgid(&init_user_ns, context->ipc.gid), > >> context->ipc.mode); > >> if (osid) { > >> - struct lsmcontext lsmcxt; > >> struct lsmblob blob; > >> > >> lsmblob_init(&blob, osid); > >> - if (security_secid_to_secctx(&blob, &lsmcxt, > >> - LSMBLOB_FIRST)) { > >> - audit_log_format(ab, " osid=%u", osid); > >> - *call_panic = 1; > >> - } else { > >> - audit_log_format(ab, " obj=%s", lsmcxt.context); > >> - security_release_secctx(&lsmcxt); > >> - } > >> + audit_log_object_context(ab, &blob); > > While we lose the "osid=X" in case of failure, the secid/SID is a > > private kernel value meaning it was always of questionable value. > > I could come up with a change to audit_log_object_context() that > would put out an osid= in the single security module case. I would > prefer not to if that would be acceptable. What I think you have right now is fine. I thought others might point out the field differences so I was trying to say that the existing code really isn't very useful in case of error, there is no practical way for someone in userspace to do anything meaningful with an osid/secid/SID value as they are transient kernel-private values. My apologies for the confusion. -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit