When it comes to chroot one needs to remember to not hold any handle/file descriptor to something on filesystem outside of chroot. If you: 1. grab file descriptor outside of chroot 2. then chroot (descriptor will not close) 3. you can escape chroot using that file descriptor At the same time it can be useful for somebody in need of exactly one IPC connection (through Unix domain sockets or TCP), but want to drop rights to open second IPC connection. It also works in similar manner in *BSD families of OSes. OpenBSD does not have namespaces, but has pledge(2) system call to easily restrict process rights.
Thanks @Stefan Froberg - to make sure I understand what this is doing, it's a guide for software application authors to do what even major applications fail to do - set themselves up a sandbox using kernel facilities with minimal permissions according to their task. IOW, bolting in the protections that Firejail is retrospectively attempting to do for the "bad" applications. FWIW, Windows developers have had a very technical ornery time achieving sandboxing, until W10, and only W10 development. Anyway, thanks again, very useful if I need to do some linux development.
But how could any exploit code grap a file descriptor outside chroot if it is already inside it? I mean, it runs as a non-root, with all root capabilities dropped. It can't exec chroot(), setuid() or any other privileged function and doing chdir(..) does not get it to anywhere. So the only way I could think that bad code could worm itself out would be that the descriptor is already open before chrooting (either accidentally or intentionally) and then it would have to be a file descriptor to directory so that the bad guy could use fchdir(). Example: Put int fd = open(".",O_RDONLY) just before chdir() and chroot() call, then after chroot() do fchdir(fd) followed with print_current_files() But right now, I can't think any reason why software would wan't to open directory file descriptor outside jail directory before chrooting. If we have a hypothetical network software X that is going to be chrooted, let's say, into /var/chroot/X it could have all it's configuration and log files inside that dir. Only file that would need to live outside of the X software would be a unix socket so that it could communicate with the rest of the system, created and opened just before chrooting. EDIT: Now that I think of it, there might be a way to prevent escaping even in the crazy situation that application would for some reason need open directory file descriptor .... have to start writing part 2 soon ...
That is right. I wanted to write these things down before I forget them and at the same time help fellow developers and show that sandboxing is not hard. Your welcome