VFS Attacks and Chroot Breakouts

Eric W. Biederman wanted to clean up some problems with the Virtual Filesystem (VFS), but he wanted to make sure his changes wouldn't break anything.

First, he pointed out that because not all filesystem changes went through the VFS, filesystems had to lie to the VFS to make everything work out OK for those kinds of changes.

Second, and perhaps more importantly, VFS at that time had a bug (or misfeature) that allowed a hostile user to mount a filesystem on another user's dentry, such that the first user couldn't get rid of it. Bad scene.

Eric's solution, he said, would fix the problems, reduce the overall complexity of the VFS, and make the kernel source tree smaller. However, because it involved a change in the semantics of the VFS interfaces, he wanted to proceed with caution and make sure nothing would suddenly break.

Linus Torvalds said that the semantic change was actually very big. Specifically, the rmdir() system call had previously refused to remove an empty directory whereas, after Eric's change, rmdir() would do it without complaint. Linus pointed out that there was code in Git itself that relied on the existing behavior of rmdir(). He said he didn't know if this would translate into anyone in the world really and truly experiencing any inconvenience, but the semantic change seemed big to him.

Linus added, "I like the _concept_ of being able to remove a mount-point and the mount just goes away. But I do think that for sanity sake, it should have something like 'if one of the mounts is in the current namespace, return -EBUSY'. IOW, the patch-series would make the VFS layer _able_ to remove mount-points, but a normal rmdir() when something is mounted in that namespace would fail in order to give legacy behavior."

Eric said he had no problem making that change, though he felt it "would be more about making stupid mistakes like running rm -rf / fail than it would be about security or correctness."

Intuitively, Eric said he agreed with Linus that "it is less surprising if rmdir was forbidden in mount namespaces where it has a mount."

At this point, the conversation veered off into other "there are security holes we should fix" topics. Rob Landley said he wanted to fix the problem with chroot(), which would allow any user to easily break out of it using a simple set of commands from within a chrooted environment:

chdir("/");
mkdir("sub");
chroot("sub");
chdir("./../../../../../../../..");

But Linus said, "escaping chroot is usually fairly easy. Making an escape-proof chroot is really quite hard. Basically impossible if you allow root." And Al Viro said, "the whole thing is idiocy – chroot() is not and has never been root-proof and anybody expecting it to be has failed to read any number of FAQs out there."

Linus also said, "That doesn't make chroot() useless – it just means that the uses are elsewhere (it's useful for various non-security issues like development environments, but it can also be useful as one small _part_ of some bigger model, like a VM etc)."

Linus added, "pivot_root() does end up being a 'better chroot than chroot' if you're looking for containment. It may not be a pretty system call, but it does avoid at least the most obvious gotchas with chroot()."