linux-kernel - Re: [PATCH v5 10/23] security: Introduce inode_post

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b0f6ece6579a5016243cca5c313d1a58cae6eff2.camel@huaweicloud.com>
Date:   Thu, 16 Nov 2023 10:43:18 +0100
From:   Roberto Sassu <roberto.sassu@...weicloud.com>
To:     Paul Moore <paul@...l-moore.com>, viro@...iv.linux.org.uk,
        brauner@...nel.org, chuck.lever@...cle.com, jlayton@...nel.org,
        neilb@...e.de, kolga@...app.com, Dai.Ngo@...cle.com,
        tom@...pey.com, jmorris@...ei.org, serge@...lyn.com,
        zohar@...ux.ibm.com, dmitry.kasatkin@...il.com,
        dhowells@...hat.com, jarkko@...nel.org,
        stephen.smalley.work@...il.com, eparis@...isplace.org,
        casey@...aufler-ca.com, mic@...ikod.net
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-nfs@...r.kernel.org, linux-security-module@...r.kernel.org,
        linux-integrity@...r.kernel.org, keyrings@...r.kernel.org,
        selinux@...r.kernel.org, Roberto Sassu <roberto.sassu@...wei.com>,
        Stefan Berger <stefanb@...ux.ibm.com>
Subject: Re: [PATCH v5 10/23] security: Introduce inode_post_setattr hook

On Wed, 2023-11-15 at 23:33 -0500, Paul Moore wrote:
> On Nov  7, 2023 Roberto Sassu <roberto.sassu@...weicloud.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@...wei.com>
> > Reviewed-by: Stefan Berger <stefanb@...ux.ibm.com>
> > Reviewed-by: Mimi Zohar <zohar@...ux.ibm.com>
> > Acked-by: Casey Schaufler <casey@...aufler-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