426 lines
19 KiB
Markdown
426 lines
19 KiB
Markdown
很多人对 Docker 有个误解，觉得容器就是轻量级虚拟机。这个想法很危险。虚拟机有自己独立的内核，而容器是共享宿主机内核的，区别大了去了。
|
||
|
||
Docker 的隔离主要靠两样东西：**[Namespace](https://zhida.zhihu.com/search?content_id=784190073&content_type=Answer&match_order=1&q=Namespace&zhida_source=entity)** 和 **[Cgroup](https://zhida.zhihu.com/search?content_id=784190073&content_type=Answer&match_order=1&q=Cgroup&zhida_source=entity)**。
|
||
|
||
Namespace 做的是资源视角的隔离，让容器里的进程觉得自己是系统唯一的主人。Linux 目前提供了 6 个主要的 Namespace：
|
||
|
||
- **PID Namespace**：容器里的进程看不到宿主机和其他容器的进程
|
||
- **Mount Namespace**：容器有自己独立的文件系统挂载点
|
||
- **Network Namespace**：容器有独立的网络栈、IP地址、端口
|
||
- **IPC Namespace**：进程间通信隔离
|
||
- **UTS Namespace**：主机名隔离
|
||
- **[User Namespace](https://zhida.zhihu.com/search?content_id=784190073&content_type=Answer&match_order=1&q=User+Namespace&zhida_source=entity)**：用户和用户组隔离
|
||
|
||
Cgroup 做的是资源使用的限制，防止一个容器把宿主机的 CPU、内存、磁盘 IO 全吃光。
|
||
|
||
听着挺完善的对吧？但问题在于，这些隔离都是"软隔离"，不是"硬隔离"。共享内核意味着，一旦内核有漏洞，或者你的配置有疏漏，容器里的恶意代码就有可能突破这些限制，逃到宿主机上。
|
||
|
||
我之前看过一个案例，某在线编程平台因为配置不当，用户通过 Python 的 `os.system()` 直接在宿主机上执行了命令，把整台服务器搞崩了。所以，做代码沙箱，安全这根弦必须绷紧。
|
||
|
||
## **第一道锁：资源限制，别让恶意代码把机器吃干抹净**
|
||
|
||
做代码沙箱，最基本的就是限制资源。你想想，要是用户提交一个死循环，或者疯狂 fork 进程的 fork 炸弹，不限制的话宿主机直接就废了。
|
||
|
||
我一般会在 `docker run` 的时候加上这些参数：
|
||
|
||
```bash
|
||
docker run \
|
||
--memory="512m" \
|
||
--memory-swap="512m" \
|
||
--cpus="1" \
|
||
--pids-limit="50" \
|
||
--cpu-shares=512 \
|
||
sandbox-runner
|
||
```
|
||
|
||
逐个解释下：
|
||
|
||
- `--memory="512m"`：限制容器最多使用 512MB 内存，超过就直接 OOM Kill，不给任何商量余地
|
||
- `--memory-swap="512m"`：这个和 memory 设成一样的值，意思就是禁用 swap。别小看这个，有些恶意代码会利用 swap 来绕过内存限制
|
||
- `--cpus="1"`：最多使用 1 个 CPU 核心的算力
|
||
- `--pids-limit="50"`：限制容器内最多 50 个进程。这个是防 fork 炸弹的关键，`:(){ :|:& };:` 这种东西直接就废了
|
||
- `--cpu-shares=512`：CPU 时间的权重分配，多个容器竞争 CPU 时按这个比例来
|
||
|
||
还有一点容易忽略的，磁盘 IO 也得限制：
|
||
|
||
```bash
|
||
# 创建限速的 cgroup
|
||
mkdir /sys/fs/cgroup/blkio/sandbox
|
||
echo "8:0 1048576" > /sys/fs/cgroup/blkio/sandbox/blkio.throttle.read_bps_device
|
||
```
|
||
|
||
不过说实话，磁盘 IO 限制在实际操作中比较麻烦，我更倾向于直接把容器的文件系统设成只读，后面会讲。
|
||
|
||
## **第二道锁：Capability 裁剪，别给容器不需要的权限**
|
||
|
||
Linux 把 root 的权限拆分成了几十个 Capability，Docker 默认只保留了容器运行所需的一小部分。但即便如此，默认配置下容器还是有一些不必要的权限。
|
||
|
||
你可以用这个命令看看默认情况下容器有哪些 Capability：
|
||
|
||
```bash
|
||
docker run --rm alpine capsh --print
|
||
```
|
||
|
||
我这边输出大概有这些：`CAP_CHOWN`, `CAP_DAC_OVERRIDE`, `CAP_FSETID`, `CAP_FOWNER`, `CAP_MKNOD`, `CAP_NET_RAW`, `CAP_SETGID`, `CAP_SETUID`, `CAP_SETFCAP`, `CAP_SETPCAP`, `CAP_NET_BIND_SERVICE`, `CAP_SYS_CHROOT`, `CAP_KILL`, `CAP_AUDIT_WRITE`。
|
||
|
||
对于代码沙箱来说，这里面很多都是多余的。我的做法是把所有 Capability 都去掉，只加回必须的：
|
||
|
||
```bash
|
||
docker run \
|
||
--cap-drop=ALL \
|
||
--cap-add=NET_BIND_SERVICE \
|
||
sandbox-runner
|
||
```
|
||
|
||
`--cap-drop=ALL` 先把所有权限都干掉，然后 `--cap-add=NET_BIND_SERVICE` 只加回绑定 1024 以下端口的权限（如果你的沙箱不需要网络，这个也省了）。
|
||
|
||
千万别用 `--privileged` 参数！这个参数等于把所有安全机制全关了，容器里的 root 和宿主机的 root 基本没区别。我见过有人在生产环境用 `--privileged` 跑容器，被领导骂了三天。
|
||
|
||
## **第三道锁：[Seccomp](https://zhida.zhihu.com/search?content_id=784190073&content_type=Answer&match_order=1&q=Seccomp&zhida_source=entity) 系统调用过滤，把攻击面缩到最小**
|
||
|
||
Seccomp 是我最喜欢的一个安全机制。它可以在内核层面限制容器进程能调用哪些系统调用，相当于给容器加了一层"系统调用防火墙"。
|
||
|
||
Docker 默认就启用了 Seccomp，使用一个白名单配置文件，默认会屏蔽大约 44 个危险或不常用的系统调用。你可以通过 `docker info` 确认：
|
||
|
||
```text
|
||
Security Options:
|
||
seccomp
|
||
Profile: default
|
||
```
|
||
|
||
但是，默认配置对于代码沙箱来说还是太宽松了。我一般会写一个自定义的 Seccomp Profile，只允许代码执行真正需要的系统调用。
|
||
|
||
举个实际的例子，如果沙箱只用来运行 Python 代码，我可以通过 `strace` 先抓取 Python 运行时需要哪些系统调用：
|
||
|
||
```bash
|
||
strace -c -f python3 /tmp/test.py 2>&1 | head -50
|
||
```
|
||
|
||
然后根据抓取结果编写 Seccomp Profile。一个精简版的 Profile 大概长这样：
|
||
|
||
```json
|
||
{
|
||
"defaultAction": "SCMP_ACT_ERRNO",
|
||
"architectures": ["SCMP_ARCH_X86_64"],
|
||
"syscalls": [
|
||
{
|
||
"names": [
|
||
"read", "write", "open", "close", "fstat", "lseek",
|
||
"mmap", "mprotect", "munmap", "brk", "rt_sigaction",
|
||
"rt_sigprocmask", "ioctl", "access", "pipe", "select",
|
||
"poll", "mremap", "nanosleep", "clock_gettime",
|
||
"clone", "fork", "vfork", "execve", "exit", "wait4",
|
||
"uname", "fcntl", "flock", "fsync", "dup", "dup2",
|
||
"getpid", "getppid", "getuid", "getgid", "geteuid",
|
||
"getegid", "getrlimit", "gettimeofday", "arch_prctl",
|
||
"set_tid_address", "set_robust_list", "futex",
|
||
"clock_getres", "clock_nanosleep"
|
||
],
|
||
"action": "SCMP_ACT_ALLOW"
|
||
}
|
||
]
|
||
}
|
||
```
|
||
|
||
关键点在于 `defaultAction` 设成了 `SCMP_ACT_ERRNO`，意思就是默认拒绝所有系统调用，只在白名单里的才放行。这比默认配置安全得多。
|
||
|
||
使用自定义 Profile 启动容器：
|
||
|
||
```bash
|
||
docker run \
|
||
--security-opt seccomp=/path/to/seccomp-profile.json \
|
||
sandbox-runner
|
||
```
|
||
|
||
有个真实的案例很有说服力：CVE-2017-16995 这个内核漏洞，攻击者可以通过 bpf 系统调用实现提权。但 Docker 默认的 Seccomp 配置屏蔽了 bpf 系统调用，所以这个漏洞在 Docker 容器里根本没法利用。这就是 Seccomp 的价值。
|
||
|
||
不过写 Seccomp Profile 是个苦力活，不同语言运行时需要的系统调用不一样，你得一个一个测。我建议先用 `SCMP_ACT_LOG` 模式跑一段时间收集日志，确认没问题再切换到 `SCMP_ACT_ERRNO`。
|
||
|
||
## **第四道锁：[AppArmor](https://zhida.zhihu.com/search?content_id=784190073&content_type=Answer&match_order=1&q=AppArmor&zhida_source=entity) / SELinux，强制访问控制再加一道门**
|
||
|
||
Seccomp 管的是系统调用，AppArmor 管的是资源访问。它可以在文件读写、网络访问、Capability 等层面做更细粒度的限制。
|
||
|
||
Ubuntu 默认使用 AppArmor，CentOS/RHEL 默认使用 SELinux。Docker 在 Ubuntu 上默认会给容器加载一个 AppArmor Profile，叫做 `docker-default`。
|
||
|
||
对于代码沙箱，我一般会写一个更严格的自定义 AppArmor Profile：
|
||
|
||
```text
|
||
#include <tunables/global>
|
||
|
||
profile sandbox-profile flags=(attach_disconnected,mediate_deleted) {
|
||
#include <abstractions/base>
|
||
|
||
# 只允许读 /usr 和 /lib
|
||
/usr/** r,
|
||
/lib/** r,
|
||
/lib64/** r,
|
||
|
||
# 允许写临时目录
|
||
/tmp/** rw,
|
||
/dev/null rw,
|
||
/dev/urandom r,
|
||
|
||
# 禁止网络访问（除了已建立的连接）
|
||
deny network,
|
||
deny network inet,
|
||
deny network inet6,
|
||
|
||
# 禁止 ptrace（防止调试其他进程）
|
||
deny ptrace,
|
||
|
||
# 禁止 mount
|
||
deny mount,
|
||
|
||
# 禁止加载内核模块
|
||
deny /sys/module/** rw,
|
||
}
|
||
```
|
||
|
||
加载并使用这个 Profile：
|
||
|
||
```bash
|
||
# 编译并加载 Profile
|
||
apparmor_parser -r /etc/apparmor.d/sandbox-profile
|
||
|
||
# 使用 Profile 启动容器
|
||
docker run \
|
||
--security-opt apparmor=sandbox-profile \
|
||
sandbox-runner
|
||
```
|
||
|
||
AppArmor 还有个好处是它的日志很好用。当容器进程尝试访问被禁止的资源时，`/var/log/syslog` 或 `/var/log/audit/audit.log` 里会有详细记录，方便你排查问题。
|
||
|
||
如果你的系统是 CentOS，那就用 SELinux，思路是一样的，只是配置方式不同。SELinux 用标签和策略来管理访问控制，比 AppArmor 更严格但也更复杂。不过对于代码沙箱场景，AppArmor 够用了。
|
||
|
||
## **第五道锁：User Namespace，让容器里的 root 变成宿主机的 nobody**
|
||
|
||
这是个很容易被忽略但非常重要的安全机制。默认情况下，Docker 容器里的 root 用户（UID 0）和宿主机的 root 用户在文件权限上是等价的。也就是说，一旦容器逃逸，攻击者拿到的是宿主机的 root 权限，想想都后怕。
|
||
|
||
User Namespace 的作用是把容器内的 UID 映射到宿主机的非特权 UID。比如容器内的 root（UID 0）在宿主机上实际是 UID 100000，这样就算逃逸了，攻击者在宿主机上也没有任何特权。
|
||
|
||
Docker 启用 User Namespace 的方式：
|
||
|
||
```bash
|
||
# 先在 /etc/docker/daemon.json 中配置
|
||
{
|
||
"userns-remap": "default"
|
||
}
|
||
|
||
# 重启 Docker
|
||
systemctl restart docker
|
||
```
|
||
|
||
Docker 会自动创建一个叫 `dockremap` 的用户，并配置 subuid 和 subgid 映射。你可以验证一下：
|
||
|
||
```bash
|
||
cat /etc/subuid
|
||
# dockremap:100000:65536
|
||
|
||
cat /etc/subgid
|
||
# dockremap:100000:65536
|
||
```
|
||
|
||
这意味着容器内的 UID 0-65535 会映射到宿主机的 UID 100000-165535。
|
||
|
||
启用 User Namespace 之后有个副作用：一些需要特权的操作（比如挂载 NFS、使用 `--net=host`）就不能用了。但对于代码沙箱来说，这些功能本来就不需要，所以影响不大。
|
||
|
||
## **第六道锁：只读文件系统 + 临时存储，不给恶意代码留后门**
|
||
|
||
代码沙箱最怕的就是恶意代码往文件系统里写东西，比如写个后门脚本、改个配置文件什么的。我的做法是把容器的根文件系统设成只读：
|
||
|
||
```bash
|
||
docker run \
|
||
--read-only \
|
||
--tmpfs /tmp:size=100m,mode=1777 \
|
||
--tmpfs /run:size=10m,mode=0755 \
|
||
sandbox-runner
|
||
```
|
||
|
||
`--read-only` 把整个根文件系统挂载为只读，`--tmpfs` 给需要写入的目录单独挂载内存文件系统。`/tmp` 给 100MB，`/run` 给 10MB，够用了。
|
||
|
||
有些运行时还需要 `/dev/shm`，也可以加上：
|
||
|
||
```bash
|
||
--tmpfs /dev/shm:size=64m,mode=1777
|
||
```
|
||
|
||
这样恶意代码就算想写东西，也只能写到 `/tmp` 里，而且容器一销毁就没了，啥也留不下。
|
||
|
||
还有一点，别把宿主机的目录挂载到容器里，尤其是敏感目录。我见过有人把 `/var/run/docker.sock` 挂进容器的，这等于把宿主机的 Docker 控制权拱手让人，攻击者可以直接创建一个特权容器然后逃逸。
|
||
|
||
## **第七道锁：网络隔离，让恶意代码连不上外网**
|
||
|
||
代码沙箱里的程序一般不需要网络访问。就算需要，也应该严格限制。
|
||
|
||
最简单粗暴的方式就是直接禁用网络：
|
||
|
||
```bash
|
||
docker run \
|
||
--network=none \
|
||
sandbox-runner
|
||
```
|
||
|
||
这样容器里连 `ping` 都用不了，恶意代码想外传数据？没门。
|
||
|
||
如果你的沙箱确实需要网络（比如代码里要请求某个 API），那可以用自定义网络 + iptables 规则来做白名单：
|
||
|
||
```bash
|
||
# 创建自定义网络
|
||
docker network create --driver bridge sandbox-net
|
||
|
||
# 启动容器
|
||
docker run \
|
||
--network=sandbox-net \
|
||
sandbox-runner
|
||
|
||
# 在宿主机上用 iptables 限制容器只能访问特定 IP
|
||
iptables -I FORWARD -s 172.20.0.0/16 -d 允许的IP -j ACCEPT
|
||
iptables -I FORWARD -s 172.20.0.0/16 -j DROP
|
||
```
|
||
|
||
这样容器只能访问你允许的 IP，其他一概不通。
|
||
|
||
## **第八道锁：超时机制，别让代码跑到天荒地老**
|
||
|
||
恶意代码不一定要搞破坏，它也可以就是跑个死循环，占着你的计算资源不放。所以超时机制必须有。
|
||
|
||
我一般这样处理：
|
||
|
||
```bash
|
||
timeout 10 docker run \
|
||
--rm \
|
||
--memory="512m" \
|
||
--cpus="1" \
|
||
sandbox-runner
|
||
```
|
||
|
||
`timeout 10` 表示 10 秒后强制终止。`--rm` 表示容器结束后自动删除，不留痕迹。
|
||
|
||
但在生产环境中，我更倾向于在代码层面控制超时，因为 `timeout` 命令发的是 SIGTERM，有些进程可能捕获信号后不退出。更可靠的做法是在容器内部用进程管理器来控制：
|
||
|
||
```python
|
||
import subprocess
|
||
import signal
|
||
|
||
try:
|
||
result = subprocess.run(
|
||
["python3", "/tmp/user_code.py"],
|
||
timeout=10,
|
||
capture_output=True,
|
||
preexec_fn=lambda: signal.signal(signal.SIGALRM, lambda *_: (_ for _ in ()).throw(TimeoutError()))
|
||
)
|
||
except subprocess.TimeoutExpired:
|
||
# 超时处理
|
||
pass
|
||
```
|
||
|
||
## **终极大招：gVisor / [Kata Containers](https://zhida.zhihu.com/search?content_id=784190073&content_type=Answer&match_order=1&q=Kata+Containers&zhida_source=entity)，真正的沙箱容器**
|
||
|
||
前面说的那些加固措施，都是基于传统 Docker 容器的，本质上还是共享内核。如果你的安全要求特别高（比如多租户环境、运行完全不可信的代码），那可以考虑使用沙箱容器运行时。
|
||
|
||
**gVisor** 是 Google 开源的一个项目，它实现了一个用户态内核叫 Sentry，拦截容器进程的所有系统调用，在用户态处理后再转发给宿主机内核。这样容器进程和宿主机内核之间就多了一层防护，攻击面大幅缩小。
|
||
|
||
gVisor 和宿主机内核的通信只用了不到 20 个系统调用，而传统容器可以用 300 多个。这差距，安全程度可想而知。
|
||
|
||
安装和使用 gVisor 也比较简单：
|
||
|
||
```bash
|
||
# 安装 runsc
|
||
curl -fsSL https://gvisor.dev/archive.key | sudo gpg --dearmor -o /usr/share/keyrings/gvisor-archive-keyring.gpg
|
||
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/gvisor-archive-keyring.gpg] https://storage.googleapis.com/gvisor/releases release main" | sudo tee /etc/apt/sources.list.d/gvisor.list
|
||
sudo apt-get update && sudo apt-get install runsc
|
||
|
||
# 配置 Docker 使用 runsc
|
||
# 在 /etc/docker/daemon.json 中添加
|
||
{
|
||
"runtimes": {
|
||
"runsc": {
|
||
"path": "/usr/bin/runsc"
|
||
}
|
||
}
|
||
}
|
||
|
||
# 重启 Docker
|
||
systemctl restart docker
|
||
|
||
# 使用 gVisor 运行容器
|
||
docker run --runtime=runsc sandbox-runner
|
||
```
|
||
|
||
gVisor 的缺点也很明显：系统调用开销导致性能有损耗，不适合系统调用密集型的应用；不支持 GPU 直通；没有实现全部的 Linux 系统调用，有些应用可能跑不起来。
|
||
|
||
**Kata Containers** 是另一种方案，它本质上是在轻量级虚拟机里跑容器。每个容器（或 Pod）都有自己独立的内核，隔离性接近虚拟机，但使用体验和普通容器一样。
|
||
|
||
Kata 的安全边界比 gVisor 更强，但资源开销也更大，每个容器至少需要几十 MB 的额外内存。对于在线编程平台这种需要同时运行成百上千个沙箱的场景，gVisor 可能更合适。
|
||
|
||
## **我的最终方案：层层叠加，纵深防御**
|
||
|
||
说了这么多，最后晒一下我在生产环境中实际使用的完整配置。我把它封装成了一个脚本：
|
||
|
||
```bash
|
||
#!/bin/bash
|
||
docker run \
|
||
--rm \
|
||
--runtime=runsc \
|
||
--network=none \
|
||
--read-only \
|
||
--memory="512m" \
|
||
--memory-swap="512m" \
|
||
--cpus="1" \
|
||
--pids-limit="50" \
|
||
--cap-drop=ALL \
|
||
--security-opt seccomp=/etc/docker/seccomp/sandbox.json \
|
||
--security-opt apparmor=sandbox-profile \
|
||
--tmpfs /tmp:size=100m,mode=1777 \
|
||
--tmpfs /run:size=10m,mode=0755 \
|
||
--user=1000:1000 \
|
||
sandbox-runner \
|
||
timeout 10 python3 /tmp/user_code.py
|
||
```
|
||
|
||
这里有几个值得注意的点：
|
||
|
||
1. `--runtime=runsc`：使用 gVisor 运行时，从内核层面加强隔离
|
||
2. `--network=none`：完全禁用网络
|
||
3. `--read-only`：只读文件系统
|
||
4. `--cap-drop=ALL`：去掉所有 Linux Capabilities
|
||
5. `--security-opt seccomp=...`：自定义 Seccomp Profile
|
||
6. `--security-opt apparmor=...`：自定义 AppArmor Profile
|
||
7. `--user=1000:1000`：以非 root 用户运行
|
||
8. `timeout 10`：10 秒超时
|
||
|
||
这套配置不是一次性就定下来的，是在实际运行中不断调整的。刚开始的时候，因为 Seccomp 太严格导致很多正常代码跑不了，我就把 `SCMP_ACT_ERRNO` 改成 `SCMP_ACT_LOG` 先观察了一周，收集了所有被拒绝的系统调用，确认哪些是必须的后才逐步放开。
|
||
|
||
还有个经验：每次更新语言运行时版本后，都要重新测试 Seccomp Profile，因为新版本可能会用到之前不需要的系统调用。我就吃过这个亏，升级 Python 版本后用户代码全报错，排查了半天才发现是 Seccomp 屏蔽了一个新加的系统调用。
|
||
|
||
## **一些血的教训**
|
||
|
||
最后分享几个我在实战中遇到的真实问题：
|
||
|
||
**1. docker.sock 千万别挂进去**
|
||
|
||
这个前面提过了，但还是要强调。我见过不止一次，有人为了在容器里操作 Docker，把 `/var/run/docker.sock` 挂进容器。这就等于把宿主机的 root 权限交出去了。
|
||
|
||
**2. 别用 latest 标签跑生产环境**
|
||
|
||
镜像版本要固定，用 digest 更好。恶意镜像替换这种攻击虽然少见，但不是不可能。
|
||
|
||
**3. 定期更新内核**
|
||
|
||
Docker 的安全很大程度上依赖内核。脏牛漏洞（CVE-2016-5195）可以直接从容器里逃逸，就是因为内核的问题。保持内核更新是最基本的安全措施。
|
||
|
||
**4. CVE-2019-5736 的启示**
|
||
|
||
这个漏洞非常经典。攻击者通过覆写宿主机上的 runc 二进制文件，实现了容器逃逸。根本原因是 runc 进入容器命名空间时，`/proc/self/exe` 指向了宿主机的 runc 程序，而容器内的 root 用户可以写入这个文件。这个漏洞的修复方式是在 runc 进入容器前先克隆一份自身的二进制文件。这个案例告诉我们，不要低估攻击者的创造力，即使看起来很小的疏漏也可能被利用。
|
||
|
||
**5. 监控和日志不能少**
|
||
|
||
再安全的沙箱也需要监控。我会在宿主机上用 auditd 记录所有和容器相关的系统调用，用 Falco 做运行时安全检测。一旦发现异常行为（比如容器进程尝试访问 `/proc` 或 `/sys` 下的敏感文件），立即告警。
|
||
|
||
## **总结**
|
||
|
||
做 Docker 代码沙箱，没有银弹，只有纵深防御。单靠任何一层安全机制都不够可靠，必须把 Namespace、Cgroup、Capability、Seccomp、AppArmor、User Namespace、只读文件系统、网络隔离这些手段叠加起来，再加上 gVisor 这类沙箱运行时，才能把风险降到可接受的水平。
|
||
|
||
记住一个原则：**最小权限**。容器只需要能完成任务的最低权限，多给一点都不行。安全这事儿，宁可过度，不能不足。
|
||
|
||
还有就是，安全是一个持续的过程，不是一次性的配置。新的漏洞会不断出现，你的防御措施也要跟着更新。保持关注 Docker 和 Linux 内核的安全公告，及时打补丁，这是最基本的运维素养。 |