chroot "jail" – what is it and how do I use it?
I have heard/read a lot about the chroot jail under linux but have never yet used it (I use Fedora day-to-day), so what is a chroot “jail”? When and why might I use it/not use it and is there anything else I should know? How would I go about creating one?
A chroot jail is a way to isolate a process and its children from the rest of the system. It should only be used for processes that don’t run as root, as root users can break out of the jail very easily.
The idea is that you create a directory tree where you copy or link in all the system files needed for a process to run. You then use the
chroot() system call to change the root directory to be at the base of this new tree and start the process running in that chroot’d environment. Since it can’t actually reference paths outside the modified root, it can’t perform operations (read/write etc.) maliciously on those locations.
On Linux, using a bind mounts is a great way to populate the chroot tree. Using that, you can pull in folders like
/usr/lib while not pulling in
/usr, for example. Just bind the directory trees you want to directories you create in the jail directory.
Basically you are just changing the root directory of your environment. So
/some-jail/ (or whatever directory you want)
When an application accesses / they’ll get /some-jail/. Also the application can’t break out of /some-jail/ so you know it won’t access anything else on your machine. Its a very simple way of saying ‘hey you can only access these things that I am giving you, and you can’t access anything else on the system.
“chroot jail” is a misnomer that should really die out, but people keep using it.
chroot is a tool that lets you simulate a directory on your filesystem as the root of the filesystem. That means you can have a folder structure like:
chroot foo and do
ls /, you’ll see:
As far as
ls (and any other tools you run) are concerned, those are the only directories on the filesystem. The reason “jail” is a misnomer is
chroot is not intended to force a program to stay in that simulated filesystem; a program that knows it’s in a chroot “jail” can fairly easily escape, so you shouldn’t use
chroot as a security measure to prevent a program from modifying files outside your simulated filesystem
“When and why might I use it ?”
One use is in testing scripts (boot time and otherwise) that make absolute path references, or that run commands that you might want to intercept and log (and perhaps no-op them) – in an environment where you would not want those commands to actually operate on your running environment.
For example I have an embedded device running Linux, I would like to check the operation of some bash without
a) running it on the real device (since I have better tools on my desktop and do not want to brick the device)
b) running it for real on my desktop (since I don’t want my desktop system messed up)
Additionally, you can then discover which commands or other script files are used since the run will exit with an error whenever it attempts to run a command or shell script that is not present in the “chroot jail”.
(Of course, to go the whole hog, you could run inside QEMU or Docker, or a VM, but that would involve creating a VM image etc. – much more work)
chroot is easily understood as a more modern term virtual environment. The process gets a new, virtual, root directory to establish path visibility. This is mainly a convenient and simple way to control what files and libraries can be referenced by the process. It is very helpful for isolating from things that might have different versions available on the actual file system.
You can also think of it as a kind of filter on what is visible in the file system.
It is important to also consider changing the current working directory after chroot to avoid an unexpected view of the file system.
One thing that is misleading is the term jail. Historically there has been use of chroot to simulate what FreeBSD calls a jail others might call a sandbox. To do that requires also self reducing the privileges of the process. Not a great security model.
A common use case is in compiling software that needs to reference a specific toolchain or set of libraries and files and tools that are a subset of what the system actually has.