Learn SELinux - History, Background & Why We Need SELinux

#Introduction

In episode 0, we set up the environment: installing SELinux userspace tools and verifying that the system runs in enforcing mode. In this episode, we'll take a break from the hands-on work and answer the most fundamental question: why does SELinux exist? Without understanding the problem it's trying to solve, you'll only memorize commands without ever understanding when and why those commands are needed.

We'll trace the birth of SELinux, understand the limitations of Linux's classic permission system (DAC), and see how Mandatory Access Control (MAC) changes the security rules of the game at the operating system level. As the saying goes, we need to understand the past so we don't repeat the same mistakes in the future.

#The Limitations of DAC: The Problem to Be Solved

Before SELinux was born, Linux relied on DAC (Discretionary Access Control) — the permission system you learned in episode 0: files have owners, and owners have the right to decide who can access them. This is called discretionary because the access decision is in the hands of the object's owner (the user), who can "grant" access to anyone at will.

The problem is that DAC has three fundamental weaknesses:

1. Permissions are only based on user and group. Whether a process can read a file is determined by the user running it. Two different processes run by the same user have exactly the same rights — even though functionally they can be very different.
2. Root has absolute power. A user with UID 0 (root) can access and do anything. All chmod rules don't apply to root. This is like giving one person the key to the whole building.
3. Programs can be exploited without restraint. If an application with loose permissions is successfully exploited, the attacker immediately gets the rights of the user running that application — often root.

The most fitting analogy: DAC is like a building door with an ID card. As long as you have a card (a valid user), you can enter any room whose door isn't locked — even rooms that have nothing to do with your job. A card in a criminal's hand works just as well.

#MAC: Mandatory Access Control

From those limitations came the concept of MAC (Mandatory Access Control). Unlike DAC, which is "discretionary" (up to the owner), MAC is "mandatory": access rules are determined by a centralized policy, not by the object's owner. File owners cannot "grant" access beyond what the policy allows.

A key principle you must remember throughout this series:

With MAC, even root is restricted by the policy.

This is a huge leap. In the MAC world, every process and every object is given a security context label. The policy determines which process-label pairs may interact with which object-label pairs. Root is just another labeled process — if the policy doesn't allow it to access something, that access will be denied, even if its UID is zero.

To make the difference between these two worlds clearer, let's compare DAC and MAC side by side:

Consider one scenario to feel the difference. Imagine a web server exploited by an attacker: in the DAC world, the web server process runs as the user www-data — once the application is exploited, the attacker can read any file www-data can read, including application config files, database credentials, and even user data if the permissions are loose. In the MAC world, that process runs in a domain labeled httpd_t — the attacker stays trapped in that domain and can't touch files labeled passwd_t or shadow_t, no matter what the file permissions are. That's the power SELinux wants to bring to Linux: limiting the damage, not just preventing the attack.

#What SELinux Is Not

Before going further, let's clear up some misconceptions that often make people afraid of SELinux:

1. SELinux is not an antivirus. It doesn't scan files or detect malware. It restricts what a process is allowed to do — including processes that are already infected.
2. SELinux is not a firewall replacement. Firewalls regulate network traffic between hosts; SELinux regulates access within a single host. Both work side by side, not as replacements for each other.
3. SELinux is not a replacement for file permissions. DAC still runs as the first layer. SELinux is the second layer that tightens things up — not a replacement for chmod and chown.
4. SELinux is not "only for secret servers". From Fedora laptops to billions of Android devices, SELinux already runs everywhere without you realizing it.

#The Birth of SELinux: NSA, Red Hat, and Kernel 2.6

SELinux is a MAC implementation for Linux developed by the National Security Agency (NSA) in collaboration with Red Hat and the Linux community. The project started in the early 2000s, with the goal of bringing defense-agency-grade security (long applied in specialized operating systems) to mainstream Linux.

Its journey in brief:

Today, SELinux is enforcing by default on RHEL, Fedora, and CentOS. On Debian, the situation is the opposite — minimal and not default (they chose AppArmor). Android itself runs SEAndroid, a SELinux variant optimized for mobile devices — so the device in your pocket every day is actually already running this technology.

As an illustration, here's a log snippet that will become very familiar to you in the troubleshooting episodes later — an example of an AVC (Access Vector Cache) denial when a process is denied:

type=AVC msg=audit(1754256000.123:456): avc: denied { read } for pid=1234 comm="nginx" name="index.html" dev="sda1" ino=5678 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file

Notice the scontext part (subject/process context) and tcontext part (target/object context): a process labeled httpd_t was denied reading a file labeled user_home_t. This is the essence of MAC — it's not who the user is, but what labels are involved. We'll dissect every part of this log in episodes 2 and 3.

#The Modern Ecosystem: Userspace 3.11

SELinux isn't just a kernel — it's a complete ecosystem that keeps evolving. By July 2026, the SELinux userspace reached version 3.11, with a set of modern tools you'll actually use every day:

• semodule — manages policy modules: installs, removes, and disables modules.
• semanage — manages runtime configuration such as filesystem label mappings, ports, and users.
• audit2allow — reads denial logs and generates policy rules that allow access — a tool we'll dive into in the following episodes.

These tools are what separate modern SELinux from its old image of being "hard and scary". With a mature userspace, managing SELinux policies today is far easier than ten years ago — and that's one of the reasons this series is worth learning from scratch.

#Common Pitfalls

1. Thinking SELinux only causes trouble and must be disabled. This is the most harmful mindset. SELinux is a defense layer proven to block thousands of real exploits — the annoying denials are actually the system protecting you.
2. Thinking SELinux replaces chmod/firewall. The three work at different layers. You still need DAC, you still need a firewall — SELinux complements, not replaces.
3. Judging SELinux from outdated experience. The image of "SELinux is hard and unusable" was born in its early era. With a modern userspace like 3.11, troubleshooting and policy management are far friendlier.
4. Not reading denials, just ignoring them. Every AVC denial contains complete information — process, labels, operation, and object class. You'll never be able to solve a security problem if you're not willing to read the data.

#Closing

In this episode 1, we've traced why SELinux was born: the limitations of DAC that only restricts based on user and group, the MAC concept that restricts everyone — including root — based on a centralized policy and context labels, the development history of NSA together with Red Hat since the early 2000s, integration into the 2.6 kernel in 2003, and the modern userspace 3.11 ecosystem used today.

The essentials to take with you:

• DAC only restricts based on user and group — and doesn't restrict root.
• MAC determines access based on context labels and a centralized policy — the object owner doesn't have full power.
• SELinux was born from the NSA and Red Hat project and entered the Linux 2.6 kernel in 2003.
• SELinux is enforcing by default on RHEL/Fedora/CentOS; minimal on Debian; SEAndroid on Android.
• AVC denials are information labeled with scontext and tcontext — not enemies, but data to be diagnosed.

This understanding of the "why" becomes the foundation for understanding the "how" of how SELinux works. In the next episode 2, we'll discuss core concepts & main architecture — dissecting Type Enforcement, unpacking the user:role:type:sensitivity security context format, understanding the role of the AVC, and the kernel LSM structure and userspace tools that make up the entire system. Stay motivated, because this is where you start truly understanding how SELinux works from the inside!