chroot仅实现文件系统路径重映射，无法阻断网络、进程、设备等内核资源访问；单独使用存在网络外连、磁盘直读、宿主进程杀伤、资源耗尽等真实风险，必须配合unshare命名空间、IOMMU加固及模块禁用才具备物理隔离能力。
chroot 本身不能实现物理隔离，它只做文件系统路径重映射，不阻断网络、进程、设备访问等任何内核级资源。所谓“物理隔离”必须靠其他机制配合，否则只是假隔离。
chroot 单独运行服务时会暴露哪些真实风险
直接 chroot 启动一个服务（比如 chroot /srv/myapp /usr/bin/python3 app.py），看似进了新根目录，但实际仍共享全部系统资源：
- 服务仍能调用
socket()建立任意网络连接——chroot不碰网络命名空间 - 可读写宿主
/proc、/sys下所有信息（如/proc/sys/net/ipv4/ip_forward） - 能通过
/dev/sda或/dev/nvme0n1直接访问物理磁盘（只要挂载了/dev） - 所有进程 PID 共享同一命名空间，
kill -9 -1会干掉整个宿主系统 - 没有内存/CPU 限制，一个崩溃的服务可能拖垮整台机器
真正阻断物理层通信必须加 unshare --net --pid --user
仅靠 chroot 防不住网络外连或设备扫描。要切断通信路径，必须组合 unshare 创建独立命名空间：
- 用
unshare --net --pid --user --mount --fork启动新命名空间，再在其中执行chroot -
--net是关键：新环境默认无网络接口，ip link只能看到lo，且无法启用其他网卡 -
--user映射 UID/GID，避免服务以 root 身份操作宿主设备节点（如/dev/mem） -
--mount配合--fork保证/proc、/sys挂载点不泄漏到宿主 - 示例命令：
sudo unshare --net --pid --user --mount --fork chroot /srv/myapp /bin/bash
防止 USB/PCI 设备逃逸需禁用对应内核模块
即使进了 unshare + chroot 环境，若宿主未禁用硬件驱动，服务仍可能通过 /dev 下的设备节点发起 DMA 攻击或外设通信：
- 检查是否加载了
usb-storage、cdc_ether、r8169、iwlwifi等模块：lsmod | grep -E 'usb|net|wifi|bluetooth' - 永久屏蔽：在
/etc/modprobe.d/disable-devices.conf中写入blacklist usb-storage、blacklist r8169等，并运行update-initramfs -u（Debian）或dracut --force（RHEL） - 启动参数加固：在
/etc/default/grub的GRUB_CMDLINE_LINUX加iommu=pt intel_iommu=on，再update-grub && reboot - 验证 IOMMU 是否生效：
dmesg | grep -i iommu输出含enabled
退出前必须手动卸载绑定挂载，否则残留 /proc /dev 会锁死宿主
很多人用 mount --bind 把宿主 /proc、/dev 挂进 chroot 目录，但忘记清理。一旦 shell 异常退出，这些挂载点会持续存在，导致：
-
umount /srv/myapp/proc失败并报device is busy - 后续
reboot卡在 “Unmounting filesystems…” - 必须进 recovery mode 手动
umount -l（lazy unmount）才能解救 - 正确做法：退出 chroot 后立即执行
sudo umount /srv/myapp/{proc,sys,dev} - 更稳妥方案：改用
unshare --mount自动管理挂载生命周期，无需手动清理
真正物理隔离不是“把服务塞进一个目录”，而是逐层关闭所有隐性通信面：从内核模块、IOMMU、命名空间到挂载点，缺一不可。chroot 只是其中最表层的一环，单独使用等于没隔离。
