Hi!

quoted

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.

quoted

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