On Mon, Mar 10, 2025 at 10:19:57PM -0400, Demi Marie Obenour wrote: > People have stuff to get done. If you disallow unprivileged filesystem > mounts, they will just use sudo (or equivalent) instead. I am not advocating that we disallow mounting of untrusted devices. > The problem is > not that users are mounting untrusted filesystems. The problem is that > mounting untrusted filesystems is unsafe. > Making untrusted filesystems safe to mount is the only solution that > lets users do what they actually need to do. That means either actually > fixing the filesystem code, Yes, and the point I keep making is that we cannot provide that guarantee from the kernel for existing filesystems. We cannot detect all possible malicous tampering situations without cryptogrpahically secure verification, and we can't generate full trust from nothing. The typical desktop policy of "probe and automount any device that is plugged in" prevents the user from examining the device to determine if it contains what it is supposed to contain. The user is not given any opportunity to device if trust is warranted before the kernel filesystem parser running in ring 0 is exposed to the malicious image. That's the fundamental policy problem we need to address: the user and/or admin is not in control of their own security because application developers and/or distro maintainers have decided they should not have a choice. In this situation, the choice of what to do *must* fall to the user, but the argument for "filesystem corruption is a CVE-worthy bug" is that the choice has been taken away from the user. That's what I'm saying needs to change - the choice needs to be returned to the user... > or running it in a sufficiently tight > sandbox that vulnerabilities in it are of too low importance to matter. > libguestfs+FUSE is the most obvious way to do this, but the performance > might not be enough for distros to turn it on. Yes, I have advocated for that to be used for desktop mounts in the past. Similarly, I have also advocated for liblinux + FUSE to be used so that the kernel filesystem code is used but run from a userspace context where the kernel cannot be compromised. I have also advocated for user removable devices to be encrypted by default. The act of the user unlocking the device automatically marks it as trusted because undetectable malicious tampering is highly unlikely. I have also advocated for a device registry that records removable device signatures and whether the user trusted them or not so that they only need to be prompted once for any given removable device they use. There are *many* potential user-friendly solutions to the problem, but they -all- lie in the domain of userspace applications and/or policies. This is *not* a problem more or better code in the kernel can solve. Kees and Co keep telling us we should be making changes that make it harder (or compeltely prevent) entire classes of vulnerabilities from being exploited. Yet every time we suggest that a more secure policy should be applied to automounting filesystems to prevent system compromise on device hotplug, nobody seems to be willing to put security first. > For ext4 and F2FS, if there is a vulnerability that can be exploited by > a malicious filesystem image, it is a verified boot bypass for Chrome OS > and Android, respectively. Verified boot is a security boundary for > both of them, How does one maliciously corrupt the root filesystem on an Android phone? How many security boundaries have to be violated before an attacker can directly modify the physical storage underlying the read-only system partition? Again, if the attacker has device modification capability, why would they bother trying to perform a complex filesystem corruption attack during boot when they can simply modify what runs on startup? And is this a real attack vector that Android must defend against, why isn't that device and filesystem image cryptographically signed and verified at boot time to prevent such attacks? That will prevent the entire class of malicious tampering exploits completely without having to care about undiscovered filesystem bugs - that's a much more robust solution from a verified boot and system security perspective... > so just forward syzbot reports to their respective > security teams and let them do the jobs they are paid to do. Security teams don't fix "syzbot bugs"; they are typically the people that run syzbot instances. It's the developers who then have to triage and fix the issues that are found, so that's who the bug reports should go to (and do). And just because syzbot finds an issue, that doesn't make it a security issue - all it is is another bug found by another automated test suite that needs fixing. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
