跳到主要内容

策略模式与内置规则

策略模式

可通过 VarmorPolicy/VarmorClusterPolicy 对象的 spec.policy.mode 字段来指定运行模式。不同 enforcers 支持的模式如下表所示。

运行模式AppArmorBPFSeccomp说明
AlwaysAllow[x][x][x]在容器启动时不对其施加任何强制访问控制
RuntimeDefault[x][x][x]使用与容器运行时组件相同的默认策略(如 containerd 的 cri-containerd.apparmor.d)进行基础防护
EnhanceProtect[x][x][x]- 支持 5 类内置规则和自定义接口,以满足不同的防护需求。
- 默认在 RuntimeDefault 模式的基础上进行增强防护(当 spec.policy.enhanceProtect.privilegednilfalse 时)
- 支持在 AlwaysAllow 模式的基础上进行增强防护(当 spec.policy.enhanceProtect.privilegedtrue
BehaviorModeling[x][ ][x]- 利用 BPF & Audit 等技术同时对多个工作负载进行行为建模
- 行为模型保存在对应的 ArmorProfileModel 对象中
- 不可切换防护模式
- 请参见 The BehaviorModeling Mode
DefenseInDepth[x]-[x]基于行为模型 ArmorProfileModel 对工作负载进行防护

注意:
- vArmor 策略支持动态切换运行模式(限 EnhanceProtect, RuntimeDefault, AlwaysAllow, DefenseInDepth)、更新沙箱规则,而无需重启工作负载。但当使用 Seccomp enforcer 时,需要重启工作负载来使 Seccomp Profile 的变更生效。
- vArmor 支持修改策略为其添加新的 enforcer,但不支持删除已经设置的 enforcer。除此之外,新添加的 enforcer 仅对新创建的 Workloads 生效。

内置规则

vArmor 支持使用在 EnhanceProtect 模式下使用内置规则和自定义接口来定义防护策略,当前支持的内置规则及其分类如下表所示。你可以尝试使用 policy advisor 来生成策略模版,从而帮助创建最终的防护策略。

注意:
- 不同 enforcer 所支持的内置策略与语法仍旧处于开发中。
- 不同 enforcer 所能支持的规则和语法会有所区别。例如 AppArmor enforcer 不支持细粒度的网络访问控制,BPF 不支持对指定的可执行程序进行访问控制等。

类别子类规则名称 & ID适用容器说明原理 & 影响支持的 enforcer
Hardening阻断特权容器的常见逃逸向量禁止改写 procfs core_pattern

disallow-write-core-pattern
Privileged攻击者可能会在特权容器(Privileged Container)中,通过改写 procfs core_pattern,来实施容器逃逸。或者在特权容器(w/ CAP_SYS_ADMIN)中,卸载特定挂载点后改写 procfs core_pattern,来实施容器逃逸。禁止修改 procfs 的 core_patternAppArmor
BPF
禁止挂载 securityfs

disallow-mount-securityfs
Privileged攻击者可能会在特权容器(w/ CAP_SYS_ADMIN)中,以读写权限挂载新的 securityfs 并对其进行修改。禁止挂载新的 securityfsAppArmor
BPF
禁止重新挂载 procfs

disallow-mount-procfs
Privileged攻击者可能会在特权容器(w/ CAP_SYS_ADMIN)中,以读写权限重新挂载 procfs,然后再通过改写 core_pattern 等方式进行容器逃逸、修改系统配置。1. 禁止挂载新的 procfs

2. 禁止使用 bind, rbind, move, remount 选项重新挂载 /proc**

3. 使用 BPF enforcer 时,还将禁止卸载 /proc**
AppArmor
BPF
禁止改写 cgroupfs release_agent

disallow-write-release-agent
Privileged攻击者可能会在特权容器(Privileged Container)中,通过改写 cgroupfs release_agent,来实施容器逃逸。禁止修改 cgroupfs 的 release_agentAppArmor
BPF
禁止重新挂载 cgroupfs

disallow-mount-cgroupfs
Privileged攻击者可能会在特权容器(w/ CAP_SYS_ADMIN)中,以读写权限重新挂载 cgroupfs。然后再通过改写 release_agent、设备访问权限等方式进行容器逃逸、修改系统配置。1. 禁止挂载新的 cgroupfs

2. 禁止使用 bind, rbind, move, remount 选项重新挂载 /sys/fs/cgroup**

3. 禁止使用 rbind 选项重新挂载 /sys**

4. 使用 BPF enforcer 时,还将禁止卸载 /sys**
AppArmor
BPF
禁止调试磁盘设备

disallow-debug-disk-device
Privileged攻击者可能会在特权容器(Privileged Container)中,通过调试宿主机磁盘设备,从而实现宿主机文件的读写。

建议配合 disable_cap_mknod 使用,从而防止攻击者利用 mknod 创建新的设备文件,从而绕过此规则
动态获取宿主机磁盘设备文件,并禁止在容器内以读写权限访问AppArmor
BPF
禁止挂载宿主机磁盘设备并访问

disallow-mount-disk-device
Privileged攻击者可能会在特权容器(Privileged Container)中,挂载宿主机磁盘设备,从而实现宿主机文件的读写。

建议配合 disable_cap_mknod 使用,从而防止攻击者利用 mknod 创建新的设备文件,从而绕过此规则
动态获取宿主机磁盘设备文件,并禁止在容器内挂载AppArmor
BPF
禁用 mount 系统调用

disallow-mount
PrivilegedMOUNT(2) 常被用于权限提升、容器逃逸等攻击。而几乎所有的微服务应用都无需 mount 操作,因此建议使用此规则限制容器内进程访问 mount 系统调用。

注:当 spec.policy.privileged 为 false 时,将默认禁用 mount 系统调用。
禁用 mount 系统调用AppArmor
BPF
禁用 umount 系统调用

disallow-umount
ALLUMOUNT(2) 可被用于卸载敏感的挂载点(例如 maskedPaths),从而导致权限提升、信息泄露。而几乎所有的微服务应用都无需 umount 操作,因此建议使用此规则限制容器内进程访问 umount 系统调用。禁用 umount 系统调用AppArmor
BPF
禁止加载内核模块

disallow-insmod
Privileged攻击者可能会在特权容器中(w/ CAP_SYS_MODULE),通过执行内核模块加载命令 insmod,向内核中注入代码。禁用 CAP_SYS_MODULEAppArmor
BPF
禁止加载 ebpf Program

disallow-load-ebpf
ALL攻击者可能会在特权容器中(w/ CAP_SYS_ADMIN & CAP_BPF),加载 ebpf Program 实现数据窃取和隐藏。

注:CAP_BPF 自 Linux 5.8 引入。
禁用 CAP_SYS_ADMIN, CAP_BPFAppArmor
BPF
禁止访问进程文件系统的根目录

disallow-access-procfs-root
ALL本策略禁止容器内进程访问进程文件系统的根目录(即 /proc/[PID]/root),防止攻击者利用共享 pid ns 的进程进行攻击。

攻击者可能会在共享了宿主机 pid ns、与其他容器共享 pid ns 的容器环境中,通过读写 /proc/*/root 来访问容器外的进程文件系统,实现信息泄露、权限提升、横向移动等攻击。
禁用 PTRACE_MODE_READ 权限AppArmor
BPF
禁止读取内核符号文件

disallow-access-kallsyms
ALL攻击者可能会在特权容器中(w/ CAP_SYSLOG),通过读取内核符号文件来获取内核模块地址。从而绕过 KASLR 防护,降低内核漏洞的难度与成本。禁止读取 /proc/kallsyms 文件AppArmor
BPF
禁用 capabilities禁用所有 capabilities

disable-cap-all
ALL禁用所有 capabilities-AppArmor
BPF
禁用除 net_bind_service 外的 capabilities

disable-cap-all-except-net-bind-service
ALL禁用除 net-bind-service 以外的 capabilities.

此规则符合 Pod Security Standards 的 Restricted Policy 要求。
-AppArmor
BPF
禁用特权 capability

disable-cap-privileged
ALL禁用所有的特权 capabilities(可直接造成逃逸、影响宿主机可用性的 capabilities),仅允许运行时的默认 capabilities

此规则符合 Pod Security Standards 的 Baseline Policy 要求,但 net_raw capability 除外。
-AppArmor
BPF
禁用任意 capability

disable-cap-XXXX
ALL禁用任意指定的 capabilities,请将 XXXX 替换为 man capabilities 中的值,例如 disable-cap-net-raw-AppArmor
BPF
阻断部分内核漏洞利用向量禁止滥用 User Namespace

disallow-abuse-user-ns
ALLUser Namespace 可以被用于增强容器隔离性。但它的出现同时也增大了内核的攻击面,或使得某些内核漏洞更容易被利用。攻击者可以在容器内,通过创建 User Namespace 来获取全部特权,从而扩大内核攻击面。

禁止容器进程通过 User Namesapce 滥用 CAP_SYS_ADMIN 特权可用于降低内核攻击面,阻断部分内核漏洞的利用路径。
在未设置 kernel.unprivileged_userns_clone=0 或 user.max_user_namespaces=0 的系统上,可通过此规则来为容器进行加固。
限制通过 User Namespace 滥用 CAP_SYS_ADMINAppArmor
BPF
禁止创建 User Namespace

disallow-create-user-ns
ALLUser Namespace 可以被用于增强容器隔离性。但它的出现同时也增大了内核的攻击面,或使得某些内核漏洞更容易被利用。攻击者可以在容器内,通过创建 User Namespace 来获取全部特权,从而扩大内核攻击面。

禁止容器进程创建新的 User Namesapce 从而获取 CAP_SYS_ADMIN 特权可用于降低内核攻击面,阻断部分内核漏洞的利用路径。
在未设置 kernel.unprivileged_userns_clone=0 或 user.max_user_namespaces=0 的系统上,可通过此规则来为容器进行加固。
禁止创建 User NamespaceSeccomp
Attack Protection缓解信息泄露缓解 ServiceAccount 泄露

mitigate-sa-leak
ALL此规则禁止容器进程读取 ServiceAccount 相关的敏感信息,包括 token、namespace、ca 证书。避免 default SA 泄漏、错误配置的 SA 泄漏带来的安全风险,攻击者通过 RCE 漏洞获取 k8s 容器内的权限后,常倾向于通过泄漏其 SA 信息来进行进一步的渗透入侵活动。

在大部分用户场景中,并不需要使用 SA 与 API Server 进行通信。而默认情况下,k8s 会为不需要与 API Server 通信的 Pod 设置 default SA。
禁止 ServiceAccount 文件的读操作AppArmor
BPF
缓解宿主机磁盘设备号泄露

mitigate-disk-device-number-leak
ALL此规则禁止容器进程读取 /proc/[PID]/mountinfo, /proc/partitions。

攻击者可能会通过读取容器进程的挂载信息来获取宿主机磁盘设备的设备号,从而用于后续的容器逃逸。
禁止 mountinfo, partitions 的读操作AppArmor
BPF
缓解容器 overlayfs 路径泄露

mitigate-overlayfs-leak
ALL禁止读取 /proc/mounts、/proc/[PID]/mounts、/proc/[PID]/mountinfo 文件。

攻击者可能会通过获取容器进程的挂载信息来获取容器进程 rootfs 在宿主机中的 overlayfs 路径,从而用于后续的容器逃逸。
禁止 mounts, mountinfo 文件的读操作

此规则可能会影响容器内 mount 命令的部分功能
AppArmor
BPF
缓解宿主机 IP 泄露

mitigate-host-ip-leak
ALL此规则禁止容器进程读取 ARP 地址解析表(/proc/net/arp、/proc/[PID]/net/arp 等),从而获取宿主机 IP 和 Mac 地址等敏感信息

攻击者通过 RCE 漏洞获取 k8s 容器内的权限后,会尝试进一步的网络渗透攻击。因此,限制攻击者借此获取宿主机 IP、MAC 地址、网段等敏感信息,可增加攻击者进行网络渗透的难度和成本。
禁止 ARP 文件的读操作AppArmor
BPF
禁止访问云服务器的 metadata service

disallow-metadata-service
ALL此规则禁止容器进程访问云服务器的 Instance Metadata Service。包含两个本地链接保留地址:100.96.0.96 和 169.254.169.254

攻击者获取容器内的代码执行权限后,会尝试访问云服务器的 Metadata Service 来进行信息泄露。在某些场景下,攻击者可能会获取敏感信息,从而进行权限提升、横向渗透。
禁止连接 Instance Metadata Services 的 IP 地址BPF
禁止敏感操作禁止写入 /etc 目录

disable-write-etc
ALL攻击者可能会通过修改 /etc 目录中的敏感文件来实施权限提升,例如修改 /etc/bash.bashrc 等实施水坑攻击、修改 /etc/passwd 和 /etc/shadow 添加用户进行持久化、修改 nginx.conf 或 /etc/ssh/ssh_config 进行持久化等。禁止写入 /etc 目录AppArmor
BPF
禁止执行 busybox 命令

disable-busybox
ALL此规则禁止容器进程执行 busybox 命令。

某些应用服务会以 busybox, alpine 等作为基础镜像进行打包,而这些镜像一般会使用 busybox 工具箱作为基础命令行工具的可执行程序。这也给攻击者提供了很多便利,攻击者可以利用 busybox 执行命令辅助攻击。
禁止 busybox 执行

若容器内服务依赖 busybox 或相关 bash 命令,开启此策略会导致运行出错
AppArmor
BPF
禁止创建 Unix Shell

disable-shell
ALL此规则禁止容器进程创建新的 Unix shell,从而实施反弹 shell 等攻击手段。

攻击者通过 RCE 漏洞获取服务的远程代码执行权限后,通常会借助 reverse shell 获取容器内任意命令执行能力。
禁止 Unix Shell 执行

有些基础镜像会动态链接 sh 到 /bin/busybox,此情况下还需配合“禁止执行 busybox 命令”策略使用
AppArmor
BPF
禁止通过 wget 命令下载文件

disable-wget
ALL此规则通过禁止执行 wget 命令来限制文件下载。

攻击者通常会借助 wget 命令从外部下载攻击程序进行随后的攻击(驻留、权限提升、网络扫描、挖矿等)。
禁止 wget 执行

有些基础镜像会动态链接 wget 到 /bin/busybox,此情况下还需配合“禁止执行 busybox 命令”策略使用
AppArmor
BPF
禁止通过 curl 命令下载文件

disable-curl
ALL此规则禁止容器进程执行 curl 命令。

攻击者通常会借助 curl 命令发起网络访问、从外部下载攻击程序进行随后的攻击(驻留、权限提升、网络扫描、挖矿等)。
禁止 curl 执行AppArmor
BPF
禁止通过 chmod 修改文件权限

disable-chmod
ALL此规则禁止容器进程执行 chmod 命令。

当攻击者通过漏洞获取容器内的控制权后,通常会尝试下载其他攻击代码、工具到容器内实施进一步的攻击(权限提升、横向渗透、挖矿等)。在这个攻击链路中,攻击者通常会利用 chmod 命令修改文件的执行权限。
禁止 chmod 执行

有些基础镜像会动态链接 chmod 到 /bin/busybox,此情况下还需配合“禁止执行 busybox 命令”策略使用

(TODO: BPF Enforcer 增加 path_chmod hook 点)
AppArmor
BPF
禁止设置文件的可执行属性

disable-chmod-x-bit
ALL此规则禁止容器进程通过 chmod 相关系统调用修改文件权限,创建可执行文件。

当攻击者通过漏洞获取容器内的控制权后,通常会尝试下载其他攻击代码、工具到容器内实施进一步的攻击(权限提升、横向渗透、挖矿等)。在这个攻击链路中,攻击者通常会调用 chmod 相关系统调用(chmod/fchmod/fchmodat/fchmodat2),设置文件的可执行权限。
禁止通过 chmod 相关系统调用,设置文件的 execute/search 权限。Seccomp
禁止设置文件的 SUID/SGID 属性

disable-chmod-s-bit
ALL此规则禁止容器进程通过 chmod 相关系统调用修改文件属性,设置文件的 s 标记位(set-user-ID, set-group-ID)。

在某些场景下,攻击者可能会尝试调用 chmod 系列的系统调用(chmod/fchmod/fchmodat/fchmodat2),通过设置文件的 s 标记位(set-user-ID, set-group-ID)来实施权限提升攻击。
禁止通过 chmod 相关系统调用,设置文件的 set-user-ID/set-group-ID 属性。Seccomp
禁止执行 sudo、su 命令

disable-su-sudo
ALL此规则禁止容器进程执行 sudo/su 命令进行权限提升。

当容器内的进程以非 root 用户运行时,攻击者需要先提权至 root 用户进行后续攻击。而 sudo/su 命令是本地提权的常见途径之一。
禁止 sudo、su 执行

有些基础镜像会动态链接 su 到 /bin/busybox,此情况下还需配合“禁止执行 busybox 命令”策略使用
AppArmor
BPF
限制特定可执行文件-ALL此规则对 “容器信息泄漏缓解” 和 “容器敏感命令限制” 两类策略的使用场景进行了扩充,使用户可以只对容器内的特定可执行文件及其子进程进行限制。

对指定的可执行文件进行限制,实现两个目的:
1). 避免沙箱策略影响容器内应用服务的正常执行
2). 对容器内指定可执行文件进行限制,增加攻击者成本和难度。

例如,可以利用此功能对容器中的 busybox、bash、sh、curl 进行限制,阻止攻击者利用它们来执行敏感操作。与此同时,应用服务的运行则不受沙箱策略的限制,可以正常执行读取 ServiceAccount token 等敏感操作。

注:受限于 BPF LSM 的实现原理,BPF enforcer 无法提供此功能
为特定可执行文件开启沙箱限制AppArmor
Vulnerability Mitigation-缓解 cgroups & lxcfs 逃逸

cgroups-lxcfs-escape-mitigation
ALL若用户将宿主机的 cgroupfs 挂载进容器,或使用 lxcfs 为容器提供资源视图。在这两种场景下可能存在容器逃逸风险,攻击者可以在容器内改写 cgroupfs 实施容器逃逸。

此规则也可用于防御 CVE-2022-0492 漏洞利用。
AppArmor Enforcer 阻止在容器内修改:
/**/release_agent,
/**/devices/device.allow,
/**/devices/**/device.allow,
/**/devices/cgroup.procs,
/**/devices/**/cgroup.procs,
/**/devices/task,
/**/devices/**/task,

BPF Enforcer 阻止在容器内修改:
/**/release_agent
/**/devices.allow
/**/cgroup.procs
/**/devices/tasks
AppArmor
BPF
-缓解通过改写 runc 实现的容器逃逸

runc-override-mitigation
ALL本策略用于缓解通过改写宿主机 runc 从而实现容器逃逸的漏洞,例如 CVE-2019-5736禁止改写 /**/runc 文件AppArmor
BPF
-缓解利用 Dirty Pipe 漏洞实现的容器逃逸

dirty-pipe-mitigation
ALL本策略用于防御利用 CVE-2022-0847 (Dirty Pipe) 漏洞进行容器逃逸的攻击,您可以使用此规则在升级内核前对容器进行加固。

注:尽管禁用 splice 系统调用可能会对一些软件包产生问题,但对大多数合法应用来说都不会产生影响,因为这个系统调用的使用相对罕见。
禁止调用 splice syscallSeccomp
THIS_IS_A_PLACEHOLDER_PLACEHOLDE