Message ID | 20231107134012.682009-11-roberto.sassu@huaweicloud.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:aa0b:0:b0:403:3b70:6f57 with SMTP id k11csp241974vqo; Tue, 7 Nov 2023 05:44:54 -0800 (PST) X-Google-Smtp-Source: AGHT+IG+GRSRONHe4vFl0jdj44oyWLyXMoAMA3qytuq9WPrCaNPOHFnjf9VYO4NUSPqT23Xxb3pL X-Received: by 2002:a05:6a20:a897:b0:163:2da1:387f with SMTP id ca23-20020a056a20a89700b001632da1387fmr21111156pzb.50.1699364694047; Tue, 07 Nov 2023 05:44:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699364694; cv=none; d=google.com; s=arc-20160816; b=hrAIQwudGGIAD0bMq5CDJX7knx1Wg9xvD6VXq+INZEAC6ex0dTu9yHU8Vr6UHTRuVj iNrAuxKpG5YLMFTuSG7917rd/rt4aqTxOXYm/7m/g3vspHFiM4pUINSVJJj/mmbaCzgk HHLDb5zTtRO2sN1wwepsXwxutDKZdF1UUimVBbHJK5wtY/IuZIamFD5i2s1UcIn7ejxW 2o0pAWCk23c3YmNe7ri5atGjL+b3+Ta7+FoR6Z/PTCwKctzmeXmWgcRpSZYsMs4uW3O9 7J5gMNpUwJKgC05s0i/UbPYDOnp4nhari5OPfmMhZ6HCrqBG9vlFaYvmvAQ7FpLpZpur n8yA== 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=40ESYfKQc/E8JYMFYZvpkNwAz4mJJs56bwwqhZHaJPA=; fh=0rZLbnWdi2+NGBdOm6VruOyaOm+3xLh8SfjCEj+mrTI=; b=CdcouUKHtPUwLtnNK1ExxaWlcn/nKDE2QJ3uapL6w2GfZLsu9JVWHGysev0T8ZGBBE bywkKDnWPwG8RLvNSZr4mrxpO0oxuIF3h4GaP0fTPBeXRo4IQXQe/o/zNmFMINa2ZTZs zQjSY0dK6Y8UyFmPFSyeBw+K3zlmSaevmQ9dikSqeVAteU4X2dD3JOZlIK8NG9W7yFyx i99bKDFAAUNcA0fLt7TiHRybGef5ZE12aSqsqTDjc7CAh5zpC0PlI4e4baaSwIzhUtlq 0+XyVgpuyy3GrolpsBaxqMi07RFfKi2ktS7OFj9faVGI4WOK94cfmPvY4XJn9L3bU9it N2gQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id nm10-20020a17090b19ca00b002803c4a0684si10053050pjb.189.2023.11.07.05.44.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Nov 2023 05:44:54 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id BE8CC81D80AA; Tue, 7 Nov 2023 05:44:52 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234199AbjKGNos (ORCPT <rfc822;lhua1029@gmail.com> + 32 others); Tue, 7 Nov 2023 08:44:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37748 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229607AbjKGNor (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 7 Nov 2023 08:44:47 -0500 Received: from frasgout11.his.huawei.com (frasgout11.his.huawei.com [14.137.139.23]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 43D58A2; Tue, 7 Nov 2023 05:44:44 -0800 (PST) Received: from mail02.huawei.com (unknown [172.18.147.228]) by frasgout11.his.huawei.com (SkyGuard) with ESMTP id 4SPpyd2Rhqz9y5gb; Tue, 7 Nov 2023 21:31:21 +0800 (CST) Received: from huaweicloud.com (unknown [10.204.63.22]) by APP1 (Coremail) with SMTP id LxC2BwAnFXUiP0plvHc3AA--.54683S2; Tue, 07 Nov 2023 14:44:16 +0100 (CET) From: Roberto Sassu <roberto.sassu@huaweicloud.com> To: 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, paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com, zohar@linux.ibm.com, dmitry.kasatkin@gmail.com, dhowells@redhat.com, jarkko@kernel.org, stephen.smalley.work@gmail.com, eparis@parisplace.org, casey@schaufler-ca.com, mic@digikod.net Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-security-module@vger.kernel.org, linux-integrity@vger.kernel.org, keyrings@vger.kernel.org, selinux@vger.kernel.org, Roberto Sassu <roberto.sassu@huawei.com>, Stefan Berger <stefanb@linux.ibm.com> Subject: [PATCH v5 10/23] security: Introduce inode_post_setattr hook Date: Tue, 7 Nov 2023 14:39:59 +0100 Message-Id: <20231107134012.682009-11-roberto.sassu@huaweicloud.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20231107134012.682009-1-roberto.sassu@huaweicloud.com> References: <20231107134012.682009-1-roberto.sassu@huaweicloud.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: LxC2BwAnFXUiP0plvHc3AA--.54683S2 X-Coremail-Antispam: 1UD129KBjvJXoWxurykAw17WFW5XF48Cw18AFb_yoWrWF4xpF WrK3WDKw4rWFW7WrykJF47ua1SgFy5urWUXrWvgwn0yFn7tw1aqF43Ka4jkr13GrW8Gr9I q3ZFvrsxCr15AwUanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkqb4IE77IF4wAFF20E14v26rWj6s0DM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26r4j6F4UM28EF7xvwVC2z280aVCY1x 0267AKxVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02 F40Ex7xfMcIj6xIIjxv20xvE14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4I kC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFIxGxcIEc7CjxVA2Y2ka0xkIwI1l42xK 82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGw C20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r4a6rW5MIIYrxkI7VAKI48J MIIF0xvE2Ix0cI8IcVAFwI0_Gr0_Xr1lIxAIcVC0I7IYx2IY6xkF7I0E14v26r4UJVWxJr 1lIxAIcVCF04k26cxKx2IYs7xG6Fyj6rWUJwCI42IY6I8E87Iv67AKxVW8JVWxJwCI42IY 6I8E87Iv6xkF7I0E14v26r4UJVWxJrUvcSsGvfC2KfnxnUUI43ZEXa7IUbHa0PUUUUU== X-CM-SenderInfo: purev21wro2thvvxqx5xdzvxpfor3voofrz/1tbiAgAOBF1jj5IbdgAAsG X-CFilter-Loop: Reflected X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham 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-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 07 Nov 2023 05:44:52 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781913033706895835 X-GMAIL-MSGID: 1781913033706895835 |
Series |
security: Move IMA and EVM to the LSM infrastructure
|
|
Commit Message
Roberto Sassu
Nov. 7, 2023, 1:39 p.m. UTC
From: Roberto Sassu <roberto.sassu@huawei.com> In preparation for moving IMA and EVM to the LSM infrastructure, introduce the inode_post_setattr hook. At inode_setattr hook, EVM verifies the file's existing HMAC value. At inode_post_setattr, EVM re-calculates the file's HMAC based on the modified file attributes and other file metadata. Other LSMs could similarly take some action after successful file attribute change. The new hook cannot return an error and cannot cause the operation to be reverted. Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> --- fs/attr.c | 1 + include/linux/lsm_hook_defs.h | 2 ++ include/linux/security.h | 7 +++++++ security/security.c | 16 ++++++++++++++++ 4 files changed, 26 insertions(+)
Comments
On 11/7/2023 5:39 AM, Roberto Sassu wrote: > From: Roberto Sassu <roberto.sassu@huawei.com> > > In preparation for moving IMA and EVM to the LSM infrastructure, introduce > the inode_post_setattr hook. > > At inode_setattr hook, EVM verifies the file's existing HMAC value. At > inode_post_setattr, EVM re-calculates the file's HMAC based on the modified > file attributes and other file metadata. > > Other LSMs could similarly take some action after successful file attribute > change. > > The new hook cannot return an error and cannot cause the operation to be > reverted. > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> > Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> > Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Casey Schaufler <casey@schaufler-ca.com> > --- > fs/attr.c | 1 + > include/linux/lsm_hook_defs.h | 2 ++ > include/linux/security.h | 7 +++++++ > security/security.c | 16 ++++++++++++++++ > 4 files changed, 26 insertions(+) > > diff --git a/fs/attr.c b/fs/attr.c > index 498e673bdf06..221d2bb0a906 100644 > --- a/fs/attr.c > +++ b/fs/attr.c > @@ -502,6 +502,7 @@ int notify_change(struct mnt_idmap *idmap, struct dentry *dentry, > > if (!error) { > fsnotify_change(dentry, ia_valid); > + security_inode_post_setattr(idmap, dentry, ia_valid); > ima_inode_post_setattr(idmap, dentry, ia_valid); > evm_inode_post_setattr(idmap, dentry, ia_valid); > } > diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h > index f5db5e993cd8..67410e085205 100644 > --- a/include/linux/lsm_hook_defs.h > +++ b/include/linux/lsm_hook_defs.h > @@ -137,6 +137,8 @@ LSM_HOOK(int, 0, inode_follow_link, struct dentry *dentry, struct inode *inode, > LSM_HOOK(int, 0, inode_permission, struct inode *inode, int mask) > LSM_HOOK(int, 0, inode_setattr, struct mnt_idmap *idmap, struct dentry *dentry, > struct iattr *attr) > +LSM_HOOK(void, LSM_RET_VOID, inode_post_setattr, struct mnt_idmap *idmap, > + struct dentry *dentry, int ia_valid) > LSM_HOOK(int, 0, inode_getattr, const struct path *path) > LSM_HOOK(int, 0, inode_setxattr, struct mnt_idmap *idmap, > struct dentry *dentry, const char *name, const void *value, > diff --git a/include/linux/security.h b/include/linux/security.h > index 750130a7b9dd..664df46b22a9 100644 > --- a/include/linux/security.h > +++ b/include/linux/security.h > @@ -361,6 +361,8 @@ int security_inode_follow_link(struct dentry *dentry, struct inode *inode, > int security_inode_permission(struct inode *inode, int mask); > int security_inode_setattr(struct mnt_idmap *idmap, > struct dentry *dentry, struct iattr *attr); > +void security_inode_post_setattr(struct mnt_idmap *idmap, struct dentry *dentry, > + int ia_valid); > int security_inode_getattr(const struct path *path); > int security_inode_setxattr(struct mnt_idmap *idmap, > struct dentry *dentry, const char *name, > @@ -877,6 +879,11 @@ static inline int security_inode_setattr(struct mnt_idmap *idmap, > return 0; > } > > +static inline void > +security_inode_post_setattr(struct mnt_idmap *idmap, struct dentry *dentry, > + int ia_valid) > +{ } > + > static inline int security_inode_getattr(const struct path *path) > { > return 0; > diff --git a/security/security.c b/security/security.c > index 7935d11d58b5..ce3bc7642e18 100644 > --- a/security/security.c > +++ b/security/security.c > @@ -2222,6 +2222,22 @@ int security_inode_setattr(struct mnt_idmap *idmap, > } > EXPORT_SYMBOL_GPL(security_inode_setattr); > > +/** > + * security_inode_post_setattr() - Update the inode after a setattr operation > + * @idmap: idmap of the mount > + * @dentry: file > + * @ia_valid: file attributes set > + * > + * Update inode security field after successful setting file attributes. > + */ > +void security_inode_post_setattr(struct mnt_idmap *idmap, struct dentry *dentry, > + int ia_valid) > +{ > + if (unlikely(IS_PRIVATE(d_backing_inode(dentry)))) > + return; > + call_void_hook(inode_post_setattr, idmap, dentry, ia_valid); > +} > + > /** > * security_inode_getattr() - Check if getting file attributes is allowed > * @path: file
On Nov 7, 2023 Roberto Sassu <roberto.sassu@huaweicloud.com> wrote: > > In preparation for moving IMA and EVM to the LSM infrastructure, introduce > the inode_post_setattr hook. > > At inode_setattr hook, EVM verifies the file's existing HMAC value. At > inode_post_setattr, EVM re-calculates the file's HMAC based on the modified > file attributes and other file metadata. > > Other LSMs could similarly take some action after successful file attribute > change. > > The new hook cannot return an error and cannot cause the operation to be > reverted. > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> > Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> > Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> > Acked-by: Casey Schaufler <casey@schaufler-ca.com> > --- > fs/attr.c | 1 + > include/linux/lsm_hook_defs.h | 2 ++ > include/linux/security.h | 7 +++++++ > security/security.c | 16 ++++++++++++++++ > 4 files changed, 26 insertions(+) ... > diff --git a/security/security.c b/security/security.c > index 7935d11d58b5..ce3bc7642e18 100644 > --- a/security/security.c > +++ b/security/security.c > @@ -2222,6 +2222,22 @@ int security_inode_setattr(struct mnt_idmap *idmap, > } > EXPORT_SYMBOL_GPL(security_inode_setattr); > > +/** > + * security_inode_post_setattr() - Update the inode after a setattr operation > + * @idmap: idmap of the mount > + * @dentry: file > + * @ia_valid: file attributes set > + * > + * Update inode security field after successful setting file attributes. > + */ > +void security_inode_post_setattr(struct mnt_idmap *idmap, struct dentry *dentry, > + int ia_valid) > +{ > + if (unlikely(IS_PRIVATE(d_backing_inode(dentry)))) > + return; I may be missing it, but I don't see the S_PRIVATE flag check in the existing IMA or EVM hooks so I'm curious as to why it is added here? Please don't misunderstand me, I think it makes sense to return early on private dentrys/inodes, but why aren't we doing that now? > + call_void_hook(inode_post_setattr, idmap, dentry, ia_valid); > +} > + > /** > * security_inode_getattr() - Check if getting file attributes is allowed > * @path: file > -- > 2.34.1 -- paul-moore.com
On Wed, 2023-11-15 at 23:33 -0500, Paul Moore wrote: > On Nov 7, 2023 Roberto Sassu <roberto.sassu@huaweicloud.com> wrote: > > > > In preparation for moving IMA and EVM to the LSM infrastructure, introduce > > the inode_post_setattr hook. > > > > At inode_setattr hook, EVM verifies the file's existing HMAC value. At > > inode_post_setattr, EVM re-calculates the file's HMAC based on the modified > > file attributes and other file metadata. > > > > Other LSMs could similarly take some action after successful file attribute > > change. > > > > The new hook cannot return an error and cannot cause the operation to be > > reverted. > > > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> > > Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> > > Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> > > Acked-by: Casey Schaufler <casey@schaufler-ca.com> > > --- > > fs/attr.c | 1 + > > include/linux/lsm_hook_defs.h | 2 ++ > > include/linux/security.h | 7 +++++++ > > security/security.c | 16 ++++++++++++++++ > > 4 files changed, 26 insertions(+) > > ... > > > diff --git a/security/security.c b/security/security.c > > index 7935d11d58b5..ce3bc7642e18 100644 > > --- a/security/security.c > > +++ b/security/security.c > > @@ -2222,6 +2222,22 @@ int security_inode_setattr(struct mnt_idmap *idmap, > > } > > EXPORT_SYMBOL_GPL(security_inode_setattr); > > > > +/** > > + * security_inode_post_setattr() - Update the inode after a setattr operation > > + * @idmap: idmap of the mount > > + * @dentry: file > > + * @ia_valid: file attributes set > > + * > > + * Update inode security field after successful setting file attributes. > > + */ > > +void security_inode_post_setattr(struct mnt_idmap *idmap, struct dentry *dentry, > > + int ia_valid) > > +{ > > + if (unlikely(IS_PRIVATE(d_backing_inode(dentry)))) > > + return; > > I may be missing it, but I don't see the S_PRIVATE flag check in the > existing IMA or EVM hooks so I'm curious as to why it is added here? > Please don't misunderstand me, I think it makes sense to return early > on private dentrys/inodes, but why aren't we doing that now? My first motivation was that it is in the pre hooks, so it should be in the post hook as well. Thinking more about it, suppose that the post don't have the check, private inodes would gain an HMAC without checking the validity of the current HMAC first (done in the pre hooks), which would be even worse. So, my idea about this is that at least we are consistent. If IMA and EVM should look at private inodes is a different question, which would require a discussion. Thanks Roberto > > + call_void_hook(inode_post_setattr, idmap, dentry, ia_valid); > > +} > > + > > /** > > * security_inode_getattr() - Check if getting file attributes is allowed > > * @path: file > > -- > > 2.34.1 > > -- > paul-moore.com
On Thu, Nov 16, 2023 at 4:44 AM Roberto Sassu <roberto.sassu@huaweicloud.com> wrote: > On Wed, 2023-11-15 at 23:33 -0500, Paul Moore wrote: > > On Nov 7, 2023 Roberto Sassu <roberto.sassu@huaweicloud.com> wrote: > > > > > > In preparation for moving IMA and EVM to the LSM infrastructure, introduce > > > the inode_post_setattr hook. > > > > > > At inode_setattr hook, EVM verifies the file's existing HMAC value. At > > > inode_post_setattr, EVM re-calculates the file's HMAC based on the modified > > > file attributes and other file metadata. > > > > > > Other LSMs could similarly take some action after successful file attribute > > > change. > > > > > > The new hook cannot return an error and cannot cause the operation to be > > > reverted. > > > > > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> > > > Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> > > > Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> > > > Acked-by: Casey Schaufler <casey@schaufler-ca.com> > > > --- > > > fs/attr.c | 1 + > > > include/linux/lsm_hook_defs.h | 2 ++ > > > include/linux/security.h | 7 +++++++ > > > security/security.c | 16 ++++++++++++++++ > > > 4 files changed, 26 insertions(+) > > > > ... > > > > > diff --git a/security/security.c b/security/security.c > > > index 7935d11d58b5..ce3bc7642e18 100644 > > > --- a/security/security.c > > > +++ b/security/security.c > > > @@ -2222,6 +2222,22 @@ int security_inode_setattr(struct mnt_idmap *idmap, > > > } > > > EXPORT_SYMBOL_GPL(security_inode_setattr); > > > > > > +/** > > > + * security_inode_post_setattr() - Update the inode after a setattr operation > > > + * @idmap: idmap of the mount > > > + * @dentry: file > > > + * @ia_valid: file attributes set > > > + * > > > + * Update inode security field after successful setting file attributes. > > > + */ > > > +void security_inode_post_setattr(struct mnt_idmap *idmap, struct dentry *dentry, > > > + int ia_valid) > > > +{ > > > + if (unlikely(IS_PRIVATE(d_backing_inode(dentry)))) > > > + return; > > > > I may be missing it, but I don't see the S_PRIVATE flag check in the > > existing IMA or EVM hooks so I'm curious as to why it is added here? > > Please don't misunderstand me, I think it makes sense to return early > > on private dentrys/inodes, but why aren't we doing that now? > > My first motivation was that it is in the pre hooks, so it should be in > the post hook as well. > > Thinking more about it, suppose that the post don't have the check, > private inodes would gain an HMAC without checking the validity of the > current HMAC first (done in the pre hooks), which would be even worse. > > So, my idea about this is that at least we are consistent. > > If IMA and EVM should look at private inodes is a different question, > which would require a discussion. As I said above, I can understand why having the IS_PRIVATE() macro check might be a good idea, I am just concerned that the current IMA/EVM hooks don't check for S_PRIVATE and thus moving to this new LSM hook would potentially be a change in behavior (like I said, I could be missing a subtle detail). I'd just like a quick confirmation from Mimi that either there is no difference because of X, or she is aware of the difference and is okay with it. It's very possible she is fine with it, she did provide her 'Reviewed-by', but I worry this is the sort of thing that might have gone unnoticed during review.
diff --git a/fs/attr.c b/fs/attr.c index 498e673bdf06..221d2bb0a906 100644 --- a/fs/attr.c +++ b/fs/attr.c @@ -502,6 +502,7 @@ int notify_change(struct mnt_idmap *idmap, struct dentry *dentry, if (!error) { fsnotify_change(dentry, ia_valid); + security_inode_post_setattr(idmap, dentry, ia_valid); ima_inode_post_setattr(idmap, dentry, ia_valid); evm_inode_post_setattr(idmap, dentry, ia_valid); } diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h index f5db5e993cd8..67410e085205 100644 --- a/include/linux/lsm_hook_defs.h +++ b/include/linux/lsm_hook_defs.h @@ -137,6 +137,8 @@ LSM_HOOK(int, 0, inode_follow_link, struct dentry *dentry, struct inode *inode, LSM_HOOK(int, 0, inode_permission, struct inode *inode, int mask) LSM_HOOK(int, 0, inode_setattr, struct mnt_idmap *idmap, struct dentry *dentry, struct iattr *attr) +LSM_HOOK(void, LSM_RET_VOID, inode_post_setattr, struct mnt_idmap *idmap, + struct dentry *dentry, int ia_valid) LSM_HOOK(int, 0, inode_getattr, const struct path *path) LSM_HOOK(int, 0, inode_setxattr, struct mnt_idmap *idmap, struct dentry *dentry, const char *name, const void *value, diff --git a/include/linux/security.h b/include/linux/security.h index 750130a7b9dd..664df46b22a9 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -361,6 +361,8 @@ int security_inode_follow_link(struct dentry *dentry, struct inode *inode, int security_inode_permission(struct inode *inode, int mask); int security_inode_setattr(struct mnt_idmap *idmap, struct dentry *dentry, struct iattr *attr); +void security_inode_post_setattr(struct mnt_idmap *idmap, struct dentry *dentry, + int ia_valid); int security_inode_getattr(const struct path *path); int security_inode_setxattr(struct mnt_idmap *idmap, struct dentry *dentry, const char *name, @@ -877,6 +879,11 @@ static inline int security_inode_setattr(struct mnt_idmap *idmap, return 0; } +static inline void +security_inode_post_setattr(struct mnt_idmap *idmap, struct dentry *dentry, + int ia_valid) +{ } + static inline int security_inode_getattr(const struct path *path) { return 0; diff --git a/security/security.c b/security/security.c index 7935d11d58b5..ce3bc7642e18 100644 --- a/security/security.c +++ b/security/security.c @@ -2222,6 +2222,22 @@ int security_inode_setattr(struct mnt_idmap *idmap, } EXPORT_SYMBOL_GPL(security_inode_setattr); +/** + * security_inode_post_setattr() - Update the inode after a setattr operation + * @idmap: idmap of the mount + * @dentry: file + * @ia_valid: file attributes set + * + * Update inode security field after successful setting file attributes. + */ +void security_inode_post_setattr(struct mnt_idmap *idmap, struct dentry *dentry, + int ia_valid) +{ + if (unlikely(IS_PRIVATE(d_backing_inode(dentry)))) + return; + call_void_hook(inode_post_setattr, idmap, dentry, ia_valid); +} + /** * security_inode_getattr() - Check if getting file attributes is allowed * @path: file