Re: HFS/HFS+ are insecure
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.
Reply to: