SELinux & AppArmor — Trivia & Interesting Facts¶
Surprising, historical, and little-known facts about SELinux and AppArmor.
SELinux was originally developed by the NSA¶
The National Security Agency (NSA) developed SELinux and released it as open-source software in December 2000. It was the first major open-source contribution by a U.S. intelligence agency. The NSA's research arm had been working on mandatory access controls since the early 1990s through the Flask architecture project at the University of Utah.
Red Hat almost did not include SELinux in RHEL¶
When Red Hat considered including SELinux in RHEL 4 (released in 2005), there was significant internal debate. SELinux was notoriously difficult to configure, and engineers worried it would generate enormous support ticket volume. They included it anyway, enabled by default in Enforcing mode — a decision that made RHEL the first major commercial Linux distribution with mandatory access controls out of the box.
The most common SELinux troubleshooting step is checking if it was disabled¶
The running joke in the Linux community is that the first line of every troubleshooting guide should be "Is SELinux in Enforcing mode? Set it to Permissive and try again." Surveys have found that a significant percentage of Linux administrators disable SELinux entirely rather than learn to configure it, prompting Red Hat's Dan Walsh to author hundreds of blog posts demystifying SELinux policy.
AppArmor was created because SELinux was considered too complex¶
Immunix (later acquired by Novell) created AppArmor in 1998 as "SubDomain," specifically as a simpler alternative to the type-enforcement model used by SELinux. Instead of labeling every file and process with security contexts, AppArmor uses pathname-based access control, which is conceptually simpler but has different security properties than label-based systems.
Android uses SELinux on billions of devices¶
Starting with Android 4.3 (2013) in permissive mode and Android 5.0 (2014) in enforcing mode, SELinux runs on every Android device. This means SELinux protects more devices worldwide than any other mandatory access control system — likely over 3 billion active devices. Google's custom SELinux policy for Android is one of the largest MAC policies ever written.
SELinux has over 100,000 policy rules in a typical RHEL installation¶
A standard RHEL installation with the targeted SELinux policy contains over 100,000 allow rules governing which processes can access which resources. Writing these rules by hand would be virtually impossible; instead, they are generated from a higher-level policy language and compiled into a binary format loaded into the kernel.
The SELinux "targeted" policy was a breakthrough compromise¶
When Fedora Core 2 shipped SELinux in 2004, it used a "targeted" policy that only confined specific high-risk daemons (like httpd, named, and sshd) rather than enforcing MAC on every process. This was a pragmatic compromise — strict policy broke too many applications. The targeted approach let most user processes run unconfined while protecting the most attacked services.
Docker containers run without AppArmor or SELinux protection by default on many systems¶
While Docker supports both AppArmor and SELinux profiles, many container deployments run with default or no MAC policies. In 2019, the "Azurescape" and similar container escape vulnerabilities demonstrated that mandatory access controls were often the last line of defense preventing container breakouts from compromising the host. This led to increased adoption of custom container MAC profiles.
The Boolean system in SELinux was inspired by a microwave oven¶
Dan Walsh, Red Hat's SELinux lead, has described how SELinux Booleans — simple on/off switches that modify policy behavior without recompiling — were inspired by the idea that security configuration should be as simple as pressing buttons on a microwave. The RHEL targeted policy includes over 300 Booleans, like httpd_can_network_connect and allow_user_exec_content.