Message ID | 20230329130415.2312521-2-roberto.sassu@huaweicloud.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp425020vqo; Wed, 29 Mar 2023 06:45:31 -0700 (PDT) X-Google-Smtp-Source: AKy350ZGaeZ3dbmBkmZDp9TlM/URnblgxAcLWzdKXcMBhvan7O41+O+D7wX82mnM7iOqG+ZhmQqf X-Received: by 2002:a17:907:7b9e:b0:8b1:fc:b06d with SMTP id ne30-20020a1709077b9e00b008b100fcb06dmr22809386ejc.77.1680097531284; Wed, 29 Mar 2023 06:45:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680097531; cv=none; d=google.com; s=arc-20160816; b=g4lxASErdoyEUScdhsw9LBmbAx0a6edsFfwD16qr9cL8p3Ufcd+hn86mpR/Rehy23J 9OGZQYmgBqk+n7Dh/E4jsGFlRMBimVgJaHgxudB/5++26blaVUpIyu6K+l4IjnJ2mcik 6jhbr8KCITAFNCCUP1Jf2JtnYGF/hAUD+lOrEsM6yMWLlbBpPWNyLhJUsEpQ4hEee809 F92G0tsUMbCqKkU8+Qhwuv9h/f/tMavgxHj+BWcNNKXR2ro4B7fw68xrKmT7h5x2nHC/ 7mZ+2pgHGPQSUhQKI3egIo8TgOuMn1J7cDyrlYnywHoKTLQYkQeQTOQg3Qzh8RCbQRWe Z2uA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=AFnJbqwkmzoyp90eHzMc+uAnMkHc6ZporG9AT2jA/OE=; b=pwt7hj+5w1Z6xNP922ayzZDAkD1U4QNMMCPdyreSQRkJP9KAgWgAVfxbF5to8JoQOQ SeCzSn8iCrpwemngLmt+LYyXfCPRhTqvPuFss50Vp7fGrCPArd3tAJaiW0+ASed3tazF ApV1/y38yV64mEtlhxC/fspQ7AtdVHXZKv4BFWhzmLOUU6B1IQ8ktl7HQ+nPksjN6olY 0ORmTIZYHGen4PUEbSKRwOb2Hkt9LHj6PA+VVNAc6+V/5rgB2dG+HzlO0mHh7CiB2UzV LNvCq/Kq/kQABBrMQ5WmzWGyijkptRd4xR0zZG0rLTJ9QM0tv6A1kRRwd1ETlxXtufYt nn+Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n21-20020a05640206d500b004c698b50197si33308073edy.342.2023.03.29.06.45.07; Wed, 29 Mar 2023 06:45:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229512AbjC2NF3 (ORCPT <rfc822;rua109.linux@gmail.com> + 99 others); Wed, 29 Mar 2023 09:05:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50662 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230081AbjC2NFX (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 29 Mar 2023 09:05:23 -0400 Received: from frasgout11.his.huawei.com (frasgout11.his.huawei.com [14.137.139.23]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C94514C02; Wed, 29 Mar 2023 06:05:15 -0700 (PDT) Received: from mail02.huawei.com (unknown [172.18.147.228]) by frasgout11.his.huawei.com (SkyGuard) with ESMTP id 4Pmmkr3z68z9v7gX; Wed, 29 Mar 2023 20:56:04 +0800 (CST) Received: from huaweicloud.com (unknown [10.204.63.22]) by APP1 (Coremail) with SMTP id LxC2BwCXFABgNyRk2AzcAQ--.1625S3; Wed, 29 Mar 2023 14:04:52 +0100 (CET) From: Roberto Sassu <roberto.sassu@huaweicloud.com> To: zohar@linux.ibm.com, dmitry.kasatkin@gmail.com, paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com, stephen.smalley.work@gmail.com, eparis@parisplace.org, casey@schaufler-ca.com Cc: reiserfs-devel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, bpf@vger.kernel.org, kpsingh@kernel.org, keescook@chromium.org, nicolas.bouchinet@clip-os.org, Roberto Sassu <roberto.sassu@huawei.com>, stable@vger.kernel.org Subject: [PATCH v9 1/4] reiserfs: Add security prefix to xattr name in reiserfs_security_write() Date: Wed, 29 Mar 2023 15:04:12 +0200 Message-Id: <20230329130415.2312521-2-roberto.sassu@huaweicloud.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20230329130415.2312521-1-roberto.sassu@huaweicloud.com> References: <20230329130415.2312521-1-roberto.sassu@huaweicloud.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: LxC2BwCXFABgNyRk2AzcAQ--.1625S3 X-Coremail-Antispam: 1UD129KBjvJXoW7Zw17Aw13Xr18GrW3WFWruFg_yoW8ZryfpF WUK3WDCr1DJF1vg3sakanxua40gFWrW3y7W39rK3sFyanrXw1xtFW0yrW3WrW8GrWDXr92 qa18Gw45A3Z5A3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUPqb4IE77IF4wAFF20E14v26rWj6s0DM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28IrcIa0xkI8VA2jI8067AKxVWUGw A2048vs2IY020Ec7CjxVAFwI0_Gr0_Xr1l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxS w2x7M28EF7xvwVC0I7IYx2IY67AKxVWUCVW8JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxV W8Jr0_Cr1UM28EF7xvwVC2z280aVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv6xkF7I0E14v2 6r4UJVWxJr1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2 WlYx0E2Ix0cI8IcVAFwI0_JrI_JrylYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkE bVWUJVW8JwACjcxG0xvY0x0EwIxGrwACI402YVCY1x02628vn2kIc2xKxwCY1x0262kKe7 AKxVW8ZVWrXwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02 F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_GFv_Wr ylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUCVW8JwCI42IY6xIIjxv20xvEc7Cj xVAFwI0_Gr1j6F4UJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI 0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBIdaVFxhVjvjDU0xZFpf9x 07jfcTPUUUUU= X-CM-SenderInfo: purev21wro2thvvxqx5xdzvxpfor3voofrz/1tbiAgALBF1jj4dSKQAAsA X-CFilter-Loop: Reflected X-Spam-Status: No, score=0.0 required=5.0 tests=SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761709948638738814?= X-GMAIL-MSGID: =?utf-8?q?1761709948638738814?= |
Series |
evm: Do HMAC of multiple per LSM xattrs for new inodes
|
|
Commit Message
Roberto Sassu
March 29, 2023, 1:04 p.m. UTC
From: Roberto Sassu <roberto.sassu@huawei.com> Reiserfs sets a security xattr at inode creation time in two stages: first, it calls reiserfs_security_init() to obtain the xattr from active LSMs; then, it calls reiserfs_security_write() to actually write that xattr. Unfortunately, it seems there is a wrong expectation that LSMs provide the full xattr name in the form 'security.<suffix>'. However, LSMs always provided just the suffix, causing reiserfs to not write the xattr at all (if the suffix is shorter than the prefix), or to write an xattr with the wrong name. Add a temporary buffer in reiserfs_security_write(), and write to it the full xattr name, before passing it to reiserfs_xattr_set_handle(). Since the 'security.' prefix is always prepended, remove the name length check. Cc: stable@vger.kernel.org # v2.6.x Fixes: 57fe60df6241 ("reiserfs: add atomic addition of selinux attributes during inode creation") Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> --- fs/reiserfs/xattr_security.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
Comments
On Wed, Mar 29, 2023 at 9:05 AM Roberto Sassu <roberto.sassu@huaweicloud.com> wrote: > From: Roberto Sassu <roberto.sassu@huawei.com> > > Reiserfs sets a security xattr at inode creation time in two stages: first, > it calls reiserfs_security_init() to obtain the xattr from active LSMs; > then, it calls reiserfs_security_write() to actually write that xattr. > > Unfortunately, it seems there is a wrong expectation that LSMs provide the > full xattr name in the form 'security.<suffix>'. However, LSMs always > provided just the suffix, causing reiserfs to not write the xattr at all > (if the suffix is shorter than the prefix), or to write an xattr with the > wrong name. > > Add a temporary buffer in reiserfs_security_write(), and write to it the > full xattr name, before passing it to reiserfs_xattr_set_handle(). > > Since the 'security.' prefix is always prepended, remove the name length > check. > > Cc: stable@vger.kernel.org # v2.6.x > Fixes: 57fe60df6241 ("reiserfs: add atomic addition of selinux attributes during inode creation") > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> > --- > fs/reiserfs/xattr_security.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/fs/reiserfs/xattr_security.c b/fs/reiserfs/xattr_security.c > index 6bffdf9a4fd..b0c354ab113 100644 > --- a/fs/reiserfs/xattr_security.c > +++ b/fs/reiserfs/xattr_security.c > @@ -95,11 +95,13 @@ int reiserfs_security_write(struct reiserfs_transaction_handle *th, > struct inode *inode, > struct reiserfs_security_handle *sec) > { > + char xattr_name[XATTR_NAME_MAX + 1]; > int error; > - if (strlen(sec->name) < sizeof(XATTR_SECURITY_PREFIX)) > - return -EINVAL; If one really wanted to be paranoid they could verify that 'XATTR_SECURITY_PREFIX_LEN + strlen(sec->name) <= XATTR_NAME_MAX' and return EINVAL, but that really shouldn't be an issue and if the concatenation does result in a xattr name that is too big, the snprintf() will safely truncate/managle it. Regardless, this patch is fine with me, but it would be nice if at least of the reiserfs/VFS folks could provide an ACK/Reviewed-by tag, although I think we can still move forward on this without one of those. > - error = reiserfs_xattr_set_handle(th, inode, sec->name, sec->value, > + snprintf(xattr_name, sizeof(xattr_name), "%s%s", XATTR_SECURITY_PREFIX, > + sec->name); > + > + error = reiserfs_xattr_set_handle(th, inode, xattr_name, sec->value, > sec->length, XATTR_CREATE); > if (error == -ENODATA || error == -EOPNOTSUPP) > error = 0; > -- > 2.25.1
On Thu, 2023-03-30 at 17:15 -0400, Paul Moore wrote: > On Wed, Mar 29, 2023 at 9:05 AM Roberto Sassu > <roberto.sassu@huaweicloud.com> wrote: > > From: Roberto Sassu <roberto.sassu@huawei.com> > > > > Reiserfs sets a security xattr at inode creation time in two stages: first, > > it calls reiserfs_security_init() to obtain the xattr from active LSMs; > > then, it calls reiserfs_security_write() to actually write that xattr. > > > > Unfortunately, it seems there is a wrong expectation that LSMs provide the > > full xattr name in the form 'security.<suffix>'. However, LSMs always > > provided just the suffix, causing reiserfs to not write the xattr at all > > (if the suffix is shorter than the prefix), or to write an xattr with the > > wrong name. > > > > Add a temporary buffer in reiserfs_security_write(), and write to it the > > full xattr name, before passing it to reiserfs_xattr_set_handle(). > > > > Since the 'security.' prefix is always prepended, remove the name length > > check. > > > > Cc: stable@vger.kernel.org # v2.6.x > > Fixes: 57fe60df6241 ("reiserfs: add atomic addition of selinux attributes during inode creation") > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> > > --- > > fs/reiserfs/xattr_security.c | 8 +++++--- > > 1 file changed, 5 insertions(+), 3 deletions(-) > > > > diff --git a/fs/reiserfs/xattr_security.c b/fs/reiserfs/xattr_security.c > > index 6bffdf9a4fd..b0c354ab113 100644 > > --- a/fs/reiserfs/xattr_security.c > > +++ b/fs/reiserfs/xattr_security.c > > @@ -95,11 +95,13 @@ int reiserfs_security_write(struct reiserfs_transaction_handle *th, > > struct inode *inode, > > struct reiserfs_security_handle *sec) > > { > > + char xattr_name[XATTR_NAME_MAX + 1]; > > int error; > > - if (strlen(sec->name) < sizeof(XATTR_SECURITY_PREFIX)) > > - return -EINVAL; > > If one really wanted to be paranoid they could verify that > 'XATTR_SECURITY_PREFIX_LEN + strlen(sec->name) <= XATTR_NAME_MAX' and > return EINVAL, but that really shouldn't be an issue and if the > concatenation does result in a xattr name that is too big, the > snprintf() will safely truncate/managle it. Ok, I could do it. Thanks Roberto > Regardless, this patch is fine with me, but it would be nice if at > least of the reiserfs/VFS folks could provide an ACK/Reviewed-by tag, > although I think we can still move forward on this without one of > those. > > > - error = reiserfs_xattr_set_handle(th, inode, sec->name, sec->value, > > + snprintf(xattr_name, sizeof(xattr_name), "%s%s", XATTR_SECURITY_PREFIX, > > + sec->name); > > + > > + error = reiserfs_xattr_set_handle(th, inode, xattr_name, sec->value, > > sec->length, XATTR_CREATE); > > if (error == -ENODATA || error == -EOPNOTSUPP) > > error = 0; > > -- > > 2.25.1
diff --git a/fs/reiserfs/xattr_security.c b/fs/reiserfs/xattr_security.c index 6bffdf9a4fd..b0c354ab113 100644 --- a/fs/reiserfs/xattr_security.c +++ b/fs/reiserfs/xattr_security.c @@ -95,11 +95,13 @@ int reiserfs_security_write(struct reiserfs_transaction_handle *th, struct inode *inode, struct reiserfs_security_handle *sec) { + char xattr_name[XATTR_NAME_MAX + 1]; int error; - if (strlen(sec->name) < sizeof(XATTR_SECURITY_PREFIX)) - return -EINVAL; - error = reiserfs_xattr_set_handle(th, inode, sec->name, sec->value, + snprintf(xattr_name, sizeof(xattr_name), "%s%s", XATTR_SECURITY_PREFIX, + sec->name); + + error = reiserfs_xattr_set_handle(th, inode, xattr_name, sec->value, sec->length, XATTR_CREATE); if (error == -ENODATA || error == -EOPNOTSUPP) error = 0;