On Tue, Mar 11, 2025 at 10:42:41AM +1100, Dave Chinner wrote: > [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. If user mounts are enabled, that comes with UID mapping, and device nodes disabled - no? Out of curiosity, what's keeping us from saying "user mounts are generally expected to be safe" for XFS? Obviously, that does expose a massive attack surface, so saying that for a C codebase that wasn't initially designed for it has a high pucker factor. But I've been impressed with syzbot's ability to find bugs, so barring architectural issues which I assume you'd know about it seems it's not nearly as crazy a thought as it used to be - for XFS, as you guys have been the most rigorous about hardening so I expect that's about as good as it's going to get until we start rewriting our filesystems in Rust.
