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: <51bc6e173bcea1f017355be5ef44a1d12c70fa7f.camel@linux.ibm.com>
Date:   Tue, 23 May 2023 13:35:06 -0400
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Dave Chinner <david@...morbit.com>,
        Christian Brauner <brauner@...nel.org>
Cc:     Amir Goldstein <amir73il@...il.com>,
        Jeff Layton <jlayton@...nel.org>,
        Stefan Berger <stefanb@...ux.ibm.com>,
        Paul Moore <paul@...l-moore.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,
        Ignaz Forster <iforster@...e.de>, Petr Vorel <pvorel@...e.cz>
Subject: Re: [PATCH] overlayfs: Trigger file re-evaluation by IMA / EVM
 after writes

On Mon, 2023-05-22 at 08:49 +1000, Dave Chinner wrote:


> > In addition the uuid should be set when the filesystem is mounted.
> > Unless the filesystem implements a dedicated ioctl() - like ext4 - to
> > change the uuid.
> 
> IMO, that ext4 functionality is a landmine waiting to be stepped on.
> 
> We should not be changing the sb->s_uuid of filesysetms dynamically.
> The VFS does not guarantee in any way that it is safe to change the
> sb->s_uuid (i.e. no locking, no change notifications, no udev
> events, etc). Various subsystems - both in the kernel and in
> userspace - use the sb->s_uuid as a canonical and/or persistent
> filesystem/device identifier and are unprepared to have it change
> while the filesystem is mounted and active.
> 
> I commented on this from an XFS perspective here when it was
> proposed to copy this ext4 mis-feature in XFS:
> 
> https://lore.kernel.org/linux-xfs/20230314062847.GQ360264@dread.disaster.area/
> 
> Further to this, I also suspect that changing uuids online will
> cause issues with userspace caching of fs uuids (e.g. libblkid and
> anything that uses it) and information that uses uuids to identify
> the filesystem that are set up at mount time (/dev/disk/by-uuid/
> links, etc) by kernel events sent to userspace helpers...
> 
> IMO, we shouldn't even be considering dynamic sb->s_uuid changes
> without first working through the full system impacts of having
> persistent userspace-visible filesystem identifiers change
> dynamically...

Oh!   FYI, we've started using the ability to change the UUID for IMA
testing.  IMA policy rules can be defined in terms of the UUID without
impacting the existing policy rules.  Changing the UUID can be used to
enable different tests without interferring with existing policy rules.

Mimi