容器加固
这些规则对容器的权限进行限制，从而减少系统攻击面。您可以参考以下格式定义策略：
policy:
enforcer: AppArmorBPFSeccomp
mode: EnhanceProtect
enhanceProtect:
hardeningRules:
- disable-cap-net-raw
- disallow-create-user-ns
加固具有特权的容器
disallow-write-core-pattern
禁止改写 procfs 的 core_pattern。
攻击者可能会在特权容器（Privileged Container）中，通过改写 procfs core_pattern，来实施容器逃逸。或者在特权容器（w/ CAP_SYS_ADMIN）中，卸载特定挂载点后改写 procfs core_pattern，来实施容器逃逸。
禁止修改 procfs 的 core_pattern。
- AppArmor
- BPF
disallow-mount-securityfs
禁止挂载 securityfs。
攻击者可能会在特权容器（w/ CAP_SYS_ADMIN）中，以读写权限挂载新的 securityfs 并对其进行修改。
禁止挂载新的 securityfs。
- AppArmor
- BPF
disallow-mount-procfs
禁止重新挂载 procfs。
攻击者可能会在特权容器（w/ CAP_SYS_ADMIN）中，以读写权限重新挂载 procfs，然后再通过改写 core_pattern 等方式进行容器逃逸、修改系统配置。
- 禁止挂载新的 procfs。
- 禁止使用 bind, rbind, move, remount 选项重新挂载
/proc**。 - 使用 BPF enforcer 时，还将禁止卸载
/proc**。
- AppArmor
- BPF
disallow-write-release-agent
禁止改写 cgroupfs 的 release_agent。
攻击者可能会在特权容器（Privileged Container）中，通过改写 cgroupfs release_agent，来实施容器逃逸。
禁 止修改 cgroupfs 的 release_agent。
- AppArmor
- BPF
disallow-mount-cgroupfs
禁止重新挂载 cgroupfs。
攻击者可能会在特权容器（w/ CAP_SYS_ADMIN）中，以读写权限重新挂载 cgroupfs。然后再通过改写 release_agent、设备访问权限等方式进行容器逃逸、修改系统配置。 Attackers may attempt to escape from containers (w/ CAP_SYS_ADMIN) by remounting cgroupfs with read-write permissions. Subsequently, they can modify release_agent and device access permissions, among other things.
- 禁止挂载新的 cgroupfs。
- 禁止使用 bind, rbind, move, remount 选项重新挂载
/sys/fs/cgroup**。 - 禁止使用 rbind 选项重新挂载
/sys**。 - 使用 BPF enforcer 时，还将禁止卸载
/sys**。
- AppArmor
- BPF
disallow-debug-disk-device
禁止调试磁盘设备。
攻击者可能会在特权容器（Privileged Container）中，通过调试宿主机磁盘设备，从而实现宿主机文件的读写。
建议配合 disable-cap-mknod 使用，从而防止攻击者利用 mknod 创建新的设备文件，从而绕过此规则。
动态获取宿主机磁盘设备文件，并禁止在 容器内以读写权限访问。
- AppArmor
- BPF
disallow-mount-disk-device
禁止挂载宿主机磁盘设备并访问。
攻击者可能会在特权容器（Privileged Container）中，挂载宿主机磁盘设备，从而实现宿主机文件的读写。
建议配合 disable-cap-mknod 使用，从而防止攻击者利用 mknod 创建新的设备文件，从而绕过此规则。
动态获取宿主机磁盘设备文件，并禁止在容器内挂载。
- AppArmor
- BPF
disallow-mount
禁用 mount 系统调用。
MOUNT(2) 常被用于权限提升、容器逃逸等攻击。而几乎所有的微服务应用都无需 mount 操作，因此建议使用此规则限制容器内进程访问 mount 系统调用。
注：当 spec.policy.privileged 为 false 时，将默认禁用 mount() 系统调用。
禁用 mount 系统调用。
- AppArmor
- BPF
disallow-umount
禁用 umount 系统调用。
UMOUNT(2) 可被用于卸载敏感的挂载点（例如 maskedPaths），从而导致权限提升、信息泄露。而几乎所有的微服务应用都无需 umount 操作，因此建议使用此规则限制容器内进程访问 umount() 系统调用。
禁用 umount 系统调用。
- AppArmor
- BPF
disallow-insmod
禁止加载内核模块。
攻击者可能会在特权容器中（w/ CAP_SYS_MODULE），通过执行内核模块加载命令 insmod，向内核中注入代码。
禁用 CAP_SYS_MODULE。
- AppArmor
- BPF
disallow-load-bpf-prog
禁止加载除 BPF_PROG_TYPE_SOCKET_FILTER 和 BPF_PROG_TYPE_CGROUP_SKB 类型外的 eBPF 程序。
攻击者可能会在特权容器中（w/ CAP_SYS_ADMIN, CAP_BPF），加载 ebpf Program 实现数据窃取和创建 rootkit 后门。
在 Linux 5.8 之前，需要 CAP_SYS_ADMIN 才能加载除 BPF_PROG_TYPE_SOCKET_FILTER 和 BPF_PROG_TYPE_CGROUP_SKB 类型以外的 eBPF 程序。自 Linux 5.8 开始，需要 CAP_SYS_ADMIN 或 CAP_BPF 才能加载这些 eBPF 程序。与此同时，加载某些类型的 eBPF 程序还需要 CAP_NET_ADMIN 或 CAP_PERFMON。
禁用 CAP_SYS_ADMIN 和 CAP_BPF。
推荐您使用内置规则 disallow-load-all-bpf-prog 来禁止容器加载任意类型的 eBPF 程序，从而减少内核攻击面。
- AppArmor
- BPF
disallow-access-procfs-root
禁止访问进程文件系统的根目录。
本策略禁止容器内进程访问进程文件系统的根目录（即 /proc/[PID]/root），防止攻击者利用共享 pid ns 的进程进行攻击。
攻击者可能会在共享了宿主机 pid ns、与其他容器共享 pid ns 的容器环境中，通过读写 /proc/*/root 来访问容器外的进程文件系统，实现信息泄露、权限提升、横向移动等攻击。
禁用 PTRACE_MODE_READ 权限。
- AppArmor
- BPF
disallow-access-kallsyms
禁止读取内核符号文件。
攻击者可能会在特权容器中（w/ CAP_SYSLOG），通过读取内核符号文件来获取内核模块地址。从而绕过 KASLR 防护，降低内核漏洞的难度与成本。
禁止读取 /proc/kallsyms 文件。
- AppArmor
- BPF
禁用能力
disable-cap-all
禁用所有 capabilities。
禁用所有 capabilities
无
- AppArmor
- BPF
disable-cap-all-except-net-bind-service
禁用除 net_bind_service 外的 capabilities。
禁用除 net-bind-service 以外的 capabilities.
此规则符合 Pod Security Standards 的 Restricted Policy 要求。
无
- AppArmor
- BPF
disable-cap-privileged
禁用特权 capability。
禁用所有的特权 capabilities（可直接造成逃逸、影响宿主机可用性的 capabilities），仅允许运行时的默认 capabilities。
此规则符合 Pod Security Standards 的 Baseline Policy 要求，但 net_raw capability 除外。
无
- AppArmor
- BPF
disable-cap-[CAP]
禁用特定 capability。
禁用任意 指定的 capabilities，请将 [CAP] 替换为 capabilities(7) 中的值，例如 disable-cap-net-raw。
无
- AppArmor
- BPF
阻断内核漏洞利用向量
disallow-abuse-user-ns
禁止滥用 User Namespace。
User Namespace 可以被用于增强容器隔离性。但它的出现同时也增大了内核的攻击面，或使得某些内核漏洞更容易被利用。攻击者可以在容器内，通过创建 User Namespace 来获取全部特权，从而扩大内核攻击面。
禁止容器进程通过 User Namesapce 滥用 CAP_SYS_ADMIN 特权可降低内核攻击面，阻断部分内核漏洞的利用路径。在未设置 kernel.unprivileged_userns_clone=0 或 user.max_user_namespaces=0 的系统上，可通过此规则来为容器进行加固。
可参考下面的链接了解更多。
禁用 CAP_SYS_ADMIN。
- AppArmor
- BPF
disallow-create-user-ns
禁止创建 User Namespace。
User Namespace 可以被用于增强容器隔离性。但它的出现同时也增大了内核的攻击面，或使得某些内核漏洞更容易被利用。攻击者可以在容器内，通过创建 User Namespace 来获取全部特权，从而扩大内核攻击面。
禁止容器进程创建新的 User Namesapce 从而获取 CAP_SYS_ADMIN 特权可降低内核攻击面，阻断部分内核漏洞的利用路径。在未设置 kernel.unprivileged_userns_clone=0 或 user.max_user_namespaces=0 的系统上，可通过此规则来加固容器。
可参考下面的链接了解更多。
禁止创建 User Namespace。
- Seccomp
disallow-load-all-bpf-prog
禁止加载任意类型的 eBPF 程序。
攻击者无需任何特权就可以加载 BPF_PROG_TYPE_SOCKET_FILTER 或 BPF_PROG_TYPE_CGROUP_SKB 类型的 extended BPF (eBPF) 程序。因此，攻击者可以尝试使用这些类型的 eBPF 程序进行网络数据包嗅探，或利用 eBPF 验证器和 JIT 引擎的漏洞实现容器逃逸。
禁止容器进程加载 eBPF 程序可降低内核攻击面，阻断部分内核漏洞的利用路径。在未设置 kernel.unprivileged_bpf_disabled=0 的系统上，可通过此规则来加固容器。
可参考下面的链接了解更多。
禁止通过 bpf 系统调用，使用 BPF_PROG_LOAD 参数加载任意类型的 eBPF 程序。
- Seccomp
disallow-load-bpf-via-setsockopt
禁止通过 setsockopt 系统调用加载 cBPF 程序。
攻击者无需特权便可通过 setsockopt 系统调用加载 classic BPF (cBPF) 程序。
攻击者可以利用此方法进行 BPF JIT 喷射，这将是一种强大的内核漏洞利用方法。因为此方法不依赖任何 capability，也不受 kernel.unprivileged_bpf_disabled 安全开关的控制。
可参考下面的链接了解更多。
禁止通过 setsockopt 系统调用，使用 SO_ATTACH_FILTER 或 SO_ATTACH_REUSEPORT_CBPF 参数加载 cBPF 程序。
推荐您组合使用 disallow-load-all-bpf-prog 规则来禁止加载人任意类型的 eBPF 程序。
- Seccomp
disallow-userfaultfd-creation
禁止创建 userfaultfd 对象。
在 Linux 内核漏洞利用中，userfaultfd 常被攻击者滥用来操纵内存访问的时序，从而辅助实现漏洞利用（如条件竞争漏洞、UAF 漏洞）。其核心作用在于精确控制页错误（Page Fault）的处理时机，为攻击者创造可预测的漏洞触发窗口。
自 Linux 5.11 起，内核 fs/userfaultfd.c 中的全局变量 sysctl_unprivileged_userfaultfd 被初始化为 0。因此，只有当进程拥有 SYS_CAP_PTRACE 权限时才可以创建 userfaultfs 对象。
在设置了 kernel.unprivileged_userfaultfd=1 的系统上，可通过此规则来加固容器。另外，容器运行时组件的默认 Seccomp profile 也禁用了 userfaultfd 系统调用。
禁止调用 userfaultfd 系统调用。
- Seccomp