On Sat, Jul 22, 2023 at 03:41:58PM +0800, Paul Wise wrote: > That still potentially exposes insecure code to untrusted data, just in > a user context rather than a kernel context. The same goes for uml + > fuse + namespaces, and even guestfs VMs. You can move the data and code > to different contexts, but that doesn't change the fundamental issue.
That's still a huge win! You can seccomp it, you can assign LSM restrictions, you can significantly reduce the risk associated with mounting an untrusted filesystem. We have many more controls in a user context than we do in a kernel context. > Disabling auto-mounting and for manual GUI mounts, requesting users > confirm they trust the filesystem they are mounting would avoid that as > much as is reasonably possible without entirely deleting the code and > without breaking the use-cases of people who need the filesystem code. When is a user going to plug in a USB stick and *not* click that button? I'm not analysing a filesystem by hand to check whether it's trustworthy before I want it mounted. There's no reason to automount when the screen is locked and presenting a dialog in the case where one was plugged in and then the screen unlocked is reasonable, but that just makes no sense as generic behaviour.
