Zack's Kernel News
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
Buy this article as PDF
Innovative system adds a hard drive and Ubuntu Core to the RPi for an IoT hub.
Linux is two weeks younger than we thought!
The Apache Software Foundation considers retiring OpenOffice
Adobe won’t kill the plugin in 2017
Linux Foundation's big event celebrates the 25th anniversary of Linux
Competitors get in the game with RHEL without Red Hat
Security researchers have already notified Microsoft; some fixes are available
The company is collaborating with Google and Intel to use Kubernetes as an engine for Fuel