linux-kernel - Re: [PATCH] overlayfs: Trigger file re-evaluation by IMA / EVM after writes

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: <20230411-abartig-relikt-9785cfe2b604@brauner>
Date:   Tue, 11 Apr 2023 16:08:45 +0200
From:   Christian Brauner <brauner@...nel.org>
To:     Jeff Layton <jlayton@...nel.org>
Cc:     Amir Goldstein <amir73il@...il.com>,
        Stefan Berger <stefanb@...ux.ibm.com>,
        Paul Moore <paul@...l-moore.com>, zohar@...ux.ibm.com,
        linux-integrity@...r.kernel.org, miklos@...redi.hu,
        linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-unionfs@...r.kernel.org
Subject: Re: [PATCH] overlayfs: Trigger file re-evaluation by IMA / EVM after
 writes

On Tue, Apr 11, 2023 at 06:13:15AM -0400, Jeff Layton wrote:
> On Tue, 2023-04-11 at 11:49 +0200, Christian Brauner wrote:
> > 
> > > 
> > > > Afaict, filesystems that persist i_version to disk automatically raise
> > > > SB_I_VERSION. I would guess that it be considered a bug if a filesystem
> > > > would persist i_version to disk and not raise SB_I_VERSION. If so IMA
> > > > should probably be made to check for IS_I_VERSION() and it will probably
> > > > get that by switching to vfs_getattr_nosec().
> > > 
> > > Not quite. SB_I_VERSION tells the vfs that the filesystem wants the
> > > kernel to manage the increment of the i_version for it. The filesystem
> > > is still responsible for persisting that value to disk (if appropriate).
> > 
> > Yes, sure it's the filesystems responsibility to persist it to disk or
> > not. What I tried to ask was that when a filesystem does persist
> > i_version to disk then would it be legal to mount it without
> > SB_I_VERSION (because ext2/ext3 did use to have that mount option)? If
> > it would then the filesystem would probably need to take care to leave
> > the i_version field in struct inode uninitialized to avoid confusion or
> > would that just work? (Mere curiosity, don't feel obligated to go into
> > detail here. I don't want to hog your time.)
> > 
> 
> In modern kernels, not setting SB_I_VERSION would mainly have the effect
> of stopping increments of i_version field on write. It would also mean
> that the STATX_CHANGE_COOKIE is not automatically reported via getattr.

Ah, good.

> 
> You probably wouldn't want to mount the fs without SB_I_VERSION set. The
> missing increments could trick an observer into believing that nothing
> had changed in the file across mounts when it actually had.

Yeah, that's what I thought and that would potentially be an attack on
IMA which is why I asked.

Thanks!
Christian