2024年，Ubuntu推出了一套全新的沙箱机制，旨在通过AppArmor对非特权用户命名空间和io_uring进行严格限制，从而大幅减少潜在的攻击面。此举被业内视为当前Linux系统安全防护的重要里程碑，尤其是针对以往频繁被利用的用户命名空间漏洞，设计初衷是确保不受信任应用只能运行在极其受限的环境中。然而，安全行业讲究攻防平衡，尽管机制看似坚不可摧，但研究者经过Ker nel级别的反复分析，还是发现了绕过该限制的潜在方法。本文将从Ubuntu的策略起因、AppArmor实际机制、内核补丁分析到具体的绕过技术，逐步展开详细阐述。Ubuntu自2024年以来，在非特权用户命名空间这一曾长期被攻击者用作本地提权入口的领域中，首次做出了彻底的防御升级。这个升级不仅依赖于AppArmor强制访问控制，其核心在于将所有普通进程在尝试创建用户命名空间时转入一个名为空间限制配置的专用AppArmor配置文件，该文件封禁了包括CAP_SYS_ADMIN在内的关键权限，导致诸如unshare命令无法正常执行，返回“Operation not permitted”错误。
这样的设计直接切断了攻击者以普通权限触达网络子系统漏洞的路径，曾被业界推测为让Ubuntu安全性跃升至几乎无懈可击的境地。激励更多研究者关注此机制的是2025年2月的一条Twitter线索，其中提示该新机制可能存在绕过路径。这一发现促使相关研究者迅速投身于Ubuntu内核和AppArmor实现细节的深入剖析。研究重点锁定于AppArmor如何应用和切换安全配置文件的流程，具体来说是定位到补丁代码中对用户命名空间创建权限的管理函数，比如apparmor_userns_create()和aa_profile_ns_perm()，在这里，缺省配置将默认非受限(“unconfined”)的AppArmor标签强制转换成“unprivileged_userns”标签，限制了权限。令人意外的是函数中存在硬编码配置和仍处开发中的注释（如TODO），这预示着该模块机制尚未成熟。而且，程序可以通过改变自身的AppArmor配置文件名，即更换为一个依旧处于“unconfined”状态但名称不同的Profile，来绕过默认的硬编码限制。
AppArmor的操作并非单纯的静态限制，内核为每个进程维持当前的AppArmor标签，该标签通常可以在/proc/self/attr/apparmor/current读取，但写入时必须符合严格格式才能生效。程序可以通过写入/proc/self/attr/current或/proc/self/attr/exec来改变自身执行环境中的AppArmor配置。正是利用了这一点，研究者设计了通过特定写操作将当前进程的配置切换至一个名为“opam”的unconfined profile，从而规避原始配置中对命名空间创建权限的拦截。绕过核心在于使系统误判当前进程使用了非默认的unconfined profile，从而在aa_profile_ns_perm()函数中避开“unprivileged_userns”标签的应用，成功创建新的非特权用户命名空间。绕过实验基于Ubuntu 24.10（内核版本6.11.0-14-generic），测试表明两种方式均可实现。第一种是在进程执行execve前，通过写/proc/self/attr/exec来设置切换到opam配置。
第二种是写/proc/self/attr/current实现即时切换profiles，并调用unshare配合手动映射uid/gid。因为该绕过仅在/proc/sys/kernel/apparmor_restrict_unprivileged_unconfined未启用（即为0）时生效，而Ubuntu 25.04及之后版本默认启用此项限制，故新版Ubuntu事实上免疫于该绕过方法，旧版系统则需根据官方指导禁用无需的配置更改权限。整个绕过事件经历了从2025年2月技术发现到5月向Ubuntu安全团队提交报告，然后经过一个月深度讨论确认，是Qualys等安全团队先前公开方法的一种变种实现，进一步完善了社区对该机制的理解。厂商对报告表现出高度协作态度，及时确认漏洞并提供建议。本文所介绍的绕过技术虽与用户空间层面的之前披露方法类似，但独特之处在于完全从内核层面撬开防护缺口，彰显安全研究的深度和价值。回顾AppArmor，作为Linux Security Module (LSM)的实现之一，采用强制访问控制来限制程序操作权限。
Ubuntu通过定义多种Profiles来区分受信任与非受信任应用，将限制动作自动套用到无配置的程序。unprivileged_userns profile严禁包括sys_admin能力，为创建命名空间的需求直接划定红线。深入观察AppArmor的内核钩子和文件接口如/proc/self/attr/current机制，揭示了权限变更清晰的代码执行路径，研究者基于该接口实现了进程配置切换，从而实现“假装”进程具备更高自由度的策略。值得注意的是，Ubuntu特有的内核补丁方法存在深度定制特征。它不仅仅是对原生Linux内核行为的增强，更是将安全策略和审计机制紧密绑定于LsM钩子之中，Audit事件与阻断日志双重反馈，让管理员能够实时监控非特权用户命名空间的使用尝试。如此完善设计初衷虽为钉死安全死角，但从开源和社区的角度看，仍留下了潜在的“破绽”，而这正是安全攻防较量的本质所在。
若系统管理员希望确保环境安全，可以启用/proc/sys/kernel/apparmor_restrict_unprivileged_unconfined以及审慎审核各类AppArmor profiles与其权限配置，避免无意中的绕开被恶意利用，尤其在早期Ubuntu版本中更需警惕profile切换攻击方式。总结来看，Ubuntu通过AppArmor限制非特权用户命名空间的机制体现了现代Linux发行版在安全设计上的战略进步，融合了内核安全增强与用户空间的访问控制策略。绕过该限制的案例不仅验证了安全架构的局限，也为厂商和社区敲响警钟，提示持续改进和多层次防御的重要性。对于希望深入理解Linux内核安全实现、防护技术及其绕过技巧的从业者、研究者而言，此次绕过案例无疑是一例极其珍贵的实战教材，助力提升整体安全防御能力与风险识别视角。未来，Ubuntu和其他发行版或将进一步完善对AppArmor的支持，强化对动态配置修改的管控，防止类似绕过情形再次发生，从而推动Linux生态更加稳固与安全。
