Received: by 2002:a05:7412:d8a:b0:e2:908c:2ebd with SMTP id b10csp314317rdg; Thu, 12 Oct 2023 06:34:54 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGeHuuvXC7eQxAMZKZR83lSuMSLv2XkjZNLIx37tLrGc2zyeAVwECsWu+iKJG19l1azDlVN X-Received: by 2002:a05:6a20:e11c:b0:175:6c37:836d with SMTP id kr28-20020a056a20e11c00b001756c37836dmr1315374pzb.35.1697117693876; Thu, 12 Oct 2023 06:34:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697117693; cv=none; d=google.com; s=arc-20160816; b=MCq6vPt7vzeJt+0AWTfVarcw8ybjZTLgWt7S55oC1VQWT7V4CuHmHwfN453YXdiQLe ru0eH0oXHcv8JdIpvF7AH7k8g3+wbS8MCG1zIqnFp3Iy0wevJxe9DgqSYhzQM6pM2W2A ePDuLgOMBrSFLSo8SyUNKEYby1LUpd+yoEofoeSKyngnj84Lta9q/877IzZpzVTQ0L1C j5nQsfDFcBVOJTqoGP/v6QeYS0s0ipV8H4wJkK6yzKTeTmw+XQsNgdej65vIl7lGqzAT 7wZarwMRrPh0Ni+EKtp/XUe5JR/Lrc0TJ8YY8FMNHBG4WvrF19hxH/RNa7PmoDx43beT 9HdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent :content-transfer-encoding:references:in-reply-to:date:cc:to:from :subject:message-id; bh=jYIgWMaT8D21vhjV6rlVIYvf42X/49oGNI2G60KFGl4=; fh=yjYWj0LaGhbIyHSUS30fEXRi+5FXXRF+m32ev5/qNgI=; b=P8nERgiUHImdVcUDscJokuTXxK0aXBgztNWWJEL59y+xPTLOkDbwEIBW0RXHCduyaE Z382s4rbtnPyIkJjEcW8d/9zYvONdGnLXF5yrOITKxZc4INwzntkCNUQVy9WAmKXqtX1 62GZy/yaZZA0xT1zkMCpTxGp6rztI7JHOTCMsImo2NkjM2Iarik3Vdp0Y2XvDx7Vvqx6 dFQnCXzQVIVIYapW36avO62Y/6+vl4DWgTZKg94che42jnLDaAZy2x2rcjAfeIviKykE mYhRK0dLxVHHLc838ndDkIVwy/GHObbvcu8jCAoBdGn/Hy+jwrzPu6BLlFdDtB3w2Eyq /fvw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from pete.vger.email (pete.vger.email. [23.128.96.36]) by mx.google.com with ESMTPS id t62-20020a638141000000b00588fa0def1fsi2226153pgd.774.2023.10.12.06.34.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Oct 2023 06:34:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id CD44081B17DB; Thu, 12 Oct 2023 06:34:36 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347263AbjJLNef convert rfc822-to-8bit (ORCPT + 99 others); Thu, 12 Oct 2023 09:34:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44144 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347271AbjJLNef (ORCPT ); Thu, 12 Oct 2023 09:34:35 -0400 Received: from frasgout13.his.huawei.com (frasgout13.his.huawei.com [14.137.139.46]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8D41694; Thu, 12 Oct 2023 06:34:30 -0700 (PDT) Received: from mail02.huawei.com (unknown [172.18.147.228]) by frasgout13.his.huawei.com (SkyGuard) with ESMTP id 4S5qzR1lnGz9y0hP; Thu, 12 Oct 2023 21:21:39 +0800 (CST) Received: from [127.0.0.1] (unknown [10.204.63.22]) by APP2 (Coremail) with SMTP id GxC2BwDXera79Sdl_EcMAg--.35445S2; Thu, 12 Oct 2023 14:34:01 +0100 (CET) Message-ID: <4866a6ef46deebf9a9afdeb7efd600edb589da93.camel@huaweicloud.com> Subject: Re: [PATCH v3 02/25] ima: Align ima_post_path_mknod() definition with LSM infrastructure From: Roberto Sassu To: Mimi Zohar , viro@zeniv.linux.org.uk, brauner@kernel.org, chuck.lever@oracle.com, jlayton@kernel.org, neilb@suse.de, kolga@netapp.com, Dai.Ngo@oracle.com, tom@talpey.com, dmitry.kasatkin@gmail.com, paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com, dhowells@redhat.com, jarkko@kernel.org, stephen.smalley.work@gmail.com, eparis@parisplace.org, casey@schaufler-ca.com Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, selinux@vger.kernel.org, Roberto Sassu Date: Thu, 12 Oct 2023 15:33:44 +0200 In-Reply-To: <84cfe4d93cb5b02591f4bd921b828eb6f3e95faa.camel@linux.ibm.com> References: <20230904133415.1799503-1-roberto.sassu@huaweicloud.com> <20230904133415.1799503-3-roberto.sassu@huaweicloud.com> <8646e30b0074a2932076b5a0a792b14be034de98.camel@linux.ibm.com> <16c8c95f2e63ab9a2fba8cba919bf129d0541b61.camel@huaweicloud.com> <2336abd6ae195eda221d54e3c2349a4760afaff2.camel@huaweicloud.com> <84cfe4d93cb5b02591f4bd921b828eb6f3e95faa.camel@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT User-Agent: Evolution 3.44.4-0ubuntu2 MIME-Version: 1.0 X-CM-TRANSID: GxC2BwDXera79Sdl_EcMAg--.35445S2 X-Coremail-Antispam: 1UD129KBjvJXoW3WrWfWFyfWr4DJF17XFWxXrb_yoWxKr43pF W8J3WDGr4DJry7Cr10va15A34Sq34UJr1UXr1Ygw17Jr1Dtr1DXF18Gr1Y9rWrGr4UGr1U XF1Utr9xurWUArJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkFb4IE77IF4wAFF20E14v26rWj6s0DM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIEc7CjxV AFwI0_Gr1j6F4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7MxAIw28IcxkI 7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxV Cjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVW8ZVWrXwCIc40Y0x0EwIxGrwCI42IY 6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6x AIw20EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280 aVCY1x0267AKxVW8Jr0_Cr1UYxBIdaVFxhVjvjDU0xZFpf9x07UAkuxUUUUU= X-CM-SenderInfo: purev21wro2thvvxqx5xdzvxpfor3voofrz/1tbiAgAIBF1jj5DzWQABsE X-CFilter-Loop: Reflected X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Thu, 12 Oct 2023 06:34:37 -0700 (PDT) On Thu, 2023-10-12 at 09:25 -0400, Mimi Zohar wrote: > On Thu, 2023-10-12 at 14:19 +0200, Roberto Sassu wrote: > > On Thu, 2023-10-12 at 07:42 -0400, Mimi Zohar wrote: > > > On Thu, 2023-10-12 at 09:29 +0200, Roberto Sassu wrote: > > > > On Wed, 2023-10-11 at 15:01 -0400, Mimi Zohar wrote: > > > > > On Wed, 2023-10-11 at 18:02 +0200, Roberto Sassu wrote: > > > > > > On Wed, 2023-10-11 at 10:38 -0400, Mimi Zohar wrote: > > > > > > > On Mon, 2023-09-04 at 15:33 +0200, Roberto Sassu wrote: > > > > > > > > From: Roberto Sassu > > > > > > > > > > > > > > > > Change ima_post_path_mknod() definition, so that it can be registered as > > > > > > > > implementation of the path_post_mknod hook. Since LSMs see a umask-stripped > > > > > > > > mode from security_path_mknod(), pass the same to ima_post_path_mknod() as > > > > > > > > well. > > > > > > > > Also, make sure that ima_post_path_mknod() is executed only if > > > > > > > > (mode & S_IFMT) is equal to zero or S_IFREG. > > > > > > > > > > > > > > > > Add this check to take into account the different placement of the > > > > > > > > path_post_mknod hook (to be introduced) in do_mknodat(). > > > > > > > > > > > > > > Move "(to be introduced)" to when it is first mentioned. > > > > > > > > > > > > > > > Since the new hook > > > > > > > > will be placed after the switch(), the check ensures that > > > > > > > > ima_post_path_mknod() is invoked as originally intended when it is > > > > > > > > registered as implementation of path_post_mknod. > > > > > > > > > > > > > > > > Signed-off-by: Roberto Sassu > > > > > > > > --- > > > > > > > > fs/namei.c | 9 ++++++--- > > > > > > > > include/linux/ima.h | 7 +++++-- > > > > > > > > security/integrity/ima/ima_main.c | 10 +++++++++- > > > > > > > > 3 files changed, 20 insertions(+), 6 deletions(-) > > > > > > > > > > > > > > > > diff --git a/fs/namei.c b/fs/namei.c > > > > > > > > index e56ff39a79bc..c5e96f716f98 100644 > > > > > > > > --- a/fs/namei.c > > > > > > > > +++ b/fs/namei.c > > > > > > > > @@ -4024,6 +4024,7 @@ static int do_mknodat(int dfd, struct filename *name, umode_t mode, > > > > > > > > struct path path; > > > > > > > > int error; > > > > > > > > unsigned int lookup_flags = 0; > > > > > > > > + umode_t mode_stripped; > > > > > > > > > > > > > > > > error = may_mknod(mode); > > > > > > > > if (error) > > > > > > > > @@ -4034,8 +4035,9 @@ static int do_mknodat(int dfd, struct filename *name, umode_t mode, > > > > > > > > if (IS_ERR(dentry)) > > > > > > > > goto out1; > > > > > > > > > > > > > > > > - error = security_path_mknod(&path, dentry, > > > > > > > > - mode_strip_umask(path.dentry->d_inode, mode), dev); > > > > > > > > + mode_stripped = mode_strip_umask(path.dentry->d_inode, mode); > > > > > > > > + > > > > > > > > + error = security_path_mknod(&path, dentry, mode_stripped, dev); > > > > > > > > if (error) > > > > > > > > goto out2; > > > > > > > > > > > > > > > > @@ -4045,7 +4047,8 @@ static int do_mknodat(int dfd, struct filename *name, umode_t mode, > > > > > > > > error = vfs_create(idmap, path.dentry->d_inode, > > > > > > > > dentry, mode, true); > > > > > > > > if (!error) > > > > > > > > - ima_post_path_mknod(idmap, dentry); > > > > > > > > + ima_post_path_mknod(idmap, &path, dentry, > > > > > > > > + mode_stripped, dev); > > > > > > > > break; > > > > > > > > case S_IFCHR: case S_IFBLK: > > > > > > > > error = vfs_mknod(idmap, path.dentry->d_inode, > > > > > > > > diff --git a/include/linux/ima.h b/include/linux/ima.h > > > > > > > > index 910a2f11a906..179ce52013b2 100644 > > > > > > > > --- a/include/linux/ima.h > > > > > > > > +++ b/include/linux/ima.h > > > > > > > > @@ -32,7 +32,8 @@ extern int ima_read_file(struct file *file, enum kernel_read_file_id id, > > > > > > > > extern int ima_post_read_file(struct file *file, void *buf, loff_t size, > > > > > > > > enum kernel_read_file_id id); > > > > > > > > extern void ima_post_path_mknod(struct mnt_idmap *idmap, > > > > > > > > - struct dentry *dentry); > > > > > > > > + const struct path *dir, struct dentry *dentry, > > > > > > > > + umode_t mode, unsigned int dev); > > > > > > > > extern int ima_file_hash(struct file *file, char *buf, size_t buf_size); > > > > > > > > extern int ima_inode_hash(struct inode *inode, char *buf, size_t buf_size); > > > > > > > > extern void ima_kexec_cmdline(int kernel_fd, const void *buf, int size); > > > > > > > > @@ -114,7 +115,9 @@ static inline int ima_post_read_file(struct file *file, void *buf, loff_t size, > > > > > > > > } > > > > > > > > > > > > > > > > static inline void ima_post_path_mknod(struct mnt_idmap *idmap, > > > > > > > > - struct dentry *dentry) > > > > > > > > + const struct path *dir, > > > > > > > > + struct dentry *dentry, > > > > > > > > + umode_t mode, unsigned int dev) > > > > > > > > { > > > > > > > > return; > > > > > > > > } > > > > > > > > diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c > > > > > > > > index 365db0e43d7c..76eba92d7f10 100644 > > > > > > > > --- a/security/integrity/ima/ima_main.c > > > > > > > > +++ b/security/integrity/ima/ima_main.c > > > > > > > > @@ -696,18 +696,26 @@ void ima_post_create_tmpfile(struct mnt_idmap *idmap, > > > > > > > > /** > > > > > > > > * ima_post_path_mknod - mark as a new inode > > > > > > > > * @idmap: idmap of the mount the inode was found from > > > > > > > > + * @dir: path structure of parent of the new file > > > > > > > > * @dentry: newly created dentry > > > > > > > > + * @mode: mode of the new file > > > > > > > > + * @dev: undecoded device number > > > > > > > > * > > > > > > > > * Mark files created via the mknodat syscall as new, so that the > > > > > > > > * file data can be written later. > > > > > > > > */ > > > > > > > > void ima_post_path_mknod(struct mnt_idmap *idmap, > > > > > > > > - struct dentry *dentry) > > > > > > > > + const struct path *dir, struct dentry *dentry, > > > > > > > > + umode_t mode, unsigned int dev) > > > > > > > > { > > > > > > > > struct integrity_iint_cache *iint; > > > > > > > > struct inode *inode = dentry->d_inode; > > > > > > > > int must_appraise; > > > > > > > > > > > > > > > > + /* See do_mknodat(), IMA is executed for case 0: and case S_IFREG: */ > > > > > > > > + if ((mode & S_IFMT) != 0 && (mode & S_IFMT) != S_IFREG) > > > > > > > > + return; > > > > > > > > + > > > > > > > > > > > > > > There's already a check below to make sure that this is a regular file. > > > > > > > Are both needed? > > > > > > > > > > > > You are right, I can remove the first check. > > > > > > > > > > The question then becomes why modify hook the arguments? > > > > > > > > We need to make sure that ima_post_path_mknod() has the same parameters > > > > as the LSM hook at the time we register it to the LSM infrastructure. > > > > > > I'm trying to understand why the pre hook parameters and the missing > > > IMA parameter are used, as opposed to just defining the new > > > post_path_mknod hook like IMA. > > > > As an empyrical rule, I pass the same parameters as the corresponding > > pre hook (plus idmap, in this case). This is similar to the > > inode_setxattr hook. But I can be wrong, if desired I can reduce. > > The inode_setxattr hook change example is legitimate, as EVM includes > idmap, while IMA doesn't. > > Unless there is a good reason for the additional parameters, I'm not > sure that adding them makes sense. Not modifying the parameter list > will reduce the size of this patch set. The hook is going to be used by any LSM. Without knowing all the possible use cases, maybe it is better to include more information now, than modifying the hook and respective implementations later. (again, no problem to reduce) Thanks Roberto