SELinux
SELinux(Security-Enhanced Linux)是内置于Linux内核中的一套强制访问控制(MAC)实现，由美国国家安全局(NSA)主导研发，2000 年 12 月以开源许可发布。它在传统的自主访问控制(DAC)权限检查之外，为进程、文件、套接字和端口等对象附加安全标签，并由管理员定义的安全策略逐项判定访问是否放行，即使以 root 运行的进程同样受限。该机制现已进入Linux内核主线，并在红帽企业级发行版、openEuler 与 Android 等系统中作为默认安全组件使用。
定义
SELinux是Linux内核中的一类安全模块(Linux Security Modules，LSM)，属于内核的安全子系统，核心职能是实现强制访问控制。系统内的每个进程和每类资源都被赋予一个安全标签，一次访问能否成立，除了要通过自主访问控制(DAC)所规定的所有者与权限位检查，还要再经过标签与安全策略的判定。作为LSM框架下的模块，它借助内核中的安全钩子介入访问控制，并且高度可配置、可修改。
需注意SELinux并非一种Linux发行版，而是可施加于类Unix系统的修改集合，表现形式包括内核改动与配套工具[1]。它支持以类型强制、基于角色的访问控制、多级安全等模型构建策略，因此同一套机制可承载不同强度的安全目标[2]。
原理
SELinux沿用了Flask安全架构，该架构把安全策略的判定逻辑与策略的执行机制分离开来：负责执行的一方称为对象管理器，负责决策的一方称为安全服务器[3]。在Linux上，安全服务器、访问向量缓存(AVC)与策略引擎都被并入内核，SELinux则通过LSM提供的钩子完成标记与控制。
每个主体和对象都带有一个安全上下文，通常写作$user:role:type:level$，依次对应用户身份、角色、类型与多级安全等级。策略判定实际依据类型进行：文件、目录、设备等对象被赋予类型，进程所处的类型特称为域，当某个进程试图访问对象时，内核按两者之间的允许规则逐项核对，未获明确放行的操作一律拒绝，这一思路称为默认拒绝。
为减少重复判定带来的开销，系统把已作出的允许或拒绝结论缓存在访问向量缓存中，命中缓存即可直接得出结果；若缓存中没有对应条目，请求才交由安全服务器查询策略矩阵[4]。被拒绝的访问会形成以 avc 开头的审计记录，写入系统的审计日志，供管理员据此修订策略[5]。文件的安全标签保存在扩展属性中，挂载文件系统时也可以为整个文件系统或远程共享指定上下文。
SELinux可运行在强制、宽容、禁用三种模式下：强制模式按策略拦截并记录违规；宽容模式仍加载策略并记录拒绝事件，但不真正阻止操作；禁用模式则不加载策略[2]。此外还支持把个别域单独设为宽容模式，而系统其余部分保持强制，便于逐步扩展受控范围。
发展历程
这一技术的渊源可追溯至20世纪80年代至90年代的操作系统安全研究，研究者认为自主访问控制难以应对当时日益增多的攻击，由此提出由系统统一作出访问决策的强制访问控制思路[6]。美国国家安全局与安全计算公司(Secure Computing Corporation)合作，研发基于类型强制的强制访问控制架构，先在Mach系统上做出DTMach与DTOS两个原型，随后与犹他大学的Flux研究组合作，把架构迁移到Fluke操作系统并加以增强，增强后的架构被命名为Flask[7]。
国家安全局自1999年夏季开始把Flask架构实现在Linux内核中，2000年12月22日以GPL发布首个公开版本，即安全增强型Linux[1]。在2001年的内核峰会上，该项目曾被提议并入2.5开发系列内核，但因当时对多种竞争性安全模型尚未形成共识而未获接纳，这一结果促成了Linux安全模块接口的出现[6]。SELinux随后改用LSM框架实现，并于2003年8月8日随Linux 2.6.0-test3进入内核主线[1]。
进入发行版的过程较为曲折。Fedora Core 2是最早带有SELinux的版本，但因早期策略过于严格而默认关闭；Fedora Core 3转而引入只约束面向网络服务的精简策略，这套做法后来成为红帽企业级Linux第4版的基础，SELinux在该版本中默认启用[6]。此后可加载策略模块与参考策略陆续出现，把原本单块的策略拆分为便于管理、便于按需定制的组件[8]。移动端方面，Android自4.3起引入SELinux，4.4对部分关键域实施强制，5.0及以后扩展到60多个域全面强制执行。
应用
服务器与桌面发行版是SELinux的主要落地场景。红帽企业级Linux及其衍生发行版把它作为默认安全机制，并提供目标策略与多级安全策略等不同策略供选择；openEuler同样默认启用SELinux以提升系统安全性。目标策略的设计思路是大多数用户进程不受限制，只把特定的网络服务放入独立且受约束的安全域中运行[2]。
在Android中，SELinux对所有进程实施强制访问控制，包括以root权限运行的进程，从而为应用沙箱划定额外边界，并限制系统服务之间以及应用对系统日志的访问。域级宽容模式让设备厂商可以先对新服务放开策略、再逐步收紧。
容器与虚拟化环境是另一类典型用途。以容器为基础的系统中，SELinux被用作附加控制手段，强化容器之间以及容器与宿主机之间的隔离[9]。在KVM等虚拟化平台上，它也被用于虚拟机之间的分离和宿主机保护[10]。此外，systemd可以读取调用进程与目标单元文件的标签，就启动、停止服务等操作向SELinux查询是否允许，使关键系统功能的管理动作同样受到策略约束[5]。
局限
SELinux的防护范围止于策略所覆盖的权限。若攻击者只做进程本来就被允许的事情，例如在可访问范围内读取数据，机制本身不能识别其意图，SQL注入式的越权取数即属此类；由进程崩溃或死循环造成的拒绝服务同样不在其防护之列[10]。策略若只约束部分应用，未被约束部分的访问就仍依赖应用自身的正确性，相应的安全保证随之减弱[11]。
使用门槛高、排错困难是长期存在的问题。安全策略规模庞大且概念层次繁多，安装第三方软件后往往需要改动策略，管理员面对大规模规则容易选择直接关闭SELinux；早期版本中定位策略问题尤为困难，SELinux的不少负面评价即源于此[12]。拒绝日志只说明操作被拦下，未必能指出是哪条策略导致，为此才陆续出现把审计记录转成策略的辅助工具以及分析拒绝原因、给出提示的排错工具[8]。
此外，禁用SELinux并不总能达到预期效果：在新版本内核中通过配置关闭的做法已被视为弃用，SELinux的钩子仍会在内部执行，只是不再加载策略，要彻底停用需改用内核启动参数[2]。策略与平台、厂商代码的版本还需要相互匹配，平台侧策略更新而厂商侧未同步时，可能引入兼容性问题[13]。策略一旦编写不当，也可能阻碍本应正常进行的操作，此时宽容模式与逐域调优成为常用的过渡手段[5]。
参见
参考资料
- SELinux [引用日期2026-10-29]
- Ubuntu Manpage: SELinux - selinux-utils_3.3-1build2_amd64 [引用日期2026-10-29]
- SANS Institute [引用日期2026-10-29]
- ch-selinux [引用日期2026-10-29]
- Red_Hat_Enterprise_Linux-9-Using_SELinux-zh-CN(PDF) [引用日期2026-10-29]
- Security [引用日期2026-10-29]
- iu.edu 上的网页 [引用日期2026-10-29]
- Have You Driven an SELinux Lately? [引用日期2026-10-29]
- SELinux [引用日期2026-10-29]
- このスライドの目的 [引用日期2026-10-29]
- kernel.org 上的网页 [引用日期2026-10-29]
- LSM stacking (again) [引用日期2026-10-29]
- Android 中的安全增強型 Linux | Android Open Source Project [引用日期2026-10-29]