Hi! > > People want to use USB sticks from time to time. And while I > > understand XFS is so complex it is unsuitable for such use, I'd still > > expect bugs to be fixed there. > > > > I hope VFAT to be safe to mount, because that is very common on USB. > > > > I also hope ext2/3/4 is safe in that regard. > > Ext4 will fix file system fuzzing attack bugs on a best efforts basis. > That is, when I have time, I've been known to stay up late to bugs > reported by fuzzers. I hope ext4 is safe, but I'm not going to make > any guarantees that it is Bug-Free(tm). If you want to trust it in > that way, you do so at your risk.
Good. > > Anyway it would be nice to have documentation explaining this. If I'm > > wrong about VFAT being safe, it would be good to know, and I guess > > many will be surprised that XFS is using different rules. > > Using USB sticks is fine, so long as you trust the provenance of the > drive. If you take a random USB stick that is handed to you by Well... That makes passing data between Windows and Linux machines using USB stick "interesting", right? > someone whom you don't trust implicitly, or worse, that you picked up > abandoned on the sidewalk, there have been plenty of articles which > describe why this is a REALLY BAD IDEA, and even if you ignore > OS-level vuleranbilities, there are also firwmare and hardware based > vulerabilities that would put your computer at risk. See [2] and > [3] I know, but bear with me. > As far as documentation is concerned, how far should we go? Should > there be a warning in the execve(2) system call man page that you > shouldn't download random binaries from the network and execute them? :-) No need to pull straw men for me. This thread suggested that kernel is _not_ supposed to be robust against corrupt filesystems (because fsck is not integrated in kernel). Which was news to me (and I'm not the person that needs warning in execve documentation). I'd certainly like to hear that VFAT and EXT4 _is_ supposed to be robust in that way. And if we have filesystems where corrupt image is known to allow arbitrary code execution, we need to a) document that. b) disable them when secure boot is enabled. Because with secure boot, we are supposed to be secure against attacks from root, and root can prepare malicious filesystems. ("The problem, simply put, is this: the objective of secure boot is to prevent the system from running any unsigned code in a privileged mode. So, if one boots a Linux system that, in turn, gives access to the machine to untrusted code, the entire purpose has been defeated. The consequences could hurt both locally (bad code could take control of the machine) and globally (the signing key used to boot Linux could be revoked), so it is an outcome that is worth avoiding. Doing so, however, requires placing limitations in the kernel so that not even root can circumvent the secure boot chain of trust." -- https://lwn.net/Articles/514985/ ). Best regards, Pavel -- http://www.livejournal.com/~pavelmachek
signature.asc
Description: PGP signature