Filesystem mounts in user namespaces

Posted Aug 7, 2015 1:45 UTC (Fri) by koverstreet (✭ supporter ✭, #4296)
In reply to: Filesystem mounts in user namespaces by neilbrown
Parent article: Filesystem mounts in user namespaces

Oh yeah, the lack of auditing is definitely scary - that's not quite what I was getting at, though. Because there's never been any real pressure to be concerned about this attack vector before, I'm worried that there might be security issues that are just baked into the semantics of posix filesystems - or at least, the VFS interface.

Like it's straightforward enough to e.g. in bcachefs audit all the code that reads in a btree node for buffer overflows and whatnot; there, the issues one is looking for are all local. An adversarial device modifying fs metadata underneath us to do god knows what at the filesystem level? Ugh...

It would be nice if it motivates people to start caring about FUSE performance, too.

to post comments

Filesystem mounts in user namespaces

Posted Aug 7, 2015 2:18 UTC (Fri) by neilbrown (subscriber, #359) [Link]

> I'm worried that there might be security issues that are just baked into the semantics of posix filesystems - or at least, the VFS interface

There are things like SETUID and device-special files of course, but they are already understood and handled.

The only other thing I can think of is that you could create a (nearly) arbitrarily deep directory tree and consume all of memory in the dcache - because all ancestors of anything in the dcache must also be in the dcache.

If mem-cgroups is able to fail allocations for new inodes or dentries, then this isn't a problem. If it can't, then this could be a denial-of-service vector.

Mind you, you can already do:
% while :;do mkdir a;cd a;done

so it isn't really anything new.