Project 9: Ansible SELinux Hardening Role

Build an Ansible role that enforces SELinux mode, booleans, and file contexts across a fleet.

Quick Reference

Attribute Value
Difficulty Level 2: Intermediate
Time Estimate 1-2 weeks
Main Programming Language YAML (Ansible)
Alternative Programming Languages Python
Coolness Level Level 3
Business Potential 3
Prerequisites Projects 2,4,6; Ansible basics
Key Topics SELinux modes, idempotency, automation, compliance reporting

1. Learning Objectives

By completing this project, you will:

  1. Automate SELinux mode enforcement across hosts.
  2. Apply booleans and file contexts idempotently.
  3. Build audit-friendly compliance reports.
  4. Safely transition systems from permissive to enforcing.
  5. Implement rollback strategies for risky changes.

2. All Theory Needed (Per-Concept Breakdown)

SELinux Modes and System Configuration

Fundamentals

SELinux can run in enforcing, permissive, or disabled mode. Enforcing blocks unauthorized access, permissive logs denials without blocking, and disabled turns SELinux off entirely. Mode is controlled both at runtime and in configuration files. Automation must handle both: setting the runtime mode with setenforce and persisting it in /etc/selinux/config. Understanding these modes is necessary to design a safe hardening role.

Deep Dive into the concept

SELinux mode is a global system state that impacts every domain. Enforcing mode is the goal for production security because it actively blocks policy violations. Permissive mode is useful for troubleshooting and for collecting AVC denials before enabling enforcement. Disabled mode should be avoided in hardened environments because it completely removes the MAC layer. The runtime mode can be queried with getenforce and changed with setenforce. However, setenforce only affects the current boot session; persistence is configured in /etc/selinux/config by setting SELINUX=enforcing or permissive.

The transition from permissive to enforcing is risky if labeling issues or missing booleans exist. Ansible automation must therefore support a staged rollout: first verify labels and booleans, then switch to enforcing. This often involves running in permissive mode, collecting AVC logs, and generating remediation actions. The role should include checks that fail with clear messages if critical denials are present. This ensures that enforcing mode is not applied blindly.

Another nuance is that some systems can be configured per-domain permissive. semanage permissive -l lists permissive domains. Your role should detect and report these because they can mask problems even when the system is enforcing. This is especially important in compliance settings where per-domain permissive is not allowed.

The role should also consider boot-time enforcement. If SELinux is disabled at boot (selinux=0 kernel parameter), runtime changes will not work. The role should detect and report this state rather than attempting changes that will fail. This is part of safe automation: recognize when the system is not in a manageable state.

Additional operational notes on SELinux Modes and System Configuration: In real systems, this concept interacts with policy versions, distribution defaults, and local overrides. Always record the exact policy version and runtime toggles when diagnosing behavior, because the same action can be allowed on one host and denied on another. When you change configuration related to this concept, capture before/after evidence (labels, logs, and outcomes) so you can justify the change, detect regressions, and roll it back if needed. Treat every tweak as a hypothesis: change one variable, re-run the same action, and compare results against a known baseline. This makes debugging repeatable and keeps your fixes defensible.

From a design perspective, treat SELinux Modes and System Configuration as an invariant: define what success means, which data proves it, and what failure looks like. Build tooling that supports dry-run mode and deterministic fixtures so you can validate behavior without risking production. This also makes the concept teachable to others. Finally, connect the concept to security and performance trade-offs: overly broad changes reduce security signal, while overly strict changes create operational friction. Good designs surface these trade-offs explicitly so operators can make safe decisions.

Further depth on SELinux Modes and System Configuration: In production environments, this concept is shaped by policy versions, automation layers, and distro-specific defaults. To keep reasoning consistent, capture a minimal evidence bundle every time you analyze behavior: the policy name/version, the exact labels or contexts involved, the command that triggered the action, and the resulting audit event. If the same action yields different decisions on two hosts, treat that as a signal that a hidden variable changed (boolean state, module priority, label drift, or category range). This disciplined approach prevents trial-and-error debugging and makes your conclusions defensible.

Operationally, build a short checklist for SELinux Modes and System Configuration: verify prerequisites, verify labels or mappings, verify policy query results, then run the action and confirm the expected audit outcome. Track metrics that reflect stability, such as the count of denials per hour, the number of unique denial keys, or the fraction of hosts in compliance. When you must change behavior, apply the smallest change that can be verified (label fix before boolean, boolean before policy). Document the rollback path and include a post-change validation step so the system returns to a known-good state.

How this fit on projects

SELinux modes are used in §3.2 and §3.7 and are referenced in P04-selinux-boolean-manager-with-web-dashboard.md.

Definitions & key terms

  • enforcing -> SELinux actively blocks unauthorized access
  • permissive -> SELinux logs but does not block
  • disabled -> SELinux turned off
  • per-domain permissive -> exception for specific domains

Mental model diagram

config file -> boot mode -> runtime mode -> enforcement behavior

How it works (step-by-step, with invariants and failure modes)

  1. Read runtime mode with getenforce.
  2. Update /etc/selinux/config for persistence.
  3. Apply runtime change with setenforce.
  4. Verify mode and report.

Invariants: runtime mode can differ from config until reboot. Failure modes: kernel parameter disables SELinux, missing permissions.

Minimal concrete example

$ getenforce
Permissive
$ sudo setenforce 1
$ sudo sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config

Common misconceptions

  • “Changing /etc/selinux/config immediately enforces SELinux.” -> Requires reboot or setenforce.
  • “Permissive mode is safe for production.” -> It allows policy violations.

Check-your-understanding questions

  1. What is the difference between runtime and persistent mode?
  2. Why is permissive mode useful during rollouts?
  3. How do you detect per-domain permissive settings?

Check-your-understanding answers

  1. Runtime mode affects current boot; persistent mode affects future boots.
  2. It allows you to collect AVCs without breaking services.
  3. Use semanage permissive -l.

Real-world applications

  • Rolling SELinux enforcement across enterprise fleets.
  • Compliance audits requiring enforcing mode.

Where you’ll apply it

References

  • Red Hat SELinux Guide, modes section
  • “SELinux System Administration” (operations)

Key insights

Mode management is not just a toggle; it is a controlled operational process.

Summary

SELinux modes define enforcement behavior and must be managed carefully in automation.

Homework/Exercises to practice the concept

  1. Switch a system from permissive to enforcing and back.
  2. Inspect /etc/selinux/config and explain its effect.
  3. List permissive domains.

Solutions to the homework/exercises

  1. Use setenforce 1 and setenforce 0.
  2. The config sets default mode at boot.
  3. semanage permissive -l.

Idempotent SELinux Automation with Ansible

Fundamentals

Idempotency means running a configuration task multiple times results in the same state without unintended side effects. For SELinux automation, this is critical because repeated changes should not break services or rewrite policy unnecessarily. Ansible provides modules like selinux, seboolean, and sefcontext that are idempotent when used correctly. Your role should use these modules rather than raw shell commands when possible.

Deep Dive into the concept

Ansible’s idempotent modules abstract away the command details and ensure state convergence. The selinux module can set enforcing/permissive mode and update the config file. The seboolean module sets booleans with persistence options and checks current state before changing. The sefcontext module adds or modifies file context rules, while restorecon is used to apply them. This pattern keeps playbooks clean and safe.

Idempotency also involves careful ordering. For example, you must define file context rules before running restorecon, otherwise the labels will revert to defaults. Similarly, you should ensure booleans are set before enabling enforcing mode to avoid immediate denials. The role should include a verification step at the end to confirm the desired state and report any deviations. This is also useful for compliance: you can output a machine-readable report that indicates whether a host is compliant.

Another aspect is handling errors gracefully. If a host is not SELinux-enabled, the role should fail early with a clear message rather than half-configuring state. Use Ansible’s failed_when and changed_when to control task behavior. For example, you might treat an inability to set a boolean as a failure, because it indicates a misconfigured system.

Finally, idempotency supports safe rollback. If the role is applied and something breaks, you should be able to rerun the role with a previous configuration (e.g., permissive mode or default booleans) and restore the system. This means the role should be configurable via variables and should document how to rollback. This is a real-world requirement for production automation.

Operational expansion for Idempotent SELinux Automation with Ansible: In real systems, the behavior you observe is the product of policy, labels, and runtime state. That means your investigation workflow must be repeatable. Start by documenting the exact inputs (contexts, paths, users, domains, ports, and the action attempted) and the exact outputs (audit events, error codes, and any policy query results). Then, replay the same action after each change so you can attribute cause and effect. When the concept touches multiple subsystems, isolate variables: change one label, one boolean, or one rule at a time. This reduces confusion and prevents accidental privilege creep. Use staging environments or fixtures to test fixes before deploying them widely, and always keep a rollback path ready.

To deepen understanding, connect Idempotent SELinux Automation with Ansible to adjacent concepts: how it affects policy decisions, how it appears in logs, and how it changes operational risk. Build small verification scripts that assert the expected outcome and fail loudly if the outcome diverges. Over time, these scripts become a regression suite for your SELinux posture. Finally, treat the concept as documentation-worthy: write down the invariants it guarantees, the constraints it imposes, and the exact evidence that proves it works. This makes future debugging faster and creates a shared mental model for teams.

Supplemental note for Idempotent SELinux Automation with Ansible: ensure your documentation includes a minimal reproducible example and a known-good output snapshot. Pair this with a small checklist of preconditions and postconditions so anyone rerunning the exercise can validate the result quickly. This turns the concept into a repeatable experiment rather than a one-off intuition.

How this fit on projects

SELinux modes are used in §3.2 and §3.7 and are referenced in P04-selinux-boolean-manager-with-web-dashboard.md.

Further depth on he config sets default mode at boot.: In production environments, this concept is shaped by policy versions, automation layers, and distro-specific defaults. To keep reasoning consistent, capture a minimal evidence bundle every time you analyze behavior: the policy name/version, the exact labels or contexts involved, the command that triggered the action, and the resulting audit event. If the same action yields different decisions on two hosts, treat that as a signal that a hidden variable changed (boolean state, module priority, label drift, or category range). This disciplined approach prevents trial-and-error debugging and makes your conclusions defensible.

Operationally, build a short checklist for he config sets default mode at boot.: verify prerequisites, verify labels or mappings, verify policy query results, then run the action and confirm the expected audit outcome. Track metrics that reflect stability, such as the count of denials per hour, the number of unique denial keys, or the fraction of hosts in compliance. When you must change behavior, apply the smallest change that can be verified (label fix before boolean, boolean before policy). Document the rollback path and include a post-change validation step so the system returns to a known-good state.

Final depth note on Idempotent SELinux Automation with Ansible: tie the concept back to verification. Define a single, repeatable action that proves the rule works, and capture the exact artifact that proves it (a log line, a label comparison, or a policy query). If the proof changes between runs, treat that as a defect in the workflow, not a mystery. This habit prevents subtle regressions and makes audits far easier.

Definitions & key terms

  • enforcing -> SELinux actively blocks unauthorized access
  • permissive -> SELinux logs but does not block
  • disabled -> SELinux turned off
  • per-domain permissive -> exception for specific domains

Mental model diagram

config file -> boot mode -> runtime mode -> enforcement behavior

How it works (step-by-step, with invariants and failure modes)

  1. Read runtime mode with getenforce.
  2. Update /etc/selinux/config for persistence.
  3. Apply runtime change with setenforce.
  4. Verify mode and report.

Invariants: runtime mode can differ from config until reboot. Failure modes: kernel parameter disables SELinux, missing permissions.

Minimal concrete example

$ getenforce
Permissive
$ sudo setenforce 1
$ sudo sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config

Common misconceptions

  • “Changing /etc/selinux/config immediately enforces SELinux.” -> Requires reboot or setenforce.
  • “Permissive mode is safe for production.” -> It allows policy violations.

Check-your-understanding questions

  1. What is the difference between runtime and persistent mode?
  2. Why is permissive mode useful during rollouts?
  3. How do you detect per-domain permissive settings?

Check-your-understanding answers

  1. Runtime mode affects current boot; persistent mode affects future boots.
  2. It allows you to collect AVCs without breaking services.
  3. Use semanage permissive -l.

Real-world applications

  • Rolling SELinux enforcement across enterprise fleets.
  • Compliance audits requiring enforcing mode.

Where you’ll apply it

References

  • Red Hat SELinux Guide, modes section
  • “SELinux System Administration” (operations)

Key insights

Mode management is not just a toggle; it is a controlled operational process.

Summary

SELinux modes define enforcement behavior and must be managed carefully in automation.

Homework/Exercises to practice the concept

  1. Switch a system from permissive to enforcing and back.
  2. Inspect /etc/selinux/config and explain its effect.
  3. List permissive domains.

Solutions to the homework/exercises

  1. Use setenforce 1 and setenforce 0.
  2. The config sets default mode at boot.
  3. semanage permissive -l.

Safe Rollout and Compliance Reporting

Fundamentals

Automation must be safe. Rolling out SELinux changes across many hosts can break services if done incorrectly. A safe rollout requires staged changes, validation, and reporting. Compliance reporting provides evidence that hosts are configured correctly. Your role should produce a machine-readable report and a summary of compliance status.

Deep Dive into the concept

Safe rollout begins with classification. Not all hosts are identical, and some may not be ready for enforcing mode. Your role should support a staged approach: first run in permissive mode to collect AVCs, then fix labels and booleans, then switch to enforcing. This can be done by applying the role with different variables across stages. Use Ansible tags to run subsets of tasks (e.g., selinux_labels, selinux_booleans, selinux_mode). This allows controlled rollouts.

Compliance reporting is about generating evidence, not just applying settings. Your role should output a summary file that includes the SELinux mode, policy type, boolean states, and any detected drift. The report can be written to /var/log/selinux-hardening/report.json and shipped to a central system. This enables audits and proves that your automation did what it claimed. You can also integrate with Ansible’s assert module to enforce compliance thresholds (for example, fail if any host is not enforcing).

Rollback is critical. If enforcement breaks a service, you must be able to revert quickly. The role should include a rollback mode that sets permissive mode, disables specific booleans, or restores defaults. This requires storing the previous state or using known baseline defaults. For simplicity, you can allow the operator to provide a baseline config file that defines the rollback state.

Finally, consider safety for critical systems. A good practice is to run in permissive mode on the first pass, then require manual approval to switch to enforcing. This could be implemented as a variable like selinux_enforce_confirmed=true. This prevents accidental enforcement in production without explicit intent.

Operational expansion for sefcontext followed by restorecon`.: In real systems, the behavior you observe is the product of policy, labels, and runtime state. That means your investigation workflow must be repeatable. Start by documenting the exact inputs (contexts, paths, users, domains, ports, and the action attempted) and the exact outputs (audit events, error codes, and any policy query results). Then, replay the same action after each change so you can attribute cause and effect. When the concept touches multiple subsystems, isolate variables: change one label, one boolean, or one rule at a time. This reduces confusion and prevents accidental privilege creep. Use staging environments or fixtures to test fixes before deploying them widely, and always keep a rollback path ready.

To deepen understanding, connect sefcontext followed by restorecon`. to adjacent concepts: how it affects policy decisions, how it appears in logs, and how it changes operational risk. Build small verification scripts that assert the expected outcome and fail loudly if the outcome diverges. Over time, these scripts become a regression suite for your SELinux posture. Finally, treat the concept as documentation-worthy: write down the invariants it guarantees, the constraints it imposes, and the exact evidence that proves it works. This makes future debugging faster and creates a shared mental model for teams.

Supplemental note for : ensure your documentation includes a minimal reproducible example and a known-good output snapshot. Pair this with a small checklist of preconditions and postconditions so anyone rerunning the exercise can validate the result quickly. This turns the concept into a repeatable experiment rather than a one-off intuition.

How this fit on projects

Idempotency drives §3.2 and §5.10 Phase 2. It also informs P04-selinux-boolean-manager-with-web-dashboard.md for safe changes.

Further depth on dd a file context rule and apply it.: In production environments, this concept is shaped by policy versions, automation layers, and distro-specific defaults. To keep reasoning consistent, capture a minimal evidence bundle every time you analyze behavior: the policy name/version, the exact labels or contexts involved, the command that triggered the action, and the resulting audit event. If the same action yields different decisions on two hosts, treat that as a signal that a hidden variable changed (boolean state, module priority, label drift, or category range). This disciplined approach prevents trial-and-error debugging and makes your conclusions defensible.

Operationally, build a short checklist for dd a file context rule and apply it.: verify prerequisites, verify labels or mappings, verify policy query results, then run the action and confirm the expected audit outcome. Track metrics that reflect stability, such as the count of denials per hour, the number of unique denial keys, or the fraction of hosts in compliance. When you must change behavior, apply the smallest change that can be verified (label fix before boolean, boolean before policy). Document the rollback path and include a post-change validation step so the system returns to a known-good state.

Definitions & key terms

  • idempotency -> repeated application yields same state
  • convergence -> system reaches desired configuration
  • sefcontext -> Ansible module for file contexts
  • seboolean -> Ansible module for booleans

Mental model diagram

desired state -> Ansible tasks -> current state -> converge

How it works (step-by-step, with invariants and failure modes)

  1. Read current state (mode, booleans, file contexts).
  2. Apply changes only if state differs.
  3. Verify and report compliance.

Invariants: tasks should be safe to re-run. Failure modes: shell commands break idempotency.

Minimal concrete example

- name: Enable httpd_can_network_connect
  seboolean:
    name: httpd_can_network_connect
    state: true
    persistent: true

Common misconceptions

  • “Using shell commands is fine.” -> It makes state detection hard.
  • “Idempotency is optional.” -> It is required for safe automation.

Check-your-understanding questions

  1. Why should you prefer Ansible modules over shell commands?
  2. What is the correct order for file context changes?
  3. How can you validate convergence?

Check-your-understanding answers

  1. Modules are idempotent and expose state.
  2. Add sefcontext rules first, then run restorecon.
  3. Re-run the role and ensure no changes are reported.

Real-world applications

  • Fleet-wide enforcement of SELinux settings.
  • Compliance and audit automation.

Where you’ll apply it

References

  • Ansible documentation for SELinux modules
  • “The Linux Programming Interface” (system administration)

Key insights

Idempotency turns risky security configuration into predictable automation.

Summary

Use Ansible SELinux modules to achieve safe, repeatable configuration.

Homework/Exercises to practice the concept

  1. Write a task to set SELinux enforcing mode.
  2. Add a file context rule and apply it.
  3. Run the playbook twice and confirm no changes the second time.

Solutions to the homework/exercises

  1. Use the selinux module with state: enforcing.
  2. sefcontext followed by restorecon.
  3. Ansible should report ok with zero changes.

3. Project Specification

3.1 What You Will Build

An Ansible role named selinux_hardening that enforces SELinux mode, booleans, and file contexts across multiple hosts, with reporting.

3.2 Functional Requirements

  1. Mode Enforcement: Set runtime and persistent SELinux mode.
  2. Boolean Management: Apply required booleans with persistence.
  3. File Contexts: Define and apply custom fcontext rules.
  4. Compliance Report: Generate a per-host report file.
  5. Rollback Mode: Support safe rollback configuration.

3.3 Non-Functional Requirements

  • Idempotency: Re-running role results in no changes.
  • Safety: Staged rollout support.
  • Auditability: Reports are deterministic and timestamped.

3.4 Example Usage / Output

$ ansible-playbook selinux_hardening.yml
ok: [web-prod-01] => SELinux enforcing
ok: [web-prod-01] => httpd_can_network_connect: on
ok: [web-prod-01] => report: /var/log/selinux-hardening/report.json

3.5 Data Formats / Schemas / Protocols

Compliance report schema (v1):

{
  "host": "web-prod-01",
  "mode": "enforcing",
  "policy": "targeted",
  "booleans": {"httpd_can_network_connect": true},
  "fcontexts": ["/srv/www(/.*)? -> httpd_sys_content_t"],
  "timestamp": "2026-01-01T00:00:00Z"
}

3.6 Edge Cases

  • Host with SELinux disabled at boot
  • Missing SELinux tools
  • Services broken by enforcing mode

3.7 Real World Outcome

3.7.1 How to Run (Copy/Paste)

ansible-playbook selinux_hardening.yml -e "selinux_mode=enforcing"

3.7.2 Golden Path Demo (Deterministic)

Use a fixture inventory with two hosts and fixed boolean list; freeze timestamps in reports during tests.

3.7.3 CLI Transcript (Success and Failure)

$ ansible-playbook selinux_hardening.yml
PLAY RECAP
web-prod-01 : ok=12 changed=0
Exit code: 0

$ ansible-playbook selinux_hardening.yml -e "selinux_mode=enforcing" --limit bad-host
FAILED: SELinux disabled at boot
Exit code: 2

4. Solution Architecture

4.1 High-Level Design

Ansible Role -> SELinux Modules -> Compliance Report

4.2 Key Components

Component Responsibility Key Decisions
Role vars Define desired state Configurable per host
Tasks Apply SELinux settings Use Ansible SELinux modules
Report Produce compliance output JSON report per host
Rollback Optional baseline settings Variables for rollback

4.3 Data Structures (No Full Code)

selinux_booleans:
  httpd_can_network_connect: true

4.4 Algorithm Overview

Key Algorithm: Converge and Report

  1. Check SELinux status and tools.
  2. Apply booleans and file contexts.
  3. Set SELinux mode.
  4. Generate report.

Complexity Analysis:

  • Time: O(n) booleans + O(m) fcontext rules
  • Space: O(1)

5. Implementation Guide

5.1 Development Environment Setup

pip install ansible

5.2 Project Structure

roles/selinux_hardening/
├── tasks/main.yml
├── defaults/main.yml
├── templates/report.json.j2
└── README.md

5.3 The Core Question You’re Answering

“How do I enforce consistent SELinux policy across hundreds of hosts?”

5.4 Concepts You Must Understand First

  1. SELinux modes and persistence.
  2. Idempotent SELinux automation.
  3. Safe rollout and compliance reporting.

5.5 Questions to Guide Your Design

  1. How will you prevent breaking services when enforcing?
  2. How will you report compliance in a machine-readable way?
  3. How will you support rollback?

5.6 Thinking Exercise

Define a “safe” set of booleans for a web server and decide how to roll them back.

5.7 The Interview Questions They’ll Ask

  1. “What is idempotency and why does it matter?”
  2. “How do you safely move from permissive to enforcing?”
  3. “What does a compliance report contain?”

5.8 Hints in Layers

Hint 1: Use Ansible SELinux modules

Hint 2: Add a report at the end of the play

Hint 3: Add tags for phased rollout

5.9 Books That Will Help

Topic Book Chapter
Automation “The Linux Programming Interface” System admin sections
Operations “The Practice of System and Network Administration” Change management

5.10 Implementation Phases

Phase 1: Foundation (3-4 days)

Goals:

  • Build role skeleton and variables.

Tasks:

  1. Define defaults for mode and booleans.
  2. Implement mode tasks with selinux module.

Checkpoint: Role runs and sets mode.

Phase 2: Core Functionality (4-5 days)

Goals:

  • Add booleans and fcontext rules.

Tasks:

  1. Use seboolean and sefcontext modules.
  2. Add restorecon task.

Checkpoint: Role configures booleans and labels.

Phase 3: Polish & Edge Cases (2-3 days)

Goals:

  • Add compliance reporting and rollback.

Tasks:

  1. Generate JSON report from template.
  2. Add rollback variables and logic.

Checkpoint: Report generated and rollback works.

5.11 Key Implementation Decisions

Decision Options Recommendation Rationale
Mode change timing early vs late late avoid breaking services early
Reporting JSON vs plain text JSON machine-readable
Rollback variables vs separate role variables simpler operations

6. Testing Strategy

6.1 Test Categories

Category Purpose Examples
Unit Tests role tasks ansible-lint checks
Integration Tests run on VM verify mode and booleans
Edge Case Tests SELinux disabled fail early

6.2 Critical Test Cases

  1. Role sets enforcing and persists it.
  2. Role sets booleans idempotently.
  3. Report generated with correct data.

6.3 Test Data

inventory/test_hosts

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall Symptom Solution
Not using modules non-idempotent tasks use selinux, seboolean
Enforcing too early service outages staged rollout
Missing restorecon labels not applied run restorecon task

7.2 Debugging Strategies

  • Use ansible-playbook --check for dry runs.
  • Verify sestatus after role runs.

7.3 Performance Traps

  • Running restorecon -Rv / can be slow; target specific paths.

8. Extensions & Challenges

8.1 Beginner Extensions

  • Add CSV report output.
  • Add tag to skip mode changes.

8.2 Intermediate Extensions

  • Integrate with OpenSCAP for compliance validation.
  • Add notification hooks on noncompliance.

8.3 Advanced Extensions

  • Fleet-wide inventory of SELinux state.
  • Policy diff integration using P08 tool.

9. Real-World Connections

9.1 Industry Applications

  • Fleet hardening for enterprises.
  • Compliance reporting for audits.
  • OpenSCAP for compliance.
  • Ansible collections for SELinux.

9.3 Interview Relevance

  • Infrastructure automation and security enforcement.

10. Resources

10.1 Essential Reading

  • Red Hat SELinux Guide (administration)
  • Ansible documentation for SELinux modules

10.2 Video Resources

  • Ansible and SELinux automation talks

10.3 Tools & Documentation

  • ansible, selinux module, seboolean, sefcontext

11. Self-Assessment Checklist

11.1 Understanding

  • I can explain SELinux modes and persistence.
  • I can design idempotent SELinux tasks.
  • I can explain a safe rollout plan.

11.2 Implementation

  • Role converges with no changes on second run.
  • Reports are generated for each host.
  • Rollback path works.

11.3 Growth

  • I documented why each boolean is set.
  • I created a staged rollout playbook.

12. Submission / Completion Criteria

Minimum Viable Completion:

  • Role sets SELinux mode and one boolean.

Full Completion:

  • Role sets mode, booleans, file contexts, and report.

Excellence (Going Above & Beyond):

  • Integrates with compliance tools and notifications.

13 Additional Content Rules (Hard Requirements)

13.1 Determinism

  • Use fixed boolean lists and freeze report timestamps in tests.

13.2 Outcome Completeness

  • Provide success and failure run examples with exit codes.

13.3 Cross-Linking

  • Link to P04 and P06 for booleans and labeling.

13.4 No Placeholder Text

  • All sections are fully specified.