In this lesson, you will learn how to manage and switch between multiple SELinux policy versions using the centralized policy store architecture.
Understanding the Policy Store
Previously, we worked with policies as singular, static entities loaded into the kernel. In modern systems, SELinux uses a "policy store" architecture, which allows you to maintain multiple named policy configurations simultaneously. Think of a policy store as a versioned repository living directly on your filesystem under /sys/fs/selinux/ and managed via utilities that interact with /var/lib/selinux.
This architecture is essential for high-availability environments where you might need to test a new security policy without overwriting the production configuration, or when you need to roll back to a known stable state instantly.
Managing Stores with semanage
The policy store is managed by the semanage utility. When you run semanage, it interacts with the current active store. You can view the available policy stores on your system by inspecting the /var/lib/selinux/ directory structure.
To create a new policy store or switch between them, we use the -s (store) flag. For example, to view the modules loaded in a specific store named targeted, you would use:
semanage module -l -s targeted
By decoupling the policy from the kernel's active memory, the store architecture allows you to compile a policy into a specific store, verify its syntax and dependencies, and only then trigger a reload into the kernel. This prevents "broken" policies from locking you out of your system.
The Workflow
- Compilation: You compile your policy modules into a specific store namespace.
- Staging: The store keeps the binary representation ready for activation.
- Activation: You commit the store to the kernel.
If you ever need to perform an audit or compare configurations, you can point your management tools to different stores. This prevents the "configuration drift" that often happens when managing multiple servers, as you can treat the policy store as a portable, versionable component of your security hardening pipeline.
Key Takeaway: Policy stores decouple policy management from kernel execution, enabling safe testing, rapid rollbacks, and the simultaneous maintenance of distinct security configurations on a single system.