i.e. writing the entire thing with zero memory corruption bugs for an attacker to exploit either via an attacker controlled filesystem or an application. Drivers similarly have to be written treating the hardware and code using them as adversarial. Choice of tools is important.
Conversation
FS drivers do not belong in privileged contexts. The FS driver for an untrusted FS should be executing in a context where it can do nothing worse than store or retrieve wrong data.
1
2
This Tweet was deleted by the Tweet author. Learn more
No, that's not what he means. He's saying that an external file system should have a sandboxed filesystem driver, so that exploiting a bug inside it doesn't immediately grant complete control over the entire system and at least requires privesc to escape (likely via the kernel).
1
4
This Tweet was deleted by the Tweet author. Learn more
Feel free to look through the hundreds of ext4 CVEs and consider reading what I pointed you towards:
events.linuxfoundation.org/wp-content/upl
kroah.com/log/blog/2018/
2
FWIW, I've never considered ext4 as a candidate for removable media. If your threat model includes physical alteration of internal drives you have bigger problems than ext4 CVEs. If your udev scripts auto-mount external ext4, your distro integrators are incompetent.
1
1
This Tweet was deleted by the Tweet author. Learn more
The Linux kernel clearly wasn't designed to be secure either. C was not designed to be usable for writing robust and secure software. The architecture and design choices / compromises are fundamentally ill suited to how they're used. It doesn't mean people don't use them for it.
1
It's not like the Linux vfat driver doesn't suffer from these issues too. It's far simpler, which is good, but also inadequate for modern usage. It doesn't have a filesystem that isn't going to have lots of low-hanging fruit via memory corruption bugs when data is untrusted.
1
Of course, ideally, you don't want filesystems to be in the kernel, especially ones for external drives. There should really be a separate instance of a filesystem process for each drive, and ideally it would be memory safe code. They handle complex untrusted data structures.