linux-kernel - Re: [PATCH v5 11/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: <CAHC9VhTPC6_dR0ymPtktVfi9rcFrnqXZL8Cq+c58OiijTRgOxg@mail.gmail.com>
Date:   Mon, 20 Nov 2023 15:55:54 -0500
From:   Paul Moore <paul@...l-moore.com>
To:     Casey Schaufler <casey@...aufler-ca.com>
Cc:     Roberto Sassu <roberto.sassu@...weicloud.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,
        mic@...ikod.net, 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 11/23] security: Introduce inode_post_removexattr hook

On Mon, Nov 20, 2023 at 1:04 PM Casey Schaufler <casey@...aufler-ca.com> wrote:
> On 11/20/2023 9:31 AM, Roberto Sassu wrote:
> > On Tue, 2023-11-07 at 09:33 -0800, Casey Schaufler wrote:
> >> On 11/7/2023 5:40 AM, Roberto Sassu wrote:
> >>> From: Roberto Sassu <roberto.sassu@...wei.com>
> >>>
> >>> In preparation for moving IMA and EVM to the LSM infrastructure, introduce
> >>> the inode_post_removexattr hook.
> >>>
> >>> At inode_removexattr hook, EVM verifies the file's existing HMAC value. At
> >>> inode_post_removexattr, EVM re-calculates the file's HMAC with the passed
> >>> xattr removed and other file metadata.
> >>>
> >>> Other LSMs could similarly take some action after successful xattr removal.
> >>>
> >>> 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>
> >>> ---
> >>>  fs/xattr.c                    |  9 +++++----
> >>>  include/linux/lsm_hook_defs.h |  2 ++
> >>>  include/linux/security.h      |  5 +++++
> >>>  security/security.c           | 14 ++++++++++++++
> >>>  4 files changed, 26 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/fs/xattr.c b/fs/xattr.c
> >>> index 09d927603433..84a4aa566c02 100644
> >>> --- a/fs/xattr.c
> >>> +++ b/fs/xattr.c
> >>> @@ -552,11 +552,12 @@ __vfs_removexattr_locked(struct mnt_idmap *idmap,
> >>>             goto out;
> >>>
> >>>     error = __vfs_removexattr(idmap, dentry, name);
> >>> +   if (error)
> >>> +           goto out;
> >> Shouldn't this be simply "return error" rather than a goto to nothing
> >> but "return error"?
> > I got a review from Andrew Morton. His argument seems convincing, that
> > having less return places makes the code easier to handle.
>
> That was in a case where you did more than just "return". Nonetheless,
> I think it's a matter of style that's not worth debating. Do as you will.

I'm not too bothered by this in the VFS code, that's up to the VFS
maintainers, but for future reference, in the LSM layer I really
dislike jumping to a label simply to return.

-- 
paul-moore.com