Lion Cipher Lab

Write a custom SELinux policy module from scratch, then prove it blocks a real violation

• Cyber / Security Engineer
• Advanced
• ~80 min
• Free · no account required

Why it matters

Ninety-five percent of SELinux work is using the policy Red Hat already wrote — relabel a file, flip a boolean, move on. But the software you are actually paid to protect is often software nobody wrote policy for: an internal daemon, a vendor blob, a service your team built. Left alone, SELinux runs it in a broad, permissive domain (or unconfined_service_t) that offers almost no containment — so if it is compromised, the attacker inherits everything the service's Unix user could touch, exactly the DAC hole mandatory access control exists to close. Writing a custom Type Enforcement module is…

What you'll learn

• declaring a brand-new SELinux domain type and entrypoint type in a .te (Type Enforcement) source file
• labelling a binary with a .fc (file context) file so it runs in your new domain — and verifying it with ps -eZ
• wiring an automatic domain transition with the init_daemon_domain() refpolicy interface (the type_transition under the hood)
• building a policy module two ways: make -f /usr/share/selinux/devel/Makefile, and the raw checkmodule + semodule_package path
• loading and removing a module with semodule -i / semodule -l / semodule -r
• running a SINGLE domain permissive with semanage permissive -a instead of disabling enforcement globally
• harvesting AVC denials with ausearch and drafting rules with audit2allow — then reviewing every allow line by hand
• recognising when a denial means the POLICY is right and the ACCESS is wrong (and refusing the rule audit2allow offers)
• knowing why dontaudit rules can hide the denial you needed, and how to see them anyway
• explaining Type Enforcement vs MLS vs booleans, and why mandatory access control contains a root-level compromise that DAC cannot

Steps in this lab

1. The idea: a module is a written contract for ONE domain
2. Get a Fedora-family VM and install the policy toolchain
3. Build a tiny service that MISBEHAVES on purpose
4. Write the policy sources: greetd.te and greetd.fc
5. Build the module, load it, and LABEL the binary
6. Run the domain PERMISSIVE and harvest the real denials
7. audit2allow as a DRAFTING aid — review every line, refuse the bad one
8. Flip to enforcing and PROVE the confinement
9. The judgment: labels, TE vs MLS vs booleans, and why MAC beats DAC

Open the full interactive lab →