On Wed, May 01, 2024 at 03:50:07PM -0700, Darrick J. Wong wrote: > On Tue, Apr 30, 2024 at 11:48:29PM -0700, Christoph Hellwig wrote: > > On Mon, Apr 29, 2024 at 08:30:37PM -0700, Darrick J. Wong wrote: > > > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > > > > > Create an experimental ioctl so that we can turn off fsverity. > > > > Didn't Eric argue against this? And if we're adding this, I think > > it should be a generic feature and not just xfs specific. > > The tagging is a bit wrong, but it is a generic fsverity ioctl, though > ext4/f2fs/btrfs don't have implementations. > > <shrug> According to Ted, programs that care about fsverity are supposed > to check that VERITY is set in the stat data, but I imagine those > programs aren't expecting it to turn off suddenly. Maybe I should make > this CAP_SYS_ADMIN? Or withdraw it? > I'm concerned that fsverity could be disabled after someone has already checked for fsverity on a particular file. Currently users only have to re-check for fsverity if they close the file and re-open it (as in that case it might have been replaced with a new file with fsverity disabled). A similar issue also would exist for the in-kernel users of fsverity such as overlayfs and IMA (upstream), and IPE (https://lore.kernel.org/linux-security-module/1712969764-31039-1-git-send-email-wufan@xxxxxxxxxxxxxxxxxxx/). For example, IPE is being proposed to cache some state about fsverity in the LSM blob associated with the struct inode. If fsverity is disabled on an inode, that state would get out of sync. This could allow bypassing the IPE policy. CAP_SYS_ADMIN isn't supposed to give a license to bypass all security features including LSMs, so using CAP_SYS_ADMIN doesn't seem like a great solution. - Eric
