Debian unstable chroot security issues

Question

This page describes how you can use the debootstrap utility to install a base Debian unstable/sid system on an existing Linux machine. The new install is accessible using chroot.

When doing this, what security issues should be kept in mind? For example, what needs to be done to stop background/startup processes from starting in the new chroot or otherwise interfering with the main system?

Answer 1

Chroot alone doesn't bring any kind of security. In other words, treat a chroot as if the chrooted processes could access everything on the system — because often they do. See also chroot "jail" - what is it and how do I use it? — note in particular Michael Mrozek's remark

"chroot jail" is a misnomer that should really die out

Chroot is a containment method for files only, and it's more of a convenience than a security feature. If you have a process that lets untrusted users specify file names (an FTP server, for example), chroot is a way to make sure that the users aren't going to be able to reference files outside the chroot directly. You should to make sure that the chroot doesn't contain any file that could lead to an escape; in particular:

• Put only the bare minimum of device files (/dev/*) in the chroot. Don't bind-mount /dev, for example you don't want block devices there. Only put tty devices and the miscellaneous data devices (/dev/null, /dev/zero, /dev/urandom, …).
• Don't mount /proc. This is a big constraint, but /proc exposes a lot of information by design. For example, if you have a process 1234 is running as a certain user outside the chroot, then any process (chrooted or not) can access the root directory as /proc/1234/root.

A chrooted process can still send signals to non-chrooted processes, open network sockets, access shared memory (on Linux, nowadays, only if /dev/shm is available), etc. If you're using chroot for containment, don't run any process outside the chroot as a user who's running processes inside the chroot.

Chroot remains a good way to run a different version of the same OS (with the same kernel)¹. When there are security concerns, there are better tools nowadays, in particular FreeBSD jails and Linux cgroups and LXC. Compared with the old days, full virtualization (VirtualBox, KVM, …) has also become a more viable option even on commodity hardware.

¹ _{By the way, in my answer there I explain how to not start services inside a Debian chroot. This isn't a security concern, and there's an assumption that the services are cooperative and correctly written.}