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 E0813C433EF for ; Tue, 26 Apr 2022 17:58:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348194AbiDZSBU (ORCPT ); Tue, 26 Apr 2022 14:01:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347438AbiDZSBR (ORCPT ); Tue, 26 Apr 2022 14:01:17 -0400 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 130D64BBA0 for ; Tue, 26 Apr 2022 10:58:08 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id bg25so11017144wmb.4 for ; Tue, 26 Apr 2022 10:58:08 -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=1hZvovRgEONI0evmHfh/dPYE5MYM2igj+YD6jKDmNGA=; b=mz/MOvI0F4FWfJZejeJKrAYFuv17SumJoq0jtd/G81PYn06FXP/RonNwOrhy/XMXlE 85HYzD5ezQznisBUjcu0+ElntaokFyL5kCgIyauuLv1DjZdkq50qZPkvL+LFmNTg6VFw pT5GaLO7BEmfw3mNoNWuEFJMnBF5rLO1Tz9QhW/TpgilxHea0wVarwoAAypHTQuV4ohD 3dT3NLalmx3mti9z6z8jEgtriNvtcI9ZEV1KSfieaW+eJ3E0CJShBCXwKHX7QhWHvsFR EfJUWi2M5rKo/ZWqbRW/Pl+hFmVQgSqufCiKOqX1xehrsn1+YStcY7+Sz6NgecE2oiWr j2mQ== 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=1hZvovRgEONI0evmHfh/dPYE5MYM2igj+YD6jKDmNGA=; b=bEHK8hhHIQckAST+eyS9/NcR86785CBcnBFiJBANqTja1xh9FgC852Fzlf+tXdQj0o BMzrMFu0F+ZzC5lcXkNkjfPS29n71sS5Bg/0yKiEee3N0BjNr8qibFZCE5ZdTyTtItZw eDCgh2pjYT7hSu7sUB+Mi7TQYAo61jAemOSig7TBqom+PYokGVZHlhCTXfDhJnGMVlQB eKVaHyNSZ6qPjlV8yzVLMC3ykuFuax1cKAhIfeqx6taDk349993v/SHLyp+/81MwFs0L nhI1sp69amR7HW6PkX5OKIQGKs6LL7CwqZtkA3ZTkba/6Wfv8qayG4XJujGFWyIOBusY TmnA== X-Gm-Message-State: AOAM531PTFRkUMOM+luVbBMuyANHlh+bKbXcwF7Is+gbFBM1/23PGjj3 RoScqwyrpeVX86vicEvP/Pg+Erp052Ryb4z0+VCB X-Google-Smtp-Source: ABdhPJzNwSILdb0ld2EVSSHHV+FNqqsmoxlGljFVPtAr+Z77PHjh1O4gx3EDrGPncUha4nTXOKAzbWBCOy4QQoeOZU0= X-Received: by 2002:a05:600c:1456:b0:38e:bd55:700 with SMTP id h22-20020a05600c145600b0038ebd550700mr22111097wmi.204.1650995886423; Tue, 26 Apr 2022 10:58:06 -0700 (PDT) MIME-Version: 1.0 References: <20220418145945.38797-1-casey@schaufler-ca.com> <20220418145945.38797-23-casey@schaufler-ca.com> In-Reply-To: From: Paul Moore Date: Tue, 26 Apr 2022 13:57:55 -0400 Message-ID: Subject: Re: [PATCH v35 22/29] Audit: Keep multiple LSM data in audit_names To: John Johansen Cc: Casey Schaufler , casey.schaufler@intel.com, jmorris@namei.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, linux-audit@redhat.com, keescook@chromium.org, 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 Mon, Apr 25, 2022 at 7:32 PM John Johansen wrote: > On 4/18/22 07:59, Casey Schaufler wrote: > > Replace the osid field in the audit_names structure > > with a lsmblob structure. This accomodates the use > > of an lsmblob in security_audit_rule_match() and > > security_inode_getsecid(). > > > > Signed-off-by: Casey Schaufler > > Acked-by: Paul Moore > > --- > > kernel/audit.h | 2 +- > > kernel/auditsc.c | 22 ++++++++-------------- > > 2 files changed, 9 insertions(+), 15 deletions(-) ... > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c > > index 231631f61550..6fe9f2525fc1 100644 > > --- a/kernel/auditsc.c > > +++ b/kernel/auditsc.c > > @@ -700,17 +700,16 @@ static int audit_filter_rules(struct task_struct *tsk, > > * lsmblob, which happens later in > > * this patch set. > > */ > > - lsmblob_init(&blob, name->osid); > > result = security_audit_rule_match( > > - &blob, > > + &name->lsmblob, > > f->type, > > f->op, > > &f->lsm_rules); > > } else if (ctx) { > > list_for_each_entry(n, &ctx->names_list, list) { > > - lsmblob_init(&blob, n->osid); > > if (security_audit_rule_match( > > - &blob, f->type, f->op, > > + &n->lsmblob, > > + f->type, f->op, > > &f->lsm_rules)) { > > ++result; > > break; > > @@ -1589,13 +1588,12 @@ static void audit_log_name(struct audit_context *context, struct audit_names *n, > > from_kgid(&init_user_ns, n->gid), > > MAJOR(n->rdev), > > MINOR(n->rdev)); > > - if (n->osid != 0) { > > - struct lsmblob blob; > > + if (lsmblob_is_set(&n->lsmblob)) { > > struct lsmcontext lsmctx; > > > > - lsmblob_init(&blob, n->osid); > > - if (security_secid_to_secctx(&blob, &lsmctx, LSMBLOB_FIRST)) { > > - audit_log_format(ab, " osid=%u", n->osid); > > + if (security_secid_to_secctx(&n->lsmblob, &lsmctx, > > + LSMBLOB_FIRST)) { > > + audit_log_format(ab, " osid=?"); > > is there something better we can do here? This feels like a regression Unfortunately no, or at least nothing has been suggested that is an improvement on this approach. We could overload the existing field, but that runs the risk of confusing userspace tooling and potentially bumping into the buffer limit in some more complex configurations. The "?" value was chosen as it is a commonly accepted way for the audit subsystem to indicate that a value is "missing" and in the case of new/updated userspace tooling this would be an indication to look for the new record type which provides all of the necessary LSM labels. In the case of old/unaware userspace tooling it would serve as a graceful indicator that something is awry, i.e. you are using new kernel functionality without updating your userspace. -- 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 3588BC433EF for ; Tue, 26 Apr 2022 17:58:17 +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-213-UNk_d4rLPV2vHh5ys5ckvg-1; Tue, 26 Apr 2022 13:58:13 -0400 X-MC-Unique: UNk_d4rLPV2vHh5ys5ckvg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7FBBB3C021A1; Tue, 26 Apr 2022 17:58:12 +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 7DAA9C2810D; Tue, 26 Apr 2022 17:58:11 +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 359301947BBB; Tue, 26 Apr 2022 17:58:11 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 0538B19451EC for ; Tue, 26 Apr 2022 17:58:09 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id E8F0B551E92; Tue, 26 Apr 2022 17:58:09 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast10.extmail.prod.ext.rdu2.redhat.com [10.11.55.26]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E4A8B550871 for ; Tue, 26 Apr 2022 17:58:09 +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 C6B2F1C05AEB for ; Tue, 26 Apr 2022 17:58:09 +0000 (UTC) Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-317-7o78nen8NE2-0BZOKMZ4-A-1; Tue, 26 Apr 2022 13:58:07 -0400 X-MC-Unique: 7o78nen8NE2-0BZOKMZ4-A-1 Received: by mail-wm1-f43.google.com with SMTP id n126-20020a1c2784000000b0038e8af3e788so2079542wmn.1 for ; Tue, 26 Apr 2022 10:58:07 -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=1hZvovRgEONI0evmHfh/dPYE5MYM2igj+YD6jKDmNGA=; b=Qos3j7+BtB6MnecU7xC3rxSBY9d+ZH7AkXn9+vjSAq5sNAdi9+zf73OEfbq7Wu7djs VQ5qsXAPkGNg3hI5H+pB9OzvHIhiiHRVODTHsjPcZ4vwHI2Z4LxfvqPHP/JH8OJBjWXm 6b8rtB+Inh9Hq5isXtIMzzbJ2n9GSJz9ysHqaSoDc5j7AQ4eNAysbJQ59k7hIFmZrLC0 kka2I4kascqDcy+stSyncYB+kxDIdLb4kdrTpKkPMuDnR74SuiS5H5IqW+k+Xd1wKV2I RQhT5+fl6A+vQwGXnCMGeKzkZCK45pg44Hk0IimEIkcb1UW7A1LOfHR3bMmoP6fABB42 pUvg== X-Gm-Message-State: AOAM5325AfAUFNoht/0BMqVEuDqdKK9aFcP5Hv6WuEFeHCSTE61t+N+O n5fKRo3t4xV1IL5HhuR78qtXXkDdTMeOVcD8+yDfz2u2sA== X-Google-Smtp-Source: ABdhPJzNwSILdb0ld2EVSSHHV+FNqqsmoxlGljFVPtAr+Z77PHjh1O4gx3EDrGPncUha4nTXOKAzbWBCOy4QQoeOZU0= X-Received: by 2002:a05:600c:1456:b0:38e:bd55:700 with SMTP id h22-20020a05600c145600b0038ebd550700mr22111097wmi.204.1650995886423; Tue, 26 Apr 2022 10:58:06 -0700 (PDT) MIME-Version: 1.0 References: <20220418145945.38797-1-casey@schaufler-ca.com> <20220418145945.38797-23-casey@schaufler-ca.com> In-Reply-To: From: Paul Moore Date: Tue, 26 Apr 2022 13:57:55 -0400 Message-ID: Subject: Re: [PATCH v35 22/29] Audit: Keep multiple LSM data in audit_names To: John Johansen 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.9 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: selinux@vger.kernel.org, jmorris@namei.org, linux-kernel@vger.kernel.org, casey.schaufler@intel.com, linux-security-module@vger.kernel.org, linux-audit@redhat.com Errors-To: linux-audit-bounces@redhat.com Sender: "Linux-audit" X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 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 Mon, Apr 25, 2022 at 7:32 PM John Johansen wrote: > On 4/18/22 07:59, Casey Schaufler wrote: > > Replace the osid field in the audit_names structure > > with a lsmblob structure. This accomodates the use > > of an lsmblob in security_audit_rule_match() and > > security_inode_getsecid(). > > > > Signed-off-by: Casey Schaufler > > Acked-by: Paul Moore > > --- > > kernel/audit.h | 2 +- > > kernel/auditsc.c | 22 ++++++++-------------- > > 2 files changed, 9 insertions(+), 15 deletions(-) ... > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c > > index 231631f61550..6fe9f2525fc1 100644 > > --- a/kernel/auditsc.c > > +++ b/kernel/auditsc.c > > @@ -700,17 +700,16 @@ static int audit_filter_rules(struct task_struct *tsk, > > * lsmblob, which happens later in > > * this patch set. > > */ > > - lsmblob_init(&blob, name->osid); > > result = security_audit_rule_match( > > - &blob, > > + &name->lsmblob, > > f->type, > > f->op, > > &f->lsm_rules); > > } else if (ctx) { > > list_for_each_entry(n, &ctx->names_list, list) { > > - lsmblob_init(&blob, n->osid); > > if (security_audit_rule_match( > > - &blob, f->type, f->op, > > + &n->lsmblob, > > + f->type, f->op, > > &f->lsm_rules)) { > > ++result; > > break; > > @@ -1589,13 +1588,12 @@ static void audit_log_name(struct audit_context *context, struct audit_names *n, > > from_kgid(&init_user_ns, n->gid), > > MAJOR(n->rdev), > > MINOR(n->rdev)); > > - if (n->osid != 0) { > > - struct lsmblob blob; > > + if (lsmblob_is_set(&n->lsmblob)) { > > struct lsmcontext lsmctx; > > > > - lsmblob_init(&blob, n->osid); > > - if (security_secid_to_secctx(&blob, &lsmctx, LSMBLOB_FIRST)) { > > - audit_log_format(ab, " osid=%u", n->osid); > > + if (security_secid_to_secctx(&n->lsmblob, &lsmctx, > > + LSMBLOB_FIRST)) { > > + audit_log_format(ab, " osid=?"); > > is there something better we can do here? This feels like a regression Unfortunately no, or at least nothing has been suggested that is an improvement on this approach. We could overload the existing field, but that runs the risk of confusing userspace tooling and potentially bumping into the buffer limit in some more complex configurations. The "?" value was chosen as it is a commonly accepted way for the audit subsystem to indicate that a value is "missing" and in the case of new/updated userspace tooling this would be an indication to look for the new record type which provides all of the necessary LSM labels. In the case of old/unaware userspace tooling it would serve as a graceful indicator that something is awry, i.e. you are using new kernel functionality without updating your userspace. -- paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit