chroot
From NetBSD Wiki
The chroot(2) system call changes the directory a process sees as root ('/'). After this call, the process will never ever be able to see any directory higher up in the 'real' directory hierarchy, only those files and directories that lie below it. The chroot stays in effect even for subcommands executed by the original chrooted process, so there is (theoretically) no way to get out of a chroot once you're in one.
The chroot(8) command simply performs the aforementioned syscall and executes either a target command or the shell.
Chroot is useful in cases where you wish to confine programs like webservers or other services that might be vulnerable to attack from the outside. These programs, when hacked, would only be able to destroy or harm a system's filesystem below a certain directory. Anyone who would gain system access through these processes will only be able to see the files below the chrooted directory.
For chroot to work properly, you'll generally need to install copies of (or make hardlinks to) binaries like the shell and libraries like libc. Otherwise, these programs and libraries will not be found since any process that is chrooted and any descendents of these processes will only be able to find anything below the chrooted dir. In practice, this means that you need to reproduce at least /bin, /sbin, /lib and /etc inside the chrooted environment, unless you're certain the chrooted process will not be requiring any subprocesses.
Instead of copying the files, you could also use a nullfs mount of the required subdirectories from the base system, preferably mounted readonly.
You can also use chroot when you wish to work on a mounted drive as if it were the base system, like when performing system maintenance or verification of any kind.
Contents |
Jails and chroot
FreeBSD has the concept of a jail, which is like a chroot, but with a more complete set of restrictions. Not only is a jailed process confined to a subset of the root filesystem, but it also gets its own IP address, which allows you to set up firewalling rules for this specific program. It also prevents jailed processes to see or interact with any processes outside of its jail, something that chroot doesn't do and a number of other things.
According to FreeBSD people, this is quite a bit more powerful than simply being able to set a chroot environment, since it helps prevent a lot more intrusions than simple filesystem intrusions. Others say chroot was never intended for security purposes in the first place. The NetBSD project's members have always held the position that jails were "arbitrarily defined", or worse, "a bad hack".
Recent developments have made jails deprecated: with systrace and virtualisation (eg, NetBSD/xen) you can often achieve even better security. These solutions are more general-purpose, elegant and less prone to contain bugs that can result in a compromised system. They are slightly harder to set up than a jail, though (a jail is set up almost like a chroot), which is probably why jails continue to be a popular feature of FreeBSD.
There is also an interesting new research project called "mult" (short for "Multiplicity"), based on a forked NetBSD 3.1 codebase. It allows multiple init process trees at once, where each subprocess of init can only see other processes within the same init process tree, in effect creating 'jails' without requiring special hooks in the codebase like Jails proper.
Examples:
To switch into a chrooted environment use:
# chroot /path/to/environment
See also
View source code (Please report any bugs or suggestions here).
References
- Jails:Confining the omnipotent root, a BSD article found on the FreeBSD website.
- OnLAMP article on FreeBSD Jails
- Implementing jail-like functionality in NetBSD and OpenBSD using systrace
- A typical post explaining the NetBSD view on jails. Read the entire thread if you would like to know more.
