这一页描述如何使用该debootstrap实用程序在现有 Linux 计算机上安装基本 Debian stable/sid 系统。新安装可使用 进行访问chroot。
这样做时，应注意哪些安全问题？例如，需要采取哪些措施来阻止后台/启动进程在新的 chroot 中启动或以其他方式干扰主系统？
答案1
仅 Chroot 并不能带来任何安全性。换句话说，对待 chroot 就好像 chroot 进程可以访问系统上的所有内容一样 — 因为它们经常这样做。也可以看看chroot "jail" - 它是什么以及如何使用它？——特别注意迈克尔·姆罗泽克的评论
“chroot监狱”是一个用词不当，应该消失
Chroot 只是一种文件遏制方法，它比安全功能更方便。如果您有一个进程允许不受信任的用户指定文件名（例如 FTP 服务器），则 chroot 是一种确保用户无法直接引用 chroot 之外的文件的方法。您应该确保 chroot 不包含任何可能导致逃逸的文件；尤其：
- 仅将最少的设备文件 (
/dev/*) 放入 chroot 中。不要bind-mount/dev，例如你不想要块设备。仅放置 tty 设备和其他数据设备（/dev/null、/dev/zero、/dev/urandom、 ...）。 - 不要挂载
/proc。这是一个很大的限制，但/proc在设计上暴露了很多信息。例如，如果您有一个进程 1234 以 chroot 之外的某个用户身份运行，则任何进程（无论是否已 chroot）都可以以/proc/1234/root.
chroot 进程仍然可以向非 chroot 进程发送信号、打开网络套接字、访问共享内存（目前在 Linux 上，仅当/dev/shm可用时）等。如果您使用 chroot 进行遏制，请不要在外部运行任何进程chroot 作为在 chroot 内运行进程的用户。
Chroot 仍然是一个好方法运行同一操作系统的不同版本（使用相同的内核）1。当存在安全问题时，现在有更好的工具，特别是FreeBSD 监狱和Linux cgroup和LXC。与过去相比，即使在商用硬件上，完全虚拟化（VirtualBox、KVM 等）也已成为更可行的选择。
顺便说一句，在我的回答中，我解释了如何不在 Debian chroot 中启动服务。这不是安全问题，并且假设服务是协作的并且编写正确。