内核隔离与防御

• Landlock 基于路径的文件系统访问控制（无特权）
• seccomp-BPF 过滤系统调用，不感知路径
• 组合使用的互补与限制

Landlock 是 Linux 5.13+ 的无特权 LSM，允许进程在运行时基于"路径"声明允许访问的文件系统范围（如只读某目录、禁止访问某目录），是原生、无特权的沙箱机制，可精确控制文件访问。seccomp-BPF 是系统调用过滤器，通过 BPF 程序过滤系统调用（如禁用 openat、execve），但它不感知参数中的路径，无法按路径区分"允许读 A 目录但拒绝 B 目录"。对比：Landlock 胜在路径粒度文件访问控制，seccomp 胜在系统调用级拦截。组合使用时，Landlock 管"哪些路径可访问"，seccomp 管"哪些系统调用可用"，二者互补；但限制是 Landlock 只能限制文件系统访问，对其他资源（网络、进程）需配合 seccomp/其他 LSM；且 Landlock 规则在 exec 后是否继承需显式处理，两者叠加配置复杂度上升。

Landlock 回答"能碰哪些路径"，seccomp 回答"能调用哪些系统调用"。二者从不同维度收紧，组合能同时限制路径与调用面，但都无法覆盖网络等非文件系统资源，需配合防火墙/其他隔离。

• ptrace 附加可导致进程间注入与提权
• user namespace 的跨 ns 附加限制
• YAMA LSM（ptrace_scope）限制

ptrace 允许一个进程附加到另一个进程并读写其内存/寄存器，滥用可导致代码注入、凭证窃取与提权。收敛策略：user namespace 中，进程只能 ptrace 附加到同 namespace 或自己创建的 namespace 内的进程，跨 namespace 的附加受 uid 映射限制；YAMA LSM 通过 kernel.yama.ptrace_scope 分级限制（0=无限制，1=仅允许同 uid 的子进程或经 PR_SET_PTRACER 声明的进程，2=仅具 CAP_SYS_PTRACE 的管理员进程，3=禁止附加），默认 1 阻止跨进程随便附加；容器运行时（如 Docker 的 --security-opt seccomp）默认在 seccomp 过滤中禁用 ptrace（或限制为 ptrace_scope=1），并设置 --cap-drop ALL 等，避免容器内进程附加宿主进程。三层从"namespace 边界、内核策略、容器配置"共同收敛 ptrace 攻击面。

ptrace 是进程间任意内存访问的强大接口，收敛需从"能否跨边界附加"入手。user namespace 隔离边界、YAMA 按 uid 限制、容器 seccomp/capabilities 禁用，构成纵深。

• unprivileged_bpf_disabled 禁用无特权 eBPF
• bpf_jit_harden 缓解 JIT spraying
• 收敛 eBPF 攻击面

eBPF 子系统一直是权限提升与利用目标（如 Spectre、bpf 漏洞利用）。kernel.unprivileged_bpf_disabled 设为 1 可禁用无特权用户的 eBPF 加载（仅 root 或具备 CAP_BPF 的进程可用），直接缩小攻击面；设为 2 则永久禁用（需重启才能改）。net.core.bpf_jit_harden 开启 JIT 加固，对 eBPF JIT 生成的代码做额外加密/随机化（如禁用可执行 JIT 或对映射打乱），缓解"JIT spraying"（把 shellcode 注入 JIT 缓冲区）与针对 JIT 区域的利用。二者配合：前者控制"谁能加载 eBPF"，后者增强"已加载 eBPF 的执行安全"，在 eBPF 子系统上实施最小权限与加固。

eBPF 是内核中高风险的可执行代码入口。收敛一是"默认禁无特权加载"，二是"让 JIT 区更难以被利用"。生产环境通常两者都开启。

• io_uring 的异步 I/O 机制绕过系统调用
• 部分 io_uring 操作不经过传统 syscall 路径，绕过 seccomp
• 内核限制：io_uring 权限、disabled 参数、SYSCALL 过滤

io_uring 通过共享内存的环形队列提交/完成 I/O 请求，绝大多数操作经 io_uring_enter 处理，但部分操作（如 IORING_OP_* 在提交后由内核 worker 异步执行）不触发传统系统调用，且 io_uring 的某些 fixed-file/async 路径可不经过 seccomp 过滤器逐条检查，导致 seccomp 对"系统调用"的过滤被绕过——攻击者可用 io_uring 执行本应被 seccomp 拦截的操作。内核限制未授权使用：sysctl kernel.io_uring_disabled（1 表示禁用无特权进程创建 io_uring，io_uring_group 组成员与特权进程仍可用；2 表示对所有进程禁用创建）、kernel.io_uring_group 限制允许的组；容器运行时在 seccomp 中拦截 io_uring_setup/io_uring_enter 等系统调用；RLIMIT_NOFILE 等限制资源。

冲突本质是"seccomp 过滤系统调用，而 io_uring 把 I/O 从 syscall 路径中抽离"。因此需从"是否允许 io_uring 本身"入手，用 io_uring_disabled 与 seccomp 拦截 io_uring 相关 syscall 双管齐下。

• KILL：直接终止进程
• ERRNO：让系统调用返回错误
• TRAP：触发信号交由用户处理

seccomp-BPF 过滤器对系统调用返回不同动作：KILL（或 KILL_PROCESS）直接终止违规进程，用于"绝不允许发生"的严格场景（如容器逃逸防御）；ERRNO 让该系统调用返回指定错误码（如 EPERM），进程继续运行但调用失败，用于"禁止但允许进程存活"的场景（如禁用 execve）；TRAP 触发信号（如 SIGSYS）交由用户态处理，适合"需要感知并用信号响应"的场景；USER_NOTIF 把系统调用转发给用户态监督进程裁决（允许/拒绝/操作参数），实现"策略外判"的动态决策，适合需要细粒度控制或系统调用重定向的场景。选择依据是"违规行为是致命还是可容忍、是否需用户态介入"。

动作选择是"安全策略松紧"的体现：KILL 最严、ERRNO 温和、TRAP 触发信号、USER_NOTIF 可动态裁决。防御价值取决于场景对进程可用性的要求。

• Kernel Lockdown 的 integrity/confidentiality 模式
• Secure Boot 的度量引导与签名验证
• 对模块加载与 /dev/mem 的限制差异

Kernel Lockdown（内核锁定）是 Linux 5.4+ 的机制，提供 integrity（完整性）与 confidentiality（机密性）两种模式，限制那些通常是 root 权限但可破坏内核完整性或窃取内核数据的操作，如禁止加载未签名模块、禁止读写 /dev/mem、/dev/kmem、/proc/kcore、禁止 kexec 等。Secure Boot 是固件/UEFI 层面的度量引导，用签名验证引导链（包括内核、模块），防止未签名代码被加载，是更底层的信任起点。差异：Kernel Lockdown 是内核内策略，主要限制运行时 root 的破坏性操作（模块加载、devmem 访问）；Secure Boot 是启动时信任链验证，限制引导阶段加载的未签名内核与模块。二者常配合：Secure Boot 保证启动可信，Kernel Lockdown 在运行期限制 root 对内核的攻击面。

Kernel Lockdown 收窄"已 root 的进程能对内核做什么"，Secure Boot 保证"启动的是可信内核"。Lockdown 的 confidentiality 模式比 integrity 更严（连读取内核数据也禁止）。

• 特权模式（--privileged）与 privileged 容器的风险
• 设备节点（--device）、宿主目录挂载
• capabilities 与 LSM 策略（AppArmor/SELinux）

容器逃逸风险评审需逐项核对攻击面：特权模式——--privileged 容器禁用大部分隔离且获得全部 capabilities，风险最高，应禁止；设备节点——--device 挂载宿主设备（如 /dev/sda、/dev/kvm）可被用于读写宿主磁盘或触发驱动漏洞，应仅挂载必要的 /dev 设备；宿主目录——挂载宿主目录（如 /、/etc、/var/run/docker.sock）可读写宿主文件或控制宿主 Docker，应只挂载只读且必要路径；capabilities——授予的 capabilities 集合（如 CAP_SYS_ADMIN、CAP_NET_ADMIN）过大可逃逸，应 --cap-drop ALL 后按需增加；LSM 策略——容器是否绑定了 AppArmor/SELinux 配置文件，默认的 docker-default AppArmor 或自定义 SELinux 类型能限制容器内访问，缺失则风险升高。评审时应结合这些维度给出分级并收敛。

容器逃逸本质是"容器内进程获得宿主资源访问"。评审聚焦"是否获得了超容器的权限/资源"，特权、设备、宿主挂载、宽 capabilities 与 LSM 缺失都是放大攻击面的关键点。

• Spectre v1/v2 的机制与缓解措施
• IBRS/STIBP/retpoline/LFENCE 的作用
• 云厂商默认开启与性能影响

Spectre 是侧信道漏洞，利用 CPU 乱序执行与分支预测泄露数据。缓解：retpoline（用返回指令替代间接跳转，避免分支预测被污染）针对 Spectre v2，编译期启用，性能影响通常较小；IBRS（Indirect Branch Restricted Speculation）在特权级切换时限制间接分支推测，系统级加固，开销较大；STIBP 限制 SMT（超线程）兄弟核的分支预测，针对跨超线程攻击，有性能开销；LFENCE 作为内存屏障插入敏感操作前，用于 Spectre v1 的特定代码（如边界检查后），软件补丁常用。云厂商镜像默认开启这些缓解（如保留 retpoline、按需打开 IBRS/STIBP），以安全性优先；代价是特定负载（如高并发、整数运算）性能下降，云厂商也提供 spectre_v2=、nosmt 等内核参数调控，在安全与性能间取舍。

缓解的核心是"消除分支预测/推测执行造成的敏感信息泄露"。retpoline 开销小被默认启用，IBRS/STIBP 开销大按需开启，云厂商默认安全优先，性能影响随负载类型而异。

• TPM 2.0 的 PCR 与引用扩展
• PCR 扩展链的度量顺序
• 远程证明的流程（quote 签名）

TPM 2.0 的 PCR（Platform Configuration Register）以"扩展"方式记录完整性度量：PCR[i] = HASH(PCR[i] || 新度量值)，形成不可逆的度量链，顺序敏感，无法擦除或伪造。引导链（固件→Bootloader→内核→initramfs）依次把各阶段度量扩展进 PCR，形成可信链。远程证明中，挑战者发起 inquiry，TPM 用受保护的密钥（EK/AK）对 PCR 值做签名（quote），生成带 nonce 的证明签章，远程方验证签名与 PCR 值是否匹配预期度量，从而确认对端运行的是可信的内核与配置。协作模式：PCR 保证"度量不可篡改"（完整性），TPM 签名保证"证明不可伪造"（真实性），引导链保证"每阶段都被度量"。

PCR 扩展链是"度量记录"，TPM 签名是"证明发布"。二者结合让远程方无需信任被证明主机，即可验证其引导/内核完整性，是可信计算与远程证明的基石。

• 各 namespace 的隔离对象
• user namespace 的 uid/gid 映射
• 映射如何影响其他 namespace 的权限

Linux namespaces 隔离不同资源：user namespace 隔离 UID/GID 与 capabilities（映射宿主 uid 到容器内 uid，容器内可"拥有"其命名空间内的 root 能力）；mount namespace 隔离挂载点视图（各 namespace 看到不同的文件系统挂载）；PID namespace 隔离进程 ID 视图（各 namespace 内从 1 开始，看不到其他 namespace 进程）；network namespace 隔离网络栈（独立的接口、路由、防火墙）。user namespace 映射影响其他 namespace 权限的原因：当进程在 user namespace 内拥有某项 capability（如 CAP_NET_ADMIN）时，它只对该映射在其 namespace 内的资源（如该 namespace 内的 network namespace）生效，不能越权作用于宿主或其他 namespace 的资源，从而把"高权限"限定在隔离边界内。这种映射是"如何把权限范围限制在 namespace 内"的关键。

namespace 是"视图隔离"，user namespace 的映射机制决定"权限在哪个范围内有效"。映射让容器内 root 只是其命名空间内的 root，无法影响宿主，这是跨 namespace 权限收敛的基础。

• namespaces 隔离视图，cgroups 限制资源
• seccomp 过滤系统调用，LSM 授权访问
• 互补关系与区别

内核隔离机制分层：namespaces 提供"视图隔离"——让进程看到独立的文件系统、进程表、网络栈、用户等资源视图，造成"看起来各不相干"；cgroups 提供"资源限制"——限制 CPU、内存、IO 等资源的使用上限，防止一个容器耗尽资源；seccomp 提供"系统调用过滤"——限制进程可调用的系统调用集合，缩小攻击面；LSM（AppArmor/SELinux）提供"访问授权"——基于强制访问控制（MAC）策略决定进程能否访问特定路径/资源。区别：namespaces/cgroups 管"隔离与限额"，seccomp/LSM 管"行为与访问的强制约束"。四者互补，共同构成容器与传统进程的隔离纵深。

namespaces 是"逻辑隔离"，cgroups 是"资源隔离"，seccomp 是"调用面收敛"，LSM 是"访问策略"。它们回答不同问题：看到什么、能用多少、能调什么、能碰什么，缺一不可。

• 模块签名验证（模块签名密钥）
• 阻止未签名/未授权模块加载
• 与 Kernel Lockdown 模式的关系

内核模块签名验证要求加载的模块带有可信密钥签名的签名（CONFIG_MODULE_SIG），内核在加载时校验签名，未签名或签名无效的模块被拒绝加载，从而防止攻击者注入恶意内核模块（rootkit）。Kernel Lockdown 的 lockdown=integrity 模式强制要求模块签名（拒绝未签名模块），且禁止修改内核（如 kexec、devmem 写入）；lockdown=confidentiality 在 integrity 基础上进一步禁止读取内核数据（如阻止读取 /proc/kcore、内核内存），防止机密泄露。关系：模块签名验证是"加载时"的单一机制，Kernel Lockdown 是"整体策略"，其中 integrity 模式把签名验证作为强制要求，confidentiality 模式再加一层数据保密。启用 Lockdown 后，未签名模块加载被严格禁止，且无法通过修改内核解除。

模块签名验证是"加载关"，Lockdown 是"系统级锁定"。integrity 强制签名并禁止改内核，confidentiality 叠加禁止读内核数据。二者协同把"内核完整性"从加载到运行全程保护。

• kptr_restrict 控制指针显示
• dmesg_restrict 限制 dmesg 读取
• kallsyms 隐藏真实地址防 KASLR 绕过

内核地址泄露会削弱 KASLR（内核地址空间随机化）的防护，攻击者可用真实地址定位内核符号与数据结构。kptr_restrict 控制内核打印指针（如 %pK）时是否显示真实地址：设为 1 仅特权进程可看，设为 2 内核地址完全隐藏（0 为无限制），从而在日志/接口中隐藏内核地址。dmesg_restrict 限制非特权用户读取 dmesg/内核日志，因为日志中可能包含敏感的地址与内核信息。/proc/kallsyms 默认对普通用户隐藏真实地址（/proc/sys/kernel/kptr_restrict 默认限制），只显示空地址，防止用户通过符号表获取内核基址来绕过 KASLR 定位攻击目标。这三者共同保护"内核地址空间的机密性"。

内核地址是 KASLR 的核心机密，泄露即削弱随机化。kptr_restrict/dmesg_restrict/kallsyms 隐藏从"日志、接口、符号表"三个路径泄露地址，任何暴露都需特权。

• MTE 的标签内存机制
• 指针与内存标签的校验
• use-after-free 与 buffer overflow 的检测原理

MTE（Memory Tagging Extension）为内存分配随机的标签（tag），并同时把标签编码进指针的高位；每次内存访问时，硬件校验指针标签与内存标签是否一致，不一致即触发 fault。检测原理：buffer overflow 时，越界访问往往落在相邻的、标签不同的内存块，指针标签与目标内存标签不匹配即被捕获；use-after-free 时，被释放的内存块标签被重新随机化（或改变），悬挂指针仍持有旧标签，访问已释放内存时标签不匹配即被检测。RISC-V 与 ARM64 都通过此类标签机制（ARM MTE、RISC-V 相关扩展）实现硬件加速的内存安全检测，用于发现 C 语言的堆越界与悬垂指针。局限是标签空间有限（如 4-bit），需配合随机分配减少碰撞误报。

MTE 用"指针标签 vs 内存标签"的硬件校验，把内存bug变成可检测的访问错误。它无法完全阻止，但能大幅提高检测率，配合标记粒度随机化降低误报。

• cgroup v2 控制资源配额
• namespace 提供视图隔离
• 二者互补不可替代

cgroup v2 是"资源控制"机制，以层级方式限制进程组的 CPU、内存、IO、PID 等资源使用上限，防止某进程耗尽资源影响他人；namespace 是"视图隔离"机制，让进程看到独立的资源视图（文件系统、进程表、网络、用户等），造成"各不相干"的假象。二者不同：cgroup 管"能占用多少资源"，namespace 管"能看到什么资源"。不能互相替代：只有 namespace 没有 cgroup，进程虽看到隔离视图却可无限占用宿主资源；只有 cgroup 没有 namespace，进程可访问宿主全部资源只是受限额度。容器需要二者配合——namespace 提供隔离，cgroup 提供限额。

cgroup 是"限额"，namespace 是"隔离"。一个管资源量，一个管可见性，功能正交，必须组合才能实现真正的容器隔离与资源管控。

• AppArmor 基于路径的 MAC
• SELinux 基于类型强制（type enforcement）
• 表达力与运维成本的取舍

AppArmor 是"基于路径"的强制访问控制（MAC），策略用路径（如 /etc/passwd、/usr/bin/foo）声明进程可访问的文件与操作，语法简单、易编写、易排障，运维成本低，适合单机与快速部署；但基于路径易被符号链接/硬链接绕过，精细度有限。SELinux 是"基于类型强制（TE）"的 MAC，为每个主体/客体分配安全标签（type），用类型间的许可规则（allow 规则）控制访问，表达力强、粒度细、能覆盖进程间通信、网络、文件等多个维度，安全模型更严格；但策略复杂、标签体系配置与排障（audit 规则、denied 日志）成本高，运维门槛高。取舍：需要强细粒度控制与安全合规选 SELinux，追求易用与快速落地选 AppArmor。

表达力与运维成本正相关。path-based 直观易维护但易绕过，type enforcement 安全但复杂。选择取决于对安全强度与运维投入的权衡。

• KASLR 随机化内核基址
• SMEP 阻止内核执行用户态代码
• SMAP 阻止内核读写用户态数据

KASLR（Kernel Address Space Layout Randomization）在启动时随机化内核代码与数据基址，使攻击者难以预测内核地址布局，增加利用难度——配合前面提到的 kptr_restrict/kallsyms 隐藏真实地址，防止被绕过。SMEP（Supervisor Mode Execution Prevention）禁止内核执行用户态页面的代码，防止攻击者把用户态 shellcode 作为"内核态跳转目标"执行（如 ROP 链跳到用户态代码）；SMAP（Supervisor Mode Access Prevention）禁止内核读写用户态页面，防止攻击者通过指针操控内核读写用户内存。三者共同缓解内核提权攻击：KASLR 增加地址不确定性，SMEP 阻断执行用户代码，SMAP 阻断访问用户数据。

这些是内核 ROP/提权利用的通用缓解：KASLR 让地址不可预测，SMEP 让"执行用户代码"失败，SMAP 让"访问用户数据"失败，配合禁用了危险的内核接口。

• PID namespace 隔离进程 ID 视图
• network namespace 隔离网络栈
• mount namespace 隔离挂载点

Linux 提供多种 namespace 隔离不同类型的资源：PID namespace 隔离进程 ID 视图，各 namespace 内进程从 1 开始编号，看不到其他 namespace 的进程；network namespace 隔离完整的网络栈（独立接口、路由表、防火墙规则、socket 可选）；mount namespace 隔离挂载点视图，各 namespace 看到不同的文件系统挂载，可实现独立文件系统感知；此外还有 user namespace（隔离 UID/GID 与 capabilities）、UTS namespace（隔离主机名）、IPC namespace（隔离进程间通信对象）、cgroup namespace（隔离 cgroup 视图）。这些 namespace 常叠加用于容器，实现多维度隔离。

namespace 是"按资源维度切分视图"的机制。PID/网络/挂载是容器最常用的三类，分别隔离进程、网络、文件系统，配合 user/UTS/IPC 等形成完整容器隔离。