Defending mounted filesystems from the root user

Posted Aug 22, 2023 11:57 UTC (Tue) by pizza (subscriber, #46)
In reply to: Defending mounted filesystems from the root user by leromarinvit
Parent article: Defending mounted filesystems from the root user

>Nothing else knows what is conforming and what isn't.

And it's often only possible to tell if a given on-disk metedata structure is "conformant" after loading *every other* bit of metadata into memory and effectively doing a full consistency/fsck pass. Of course you're still vulnerable to stuff being written to disk behind your back, so the only way to handle that is to always keep the full metadata in memory, and never re-read anything from disk.

Defending mounted filesystems from the root user

Posted Aug 22, 2023 13:39 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (8 responses)

But then you have to write all of it back because it might have changed on disk behind your back. Anything less and you're just deferring discovering the bogus writes until the next mount time.

Defending mounted filesystems from the root user

Posted Aug 22, 2023 14:10 UTC (Tue) by leromarinvit (subscriber, #56850) [Link] (3 responses)

Trying to detect writes to a device (or the page cache) behind the file system's back is probably a futile endeavor. But making sure to never crash, no matter what any given read returns (and no matter if that's consistent with what was read elsewhere), seems like a goal that should be attainable in principle (even if, as many have said, it's a lot of work).

Defending mounted filesystems from the root user

Posted Aug 22, 2023 16:08 UTC (Tue) by DemiMarie (subscriber, #164188) [Link]

Exactly! And big companies (Google, Oracle, Red Hat, etc) need to hire more people to meet that goal.

Defending mounted filesystems from the root user

Posted Aug 22, 2023 17:19 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (1 responses)

That sounds like a futile endeavor to me. Sure, make things *better*, but *crash-proof* when you're in the realm of forced TOCTOU races (that iSCSI situation given above), deliberately bad actors messing with inode pointers/refcounts that may cause page cache confusions, or whatever else could possibly go wrong when you're in an absolutely uncontrollable and hostile environment…

I don't know…the trust line has to go somewhere here. For example, Rust is not safe against `/proc/self/mem` editing. I'm not sure what one *could* do in the face of such power because the only thing you have is "my registers are not accessible" and "the program counter will keep moving".

Note that I am usually all about defensive programming and covering bases, but I also don't interface with hardware directly and have some baseline level of viable behavior. The tales I've heard here (and from linked blogs, etc.) make me happy about my course so far. I am extremely grateful for those that do that work, but I do not envy their jobs.

Defending mounted filesystems from the root user

Posted Aug 23, 2023 17:13 UTC (Wed) by leromarinvit (subscriber, #56850) [Link]

Sure, perfection is impossible for anything sufficiently complex. What I really meant was fixing the issues one knows about, and having the attack vector in mind when designing and writing new code. Not saying the current maintainers have to tackle all that in addition to everything they're already doing - it's clear that adding more work either leads to everything moving at a slower pace, or someone needs to step in and fund more developers. (Someone volunteering is of course also possible, but I have a hard time imagining that "I can use root privileges to make the kernel do funny things" is many people's most important itch to scratch.)

I also should probably have qualified the "never crash" with "in a way that potentially allows privilege escalation". If removable media were by default mounted using something like lklfuse, that would IMHO be a big step in the right direction. But I think this should be mainlined, or decoupled from the actual driver code so much that it can use arbitrary kernel images or modules. Using different versions of the same fs driver (with a different set of features and bugs), potentially interchangeably on the same device, sounds like a recipe for compatibility issues.

Defending mounted filesystems from the root user

Posted Aug 24, 2023 7:12 UTC (Thu) by Karellen (subscriber, #67644) [Link] (3 responses)

Anything less and you're just deferring discovering the bogus writes until the next mount time.

Why is that a problem?

Defending mounted filesystems from the root user

Posted Aug 24, 2023 12:33 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (2 responses)

Let's say you bring in all of the metadata from the FS into memory and work from there. If you don't edit any of them, there's no need to write. However, in a situation where the backing store is editable by some other mechanism (network-mounted block device, direct writes, whatever, these can be written without noticing (say, swapping two inodes in a directory listing). Without writeback, you're just deferring "something edited my FS" problems from "direct memory access" to "when I load from disk next time".

Defending mounted filesystems from the root user

Posted Aug 24, 2023 14:16 UTC (Thu) by Karellen (subscriber, #67644) [Link] (1 responses)

you're just deferring "something edited my FS" problems from "direct memory access" to "when I load from disk next time".

I get that. I just don't see why it's a problem. Surely checking for consistency and deciding what to do if there's a problem is easier at mount time than it is while the filesystem is in use?

Defending mounted filesystems from the root user

Posted Aug 30, 2023 9:45 UTC (Wed) by taladar (subscriber, #68407) [Link]

At that point you are potentially working on a fictional version of your filesystem that doesn't exist on disk for months at a time. Considering persistent storage is the main purpose of a hard disk that doesn't seem like a good idea.