Surely you need to handle corrupt data anyway
Surely you need to handle corrupt data anyway
Posted Jun 19, 2023 1:27 UTC (Mon) by jschrod (subscriber, #1646)In reply to: Surely you need to handle corrupt data anyway by smurf
Parent article: Mounting images inside a user namespace
OK, Rust gives you memory-safe code. Well, since decades most of my programming is done in programming languages with managed memory. There the kind of problems that you cite "compared to doing the same thing in C" don't happen.
But: Do you really think that these systems are free of security bugs? I have CVEs for code, written by me in Lisp, that proves this wrong. In this thread the focus is on the obvious problems with memory management and access. But there is a huge domain of bugs *in the logic of our programs*. This logic errors are all memory safe and won't prevented by Rust, but they bite you dearly. If the logic of an interpretation of a binary structure on disk is wrong, you're out. No safe filesystem any more.
And that is, what this article and the discussion is about: are we're willing to allow random people mounting filesystems with kernel code in user space? The proposal of "md" about a `safe file-system' that someone else shall write is contra-productive, IMNSHO. "md" argues that it's possible by principle, but no one wants to do that. I have raised my voice in an opposing argument: it's not even possible to do by principle. Murphy bites, and he does it all the time.
Lennart and others made, in this article discussion, a compelling argument for using FUSE. I don't even understand why an automount of a USB stick happens with udisk if it's not in VFAT format. (Those eccentric people who want to mount ext4 USB sticks -- and I belong to them! -- are not worth to make that the default behaviour.) IMHO, these are the directions one has to follow to constrain that attack vector. Gambling on a "safe filesystem" is not an option, neither technically nor socially.
FWIW, my background: I have never been involved in filesystem development. But for the last 40(!) years, I wrote printer and graphics drivers. From that background of hardware-near software development, I know that Rust will be a *VERY BIG* help in better security, but it will not be a panacea that guarentees us to be safe of any security problem.
Posted Jun 19, 2023 11:32 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
One thing that's not inherent to C versus Rust, but is a cultural difference that tends to go in Rust's favour, is Rust developers' preference for parsing over validating, and for abstractions over raw integers that prevent you making the security errors to begin with. This isn't a guarantee (unlike memory safety in safe Rust), but it does tend to result in fewer security issues.
This, in turn, leads to bounds on the danger level of accessing a filesystem; if the worst case possible by supplying a corrupt filesystem to a driver is that it'll read parts of the block device it wouldn't have read without the corruption, then you have a very different issue to one where a corrupt filesystem will cause the driver to read from an entirely different partition.
Posted Jun 19, 2023 12:26 UTC (Mon)
by pizza (subscriber, #46)
[Link]
For Fedora/GNOME, EXT4 and XFS filesystems are only sometimes automounted. SD cards seem to be, but "real" external drives required me to explicitly mount the drive, either manually or by clicking on it in GNOME's file browser. Though now that I think about it, it's possible there are LVM interactions involved here too. (yay, another layer of things to go very wrong..)
(I don't recall if NTFS volumes behave the same way -- I have a 1TB SSD set up that way, but it's not stashed somewhere convenient)
Surely you need to handle corrupt data anyway
Surely you need to handle corrupt data anyway