涉及开发实现 Security-Enhanced Linux®（即 SELinux，是一种实现强制访问控制的系统）的项目最初是由美国安全局 (NSA) 发起。Secure Computing Corporation (SCC) 和 MITRE 直接参与了开发，许多实验室也加入其中。该系统最初是作为一款通用访问软件，发布于 2000 年 12 月（源代码采用 GPL 许可发布）。NSA 发布了一个特殊简化版作为纪念版本。此后的十年中，SELinux 的基本架构作参与了多个半研究/半军事项目，进行了开发、分析和测试。
项目盛宴：DTMach、DTOS、Fluke、Flusk 和 Flask
在 1992–1993 年，来自 NSA 和 SCC 的研究人员致力于研究 Distributed Trusted Mach (DTMach) 操作系统，该系统结合了来自 TMach 和 LOCK 项目的研究成果。DTMach 捆绑了一种通用的类型强制、一个灵活的访问控制机制和一个 Mach 微内核。DTMach 项目随后作为 Distributed Trusted Operating System (DTOS) 项目的一部分开发。DTOS 项目结束后，NSA、SCC 和犹他大学共同将 DTOS 安全系统集成到 Fluke 研究操作系统。新的项目称为 Flux。与此同时，安全系统的初始架构得到了增强，从而能够更好地支持动态安全策略。新增强的架构称为 Flask。NSA 的下一步是对 Linux OS 使用该安全系统架构，并以 Security-Enhanced Linux 的名称向公众发布。
新的强制访问控制系统所基于的流程是查看操作系统对象和主体的安全标签，并包含许多最新的访问控制技术。其中一种技术就是类型强制 (type enforcement)。该系统最初放在一个专门设计的可信任 “A1” 级系统（称为 LOCK）中进行了测试，然后在研究操作系统 Flask 的安全子系统中进行了进一步开发。在基于 SELinux 角色的访问控制以及 Multi-Level 或 Multi-Category 具体实现中支持使用该类型强制。
类型强制
类型强制是一种访问控制技术，它允许根据当前的安全上下文或域向主体（用户、软件流程和工作流）授权以访问对象（文件、I/O 端口和其他）。
在 SELinux 中，安全上下文存储在扩展的文件系统属性中，并通过 Linux Security Module (LSM) 进行管理。类型强制用于实现强制访问控制，对基于角色的访问控制 (RBAC) 进行了补充，是实现 Multi-Level Security (MLS) 和 Multi-Category Security (MCS) 的第一步。
LOCK
SCC 的 LOCK (Logical Co-processing Kernel) 项目其目标是开发一个可信任的计算机系统，提供多级别安全性。这意味着根据可信任的计算系统评估标准（Trusted Computing System Evaluation Criteria，也称为 “Orange Book”），系统必须满足 “A1” 级别的需求。
项目成功结束后，将在军事指挥中心建立数十个系统。类型强制是 LOCK 技术的主要架构特性，确保有效地实现访问控制机制。
目前，与安全和访问控制（包括类型增强）有关的基础 LOCK 技术主要在以下系统中开发：
Sidewinder Internet Firewall 产品线 SELinux
在发布 SELinux 时，它是作为 2.2 和 2.4 内核更新发布的。然而，当出现了是否把 SELinux 包含到正式版内核中这一问题时，Linus Torvalds 要求修改项目，从而将 Linux 安全子系统实现为一个模块，为后续的维护或增强提供便利。因此，开发人员创建了 Linux Security Modules 子系统，通过一个接口为安全子系统提供内核功能。该解决方案允许 Linux 用户和开发人员从大量强制访问控制系统中进行选择：AppArmor、TOMOYO Linux、SMACK 和 SELinux。
Linux Security Modules
Linux Security Modules (LSM) 是一种 Linux 内核子系统，旨在将内核以模块形式集成到各种安全模块中。在 2001 年的 Linux Kernel 峰会上，NSA 代表建议在 Linux 内核版本 2.5 中包含强制控制访问系统 Security-Enhanced Linux。然而，Linus Torvalds 拒绝了这一提议，因为 SELinux 并不是惟一一个用于增强 Linux 安全性的安全系统。除此之外，并不是所有的开发人员都认为 SELinux 是最佳解决方案。SELinux 并没有直接包含在内核中，相反，创建了 Linux Security Modules 系统，允许安全子系统作为模块使用，这意味着可以比较方便地连接新的模块。
LSM 子系统的开发工作持续了大约三年时间，并从版本 2.6 开始，就被包含到 Linux 内核中。目前具备正式官方支持的安全模块包括 SELinux、Apparmor、Smack 和 TOMOYO Linux。
关于 LSM 架构的详细描述请参见文章 “Linux Security Modules: General Security Support for the Linux Kernel”，该文章在 2002 年的 USENIX Security 会议上发表。
SELinux 根据标签控制与强制访问控制系统建立关联。 这意味着由 SELinux 保护的操作系统中的每个对象或主体都需要一个称为 security context 的特殊标签。这些标签最初存储为数字，放在 ext2 文件系统节点中的未使用字段中。每个数字标签在 SELinux 中被映射到一个可读的基于文本的安全上下文标签中。这种方法不具备可扩展性，并且基于特定的 ext2 文件系统的特性，这被认为是整个解决方案的一个明显的瑕疵。
在开发的下一个阶段，SELinux 被实现为一个可以载入到 Linux 内核版本 2.4 的模块。该模块可以处理存储在单独文件中的标签，这意味着 SELinux 的实现对所使用的文件系统没有任何限制。然而，去掉某个架构缺陷可能会引起另一个缺陷。对包含安全上下文标签的文件进行频繁访问将导致生产力显著下降。
Linux 内核 2.6 版本的发布彻底解决了这个问题，它充分支持 Linux Security Modules 和 ext3 文件系统的扩展属性。为了能够对系统的对象和主体存储安全上下文标签，SELinux 转变为使用扩展的属性。不幸的是，这种创新对文件系统的使用提出了限制。SELinux 只能在支持扩展属性的文件系统中使用。然而，这个问题随时间而得到解决，目前几乎所有通用的文件系统都充分支持扩展属性，这意味着它们都能够使用 SELinux。
一段时间后，SELinux 被集成到 Linux 内核并开始进行发布，第一次作为内核 2.6.0-test3（2003 年 8 月 8 日发布）的子系统进行测试。作为发布的一部分，针对内核 2.2 和 2.4 发布了一个内核路径，用于强制访问控制系统，同时在内核 2.4 中引入了对 Linux Security Modules 的支持，从而导致了面向 LSM 的 SELinux 版本的开发。
SELinux 很快成为受保护 Linux 系统的事实标准，以及 Red Hat Enterprise Linux 最流行的企业发布版之一（从 Red Hat Enterprise Linux 4 开始）。此后，SELinux 开始在广泛部署的 Debian 和 Fedora 上得到应用，并获得 Ubuntu 发行版的支持，后者非常受用户欢迎（自 LTS 版本 8.04 Hardy Heron 开始）。很久之后，Novell（当时正在开发 AppArmor 并计划将其包含在 Linux 内核中）开始在其 OpenSUSE 和 SUSE Linux Enterprise 发行版中支持 SELinux。
最终，Security-Enhanced Linux 获得了所有流行版本的开发人员的支持。在当前的 Linux 内核版本 2.6 中，SELinux 使用 Linux Security Modules 执行操作。此外，许多 SELinux 元素被合并到实际内核中。
强制访问控制系统使用的冗长路径一直由美国国家安全局监管。将 SELinux 集成到 Linux 内核的基本工作也获得了 Red Hat 的支持。NSA 网站上给出了对 SELinux 开发贡献最大的开发人员的完整列表。