The trouble with root access is that there's always a way for active malice to get in. For instance, our approach is trivially vulnerable to loading a kernel module. It's possible that something like user namespaces would solve that today.
This call does not change the current working directory, so that after the call '.' can be outside the tree rooted at '/'. In particular, the superuser can escape from a "chroot jail" by doing:
mkdir foo; chroot foo; cd ..
However, there are some kernel patches floating around that disable double-chroot, so just as such an attack would be easy, blocking that specific attack would be easy too. My point was that there are lots of things that root can do, and blocking them all is difficult; in general root is trusted to load drivers, which means it can bypass any driver that confines it. There's no direct equivalent of chroot on 16-bit DOS/Windows, but you could almost certainly bypass OP's filtering scheme by loading your own VxD that fought with theirs.
chdir("/"); /* go to / of "chroot jail" */
mkdir("foo", ...); /* create directory in jail */
chroot("foo"); /* change / to foo */
/* fail to chdir("foo"); */
chdir(".."); /* instead go up parent (there is nothing preventing you since you are no longer in the "chroot jail" since the jail is now foo and you never entered it) */
chdir("..");
/* ... */
chdir(".."); /* . is now the real root */
chroot("."); /* change / to the real root */
Note that this includes Linux itself with CLONE_NEWNS + pivot_root (which is what Docker does).
Parent's attack requires the attacker to have root inside the chroot. It's a "double-chroot" attack: you call chroot a second time as root, so a new directory starts getting remapped. Then the old one no longer does, and you can "cd .." out of it and eventually "chroot ." when you get to the top. The only mitigation is not to give an attacker root inside a chroot.
Your attack does not require the attacker to have root. Instead, the process who was setting up the chroot (which does have root) forgets to cd into the chroot, and leaves the working directory outside it. The attacker cannot chroot again, but they can continue to cd anywhere on your filesystem.
It does exactly what you want, although it was created for different use cases (Live CDs, layered images as used by Docker, etc.):
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
In 1991, my company was sandboxing commercial software. This was for try-before-you-buy. Except, instead of recompiling a crippled version, we would take a retail SKU, encipher the executables and then deliver with a device driver: a VxD. The VxD would hook the low level Int13 IO calls to pass all disk IO through a write-through cache. The installed app could read from anywhere on the disk. But, all attempts to write would copy the changed sectors to the cache. This would allow a perfect uninstall; simply remove the cache and the disk reverts back to its preinstalled state. This was because most software, back in 1991, assumed that you'd never want to uninstall. So, it would scatter its junk all over the place.
Now imagine if the VxD was part of the OS. Any downloaded exe could access the HD, but all writes would write-through to a separate cache. That was 25 years ago. This is a roundabout way of asking: how feasible is sandboxing to avoid malware?