Prevent mounting on ".."

Hi Al and Marcelo,

while I was trying to get maximum restrictions on a chroot on 2.4.21-pre, I found that it's always possible to mount a ramfs or a tmpfs on "..", and then upload whatever I wanted in it. It's a shame because I was trying to isolate network daemons inside empty, read-only file-systems, and I discovered that this effort was worthless. To resume, imagine a network daemon which does :

chroot("/var/empty") (read-only directory or file-system) chdir("/")
listen(), accept(), fork(), whatever...
-> external code injection from a cracker :
mount("none", "..", "ramfs") mkdir("../mydir")
chdir("../mydir")
the cracker now installs whatever he wants here.

The worst is that the new directory can even become invisible from all other processes, so that the intruder has nothing to fear :-(

So I read fs/namei.c and fs/namespace.c, and found a way to prevent this. Basically, the only case where it's still possible to mount something on the current->fs->root now, is when the process wants to remount the root fs, but no other mounts are allowed.

Since I'm really clueless about VFS code, I might have done it wrong, or broken something, so I post this patch for comments. If everyone agrees, I would really appreciate it if it was accepted in mainstream, because it's a security problem IMHO.

It still applies to 2.5.66 with offset BTW.

Cheers,
Willy

@@ -732,6 +732,10 @@
 	if (flags & MS_REMOUNT)
 		retval = do_remount(&nd, flags & ~MS_REMOUNT, mnt_flags,
 				    data_page);
+	else if (nd.dentry == current->fs->root &&
+		 nd.mnt == current->fs->rootmnt)
+		/* prevents someone from mounting on . or .. */
+		retval = -EINVAL;
 	else if (flags & MS_BIND)
 		retval = do_loopback(&nd, dev_name, flags & MS_REC);
 	else if (flags & MS_MOVE)

well...
you need to be root to mount. If you're root you can break out of a chroot anyway....

not in all cases. for the classical "mkdir a; chroot a; chdir ..", you need a writable directory to create "a" or an existing directory somewhere to serve as a mount point. If neither of them is true, I don't see other means of escaping the chroot. And here, ".." is the only one I could exploit, that's why I proposed this patch which closes what is, to me, the only weakness in this very particular case.

Cheers,
Willy

That's a BS. Same effect would be achieved by replacing ".." with ".". Or mounting on any existing subdirectory.

If attacker can mount of chroot - you've LOST. Already. End of story.

No, it works only with "..", and not with "." ! I don't know why, I believe it's because the process is still attached to the old FS when mounting on ".".

To me, it seems this is the *only* remaining case in an *empty* read-only directory. The fact is that the attacker needs at least a mount point to mount something. Not providing him one is efficient, but here he can only exploit "..".

Please reconsider the question, Al, because I really think that with this, we can get reliable jails for network daemons which don't need file access at all.

Cheers,
Willy

So? chdir around and you'll get to the covering directory.

Sigh... We _can't_ do that via chroot(). Please, stop fooling yourself - if attacker gets control over root process, the fight is over. In particular, attacker can chmod your read-only directory and/or remount the thing.

not if the file-system is read-only by design (eg: romfs or anything like that) or a read-only directory in /proc. To be honnest, I have another patch which allows any process to chroot to /proc/self/empty. I know that it's not good when the root is compromized. The attacker could do other things and even halt the system. That's not what I'm trying to fight against. I'm only trying to stop proliferation, and isolate the attacker into a place where the only tools he can use are the ones he codes himself on the heap or stack, which is rather limitating.

Cheers,
Willy