[cc linux-fsdevel] On Mon, Mar 10, 2025 at 03:36:04PM +0100, Greg Kroah-Hartman wrote: > On Mon, Mar 10, 2025 at 01:00:50PM +0100, Mickaël Salaün wrote: > > Hi Greg, > > > > FYI, I don't think this patch fixes a security issue. If attackers can > > corrupt a filesystem, then they should already be able to harm the whole > > system. > > > > The commit description might be a bit confusing, but from an access > > control point of view, the filesystem on which we spotted this issue > > (bcachefs) does not allow to open weird files (but they are still > > visible, hence this patch) and I guess it would be the same for other > > filesystems, right? I'm not sure how a weird file could be used by user > > space. See > > https://lore.kernel.org/all/Zpc46HEacI%2Fwd7Rg@xxxxxxxxxxxxxxxxxxx/ > > > > The goal of this fix was mainly to not warn about a bcachefs issue (and > > avoid related syzkaller report for Landlock), and to harden Landlock in > > case other filesystems have this kind of bug. > > It was issue a CVE because the reviewers thought that it was a way to > circumvent the landlock permission checks, based on the changelog text > (note, creating a "corrupted filesystem" is quite easy to get many Linux > systems to auto-mount it, so those types of issues do get assigned > CVEs.) That's an argument straight from the security theatre. > If you all do not think this meets the definition of a vulnerability as > defined by CVE.org as: > An instance of one or more weaknesses in a Product that can be > exploited, causing a negative impact to confidentiality, integrity, or > availability; a set of conditions or behaviors that allows the > violation of an explicit or implicit security policy. Yes, so shall we follow this reasoning based on untrusted user auto-mounts of untrusted devices to it's logical conclusion? If an untrusted user is in control of the filesystem image, then they don't need to corrupt the filesystem image to subvert the system. They can just change the permissions on files, change ACLs, change security xattrs (selinux, landlock, smack, etc), replace the contents of file data (e.g. trojan executables), etc. The filesystem will not flag *any* of these shenanigans as they don't involve actually corrupting the filesystem structure. IOWs, the kernel filesystem code can function perfectly and bug free, yet the system can be silently compromised through the hole punched in the *implicitly trusted security information under user control* in the fs image. This is a "trusted device contains trusted security information" model deficiency, not a filesystem implementation issue. The CVE worthy issue here is that the security model is violated by the untrusted automounts, not by how the filesystem reacts to the security model violation that has already occurred. Further, the kernel (and therefore the filesystem implemenation) cannot prevent untrusted user device auto-mounts, so this must be considered a system level vulnerability that requires userspace policy and implementation changes to mitigate. We've tried for years to get userspace to adopt a more security-aware model for untrusted devices, but have made pretty much no progress. Filesystem developers have ended up with their userspace filesystem packages shipping udisks rules to turn off automounting of those filesystem types for application that use udisks for this stuff. That catches -some- of the automounting behaviour, but not all of it. And we can't do anything else without changes to the wider userspace/distro policies around user automounting of untrusted devices. IOWs, to prevent these "corrupted filesystem causes issues" from being considered security issues, we need userspace to stop violating the kernel trust model for persistent security information storage. Greg, you have the ability to issue a CVE that will require downstream distros to fix userspace-based vulnerabilities if they want various certifications. You have the power to force downstream distros to -change their security model policies- for the wider good. We could knock out this whole class of vulnerability in one CVE: issue a CVE considering the auto-mounting of untrusted filesystem images as a *critical system vulnerability*. This can only be solved by changing the distro policies and implementations that allow this dangerous behaviour to persist. We've suggested many relatively user friendly ways this can be handled in the past (e.g. device fingerprinting via libblkid (which it kinda already does) and prompting the user to allow/deny devices with an unknown fingerprint). The simplest policy fix is to simply disallow auto-mount of removable devices by default across the entire distro. If distros want to close that kernel CVE then they have to, at minimum, turn off device auto-mount by default across the entire distro. At worst, this makes the reason you give for filesystem corruption issues being considered CVE worthy go away completely. At best, we get full distro level integration of efficient, persistent untrusted device handling at the desktop interfaces. That would be a win for -everyone-, not just the distro people who have to handle kernel CVEs.... If we want filesystem corruption CVEs to be any other than security theatre, then use we should be using the kernel CVE powers for the reason they were obtained in the first place. i.e. to force downstream distros to address issues they would otherwise ignore to help make our linux systems more reliable and secure. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
