Chroot notes
| 📃 These are primarily notes, intended to be a collection of useful fragments, that will probably never be complete in any sense. |
See also SSH_-_SSH_jails
tl;dr:
- chroot changes the filesystem's apparent root
- chroot is mainly a development tool
- chroot is not a security tool against those with ill will
- ...though better than nothing against side effects of bugs
What
chroot
- changes a process's apparent filesystem-root directory to a given path
- after which path resolution only resolves within that subtree.
- does not affect already-open file descriptors (files, pipes, sockets, etc.)
- does not affect hardlinks to outside
- basically doesn't affect non-path system calls
As such, chroot is mostly useful for things that themselves want to run in an isolated environment.
And doesn't do much against people trying to break out of such an environment. (It might work against the unwashed masses, but not against hackers. In various chroot implementations (yes, details vary), if a user in the jailed environment has the ability to chroot, they can break out of it)
That said, there are some variations/extensions of the chroot idea that are security-oriented.
Example uses:
- The best example of its use is testing/debugging, for example testing some newly compiled libraries without installing them system-wide.
- Different OS environment, e.g. from the one you have booted from
- You could boot from a liveCD to then chroot to your installed OS (for example to fix it, in particular if what is wrong is its ability to boot).
- One way of installing gentoo is taking over a disk this way [1]
- Jailed daemon
- For example, you could chroot a web server or file server (with the content they serve) so that if someone finds an exploit that gives them read access to the filesystem (and not security elevation), this still only means 'any file inside that jail'.
- This is mostly so that the filesystem accesses that are implied by web accesses or the scripts will not go outside the jail. When exploits allow remote code execution, a jail may only be an additional hurdle.
- Jailed login
- Usually to the user's home directory (because that's easier to organize)
- An actually restrictive chroot jail is surprisingly hard to set up. Implementations vary, so all chroot is really guaranteed to do is change the way typical path resolution works.
- For hackers this may be a temporary hurdle to further access (though further access may amount to nothing more than "the full filesystem as the user would see without chroot, and nothing more", which is no less secure than not using chroot -- but also no better).
Details
jail account / working environment
After you chroot, you need an environment that works.
To run anything nontrivial, and in particular daemons, you'll probably need
/usr, /bin, /etc with things like resolv.conf, and a /lib with dozens of libraries, and quite possibly bind-mounted /dev, sys, and /tmp, mount /proc, and whatnot.
You'll pretty much find out. At some point point virtualization becomes the easier option.
In one case, I wanted an account to support making SSH tunnels. This means it's fine if the account itself can do essentially nothing.
For even just bash and ls you'll probably need most of the above-mentioned directory structure and a dozen libraries present. (verify)
In general, restricted accounts are best kept as minimal as possible, largely because various not-yet-particularly-fancy commands do things that are not restricted by chroot, and in some cases they can be used to break out of the jail.
There are utilities that help you create such a chroot environment from scratch, such as jk_init.
On links
Hardlinks work fine, because they are not links, they point directly to an inode. They're only called hardlinks to point out multiple file entries point to the same inode. Keep in mind that wrong permissions inside the jail will let users clobber files (that you probably consider as really being) outside the jail.
Symlinks will be resolved within the chroot, so most won't work as you probably intend. Some issues this introduces can be worked around with bind-mounting.