On Tue, Mar 11, 2025 at 03:24:40PM +1100, Dave Chinner wrote: > On Mon, Mar 10, 2025 at 10:09:22PM -0400, Kent Overstreet wrote: > > On Tue, Mar 11, 2025 at 10:42:41AM +1100, Dave Chinner wrote: > > If user mounts are enabled, that comes with UID mapping, and device > > nodes disabled - no? > > Not necessarily. Those security mechanisms are all optional mount > options under userspace control.... Well, if someone's being an idiot, that's on them and not something I'm going to argue about :) Uidmapping has been around for plenty long enough for userspace to start using it. > > > Out of curiosity, what's keeping us from saying "user mounts are > > generally expected to be safe" for XFS? > > What does "generally expected to be safe" actually mean? > > If be "safe" you mean "won't crash the kernel if the structure has > been altered in detectable ways with", then we already largely tick > that box. However, there are whole classes of DOS attacks that are > very difficult to detect without rigorous, expensive runtime > checking (e.g. loops in btree pointers). btree nodes don't change depth, so just recording the level of a node and validating it trivially defeats that. bcachefs has that in its on disk format, but if you don't have that then that might be a problem - you'd at least need to know a priori the depth of the root node. > Hence while we catch almost all the the obvious out-of-bounds > corruptions within an object, detecting corruptions that require > spanning a largely unbound number of objects to detect are not > handled at all. I can corrupt a filesystem to induce an endless > btree search loop like this pretty easily with a little bit of > xfs_db magic. Yup, we even provide the tools to make doing stuff > like this easy... *nod* In bcachefs, we right now have no way to cleanly detect "filesystem is actually full, disk accounting info is wrong" so - that means corruption causes allocations to get stuck. That one is fixable, and I'm going to have to at some point since syzbot knows how to trigger it :) > If by "safe" you mean "can detect all cases where a metadata field > or file data has been tampered with", then XFS is completely unsafe > and should not be used. > > We can't detect that a malicious actor has changed something like a > file permission field or the contents of a security xattr. To do > that requires cryptographically secure signatures of metadata > objects and file data. We do not have that sort of feature in the > on-disk format. We expect users that need protection from such > tampering will use an envrypted block device to prevent malicious > actors from being able to mutate the filesystem structure in this > way. Yeah, but that's the less interesting case to me. Not uninteresting, since "I don't fully trust my block device" is a real scenario with network attached storage. But generally, the tampering would be done by the user that did the mount - so perhaps we need to find some new nudges to make uidmapping of user mounts required? That could be done in util-linux...
