Project 4: SELinux Boolean Manager with Web Dashboard

Build a small web dashboard to view, search, and safely toggle SELinux booleans with audit logging.

Quick Reference

Attribute Value
Difficulty Level 2: Intermediate
Time Estimate 1-2 weeks
Main Programming Language Python (Flask)
Alternative Programming Languages Go, Node.js
Coolness Level Level 3
Business Potential 2
Prerequisites Projects 1-2, basic web dev, SELinux tools
Key Topics SELinux booleans, conditional policy, audit logging, safe UI

1. Learning Objectives

By completing this project, you will:

  1. Understand SELinux booleans and how they conditionally enable policy rules.
  2. Build a secure web UI for viewing and toggling booleans.
  3. Implement audit logging and change tracking for policy operations.
  4. Safely persist boolean changes and verify their effects.
  5. Create a clear operator workflow for safe SELinux configuration.

2. All Theory Needed (Per-Concept Breakdown)

SELinux Booleans and Conditional Policy

Fundamentals

SELinux booleans are runtime switches that enable or disable parts of policy without requiring a rebuild or module reload. They are used to control optional behaviors, such as allowing httpd_t to connect to the network or letting daemons access user home directories. Booleans are preferred for operational flexibility because they represent policy-author-approved variations. Understanding how booleans map to policy rules is critical, because toggling a boolean can significantly expand the access a domain has. Your dashboard needs to list booleans, show descriptions, and toggle them safely with persistence options.

Deep Dive into the concept

Booleans are implemented in SELinux policy as conditional blocks that guard allow rules. When a boolean is on, the rules inside the conditional are active; when it is off, they are not. This design provides a structured way to enable optional features without redefining policy. Booleans are stored in the SELinux policy store and can be set temporarily or persistently. setsebool changes the runtime state; setsebool -P persists the change across reboots by writing to the policy store. The difference matters operationally: a temporary change is useful for testing, while persistent changes are for production.

The command getsebool -a lists booleans and their current values. semanage boolean -l provides descriptions, which is essential for a UI because boolean names can be cryptic. Your dashboard should combine the two sources into a single table. You should also track which booleans are already on and highlight risky booleans. Some booleans are commonly enabled in production, while others are considered high risk because they enable broader access (e.g., allowing services to access all user files). The UI should not blindly toggle booleans without context; it should show the description and allow a confirmation step.

From a policy reasoning perspective, booleans are explicit, and that is their power. They codify expected exceptions, such as allowing a web server to serve user home directories. If the boolean is off, the denial is expected; if on, the access is allowed. This means booleans are a safe alternative to custom policy rules because they preserve the policy author’s intent. However, they can still be misused. A web admin might enable a boolean to “make it work” without understanding the broader impact. Your dashboard should include a “diff” view that shows which booleans differ from defaults, making it easy to audit changes.

When designing your system, remember that boolean changes can trigger AVC cache invalidation and may affect running processes. This is usually safe, but it can change behavior instantly. That is why the dashboard should include a confirmation dialog and should log every change with timestamp, user identity, and reason. These logs are vital for compliance and troubleshooting. If a service behaves differently, you can check the dashboard logs to see if a boolean was toggled.

Additional operational notes on SELinux Booleans and Conditional Policy: 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 Booleans and Conditional Policy 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.

How this fit on projects

Booleans are used in §3.2 and §3.7. This concept is also reused in P02-avc-denial-analyzer-auto-fixer.md for remediation suggestions.

Definitions & key terms

  • boolean -> runtime policy switch
  • conditional rule -> allow rules guarded by a boolean
  • persistent change -> stored across reboots (-P)
  • default state -> boolean value in base policy

Mental model diagram

boolean OFF -> allow rules inactive
boolean ON  -> allow rules active

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

  1. Operator toggles a boolean via setsebool.
  2. SELinux updates runtime policy state.
  3. AVC cache invalidates for affected rules.
  4. Access decisions change immediately.

Invariants: boolean state applies system-wide; policy rules are deterministic given boolean values. Failure modes: changes not persistent, missing permissions to set booleans.

Minimal concrete example

$ getsebool httpd_can_network_connect
httpd_can_network_connect --> off
$ sudo setsebool -P httpd_can_network_connect on

Common misconceptions

  • “Booleans only matter at boot.” -> They change policy immediately.
  • “Temporary changes are fine for production.” -> They disappear on reboot.

Check-your-understanding questions

  1. What is the difference between setsebool and setsebool -P?
  2. Why are booleans considered safer than custom policy rules?
  3. What should a dashboard show to help safe decisions?

Check-your-understanding answers

  1. setsebool changes runtime only; -P makes it persistent.
  2. Booleans are pre-approved policy paths authored by policy maintainers.
  3. The boolean description, current value, default value, and change history.

Real-world applications

  • Enabling network access for web apps.
  • Allowing daemons to read user content in controlled scenarios.

Where you’ll apply it

References

  • Red Hat SELinux Guide, booleans section
  • “SELinux System Administration” (Vermeulen), policy tuning

Key insights

Booleans are the safe, policy-sanctioned way to toggle optional behavior.

Summary

Booleans conditionally enable policy rules and must be managed with care and auditability.

Homework/Exercises to practice the concept

  1. List booleans and identify three related to web services.
  2. Toggle a boolean temporarily and verify its effect.
  3. Compare default vs current boolean states.

Solutions to the homework/exercises

  1. Use getsebool -a | grep httpd.
  2. setsebool httpd_can_network_connect on then confirm with getsebool.
  3. Use semanage boolean -l to see defaults and compare to runtime.

Safe Change Management and Auditability

Fundamentals

Changing SELinux policy settings is a security-sensitive operation. Operators need a clear record of what changed, who changed it, and why. This is especially true in regulated environments. Your dashboard must implement audit logging for boolean changes and provide a history view. It must also include guardrails: confirmation prompts, change reason fields, and an ability to roll back changes. These practices make the tool safe for real-world use.

Deep Dive into the concept

Auditability is not an extra feature; it is a core requirement for security operations. In SELinux, booleans can have wide-reaching effects, and a change can immediately alter the security posture of a system. Your dashboard should maintain an internal audit log with fields such as timestamp, boolean name, old value, new value, user identity, and reason. This log should be stored in an append-only file or database table to prevent silent tampering. If possible, integrate with the system audit log by emitting a structured event, but for this project, a local log file is acceptable.

A good operational workflow includes a “preview” or “diff” view that shows what will change. For example, if a user selects three booleans to enable, the dashboard should show a summary of those changes before applying them. The system should also allow a dry-run mode that reports the commands that would be executed. This is aligned with infrastructure-as-code practices where changes are reviewed before being applied.

Rollback is another key part of change management. If a boolean is toggled and causes unintended access, you should be able to revert to the previous state quickly. A simple approach is to store the previous value in the audit log and provide a “revert” action on each entry. This not only speeds recovery but also reinforces good operational hygiene.

Additionally, your dashboard should be careful about permissions. Only authorized users should be able to change booleans. If the dashboard is running as a web service, it should require authentication and enforce role-based access (e.g., read-only vs admin). Logging should include the authenticated user. This is both a security requirement and a debugging tool: when issues arise, you can trace them to a specific change.

Operational expansion for Safe Change Management and Auditability: 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 Safe Change Management and Auditability 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.

How this fit on projects

Booleans are used in §3.2 and §3.7. This concept is also reused in P02-avc-denial-analyzer-auto-fixer.md for remediation suggestions.

Further depth on Safe Change Management and Auditability: 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 Safe Change Management and Auditability: 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

  • boolean -> runtime policy switch
  • conditional rule -> allow rules guarded by a boolean
  • persistent change -> stored across reboots (-P)
  • default state -> boolean value in base policy

Mental model diagram

boolean OFF -> allow rules inactive
boolean ON  -> allow rules active

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

  1. Operator toggles a boolean via setsebool.
  2. SELinux updates runtime policy state.
  3. AVC cache invalidates for affected rules.
  4. Access decisions change immediately.

Invariants: boolean state applies system-wide; policy rules are deterministic given boolean values. Failure modes: changes not persistent, missing permissions to set booleans.

Minimal concrete example

$ getsebool httpd_can_network_connect
httpd_can_network_connect --> off
$ sudo setsebool -P httpd_can_network_connect on

Common misconceptions

  • “Booleans only matter at boot.” -> They change policy immediately.
  • “Temporary changes are fine for production.” -> They disappear on reboot.

Check-your-understanding questions

  1. What is the difference between setsebool and setsebool -P?
  2. Why are booleans considered safer than custom policy rules?
  3. What should a dashboard show to help safe decisions?

Check-your-understanding answers

  1. setsebool changes runtime only; -P makes it persistent.
  2. Booleans are pre-approved policy paths authored by policy maintainers.
  3. The boolean description, current value, default value, and change history.

Real-world applications

  • Enabling network access for web apps.
  • Allowing daemons to read user content in controlled scenarios.

Where you’ll apply it

References

  • Red Hat SELinux Guide, booleans section
  • “SELinux System Administration” (Vermeulen), policy tuning

Key insights

Booleans are the safe, policy-sanctioned way to toggle optional behavior.

Summary

Booleans conditionally enable policy rules and must be managed with care and auditability.

Homework/Exercises to practice the concept

  1. List booleans and identify three related to web services.
  2. Toggle a boolean temporarily and verify its effect.
  3. Compare default vs current boolean states.

Solutions to the homework/exercises

  1. Use getsebool -a | grep httpd.
  2. setsebool httpd_can_network_connect on then confirm with getsebool.
  3. Use semanage boolean -l to see defaults and compare to runtime.

Secure Web UI for Privileged Operations

Fundamentals

A web dashboard that can change SELinux booleans is a privileged tool. It must include authentication, authorization, and protection against common web attacks. Even a simple Flask app should enforce login, use CSRF tokens for POST requests, and avoid command injection when invoking system tools. This concept ensures that your tool does not introduce new security risks.

Deep Dive into the concept

When building a web interface that runs privileged commands, the main risk is that an attacker could manipulate requests to run arbitrary commands or change security settings. The first layer of defense is authentication: only trusted users should access the dashboard. For a local-only lab, basic auth may be enough; for a production-ready tool, you should integrate with system authentication or use a reverse proxy with SSO. The second layer is authorization: read-only users should be able to view booleans but not change them. This can be implemented with simple roles stored in a configuration file.

The next layer is input validation. Boolean names should be validated against a whitelist derived from getsebool -a, not from user input. Never pass raw user input into a shell command. Use safe subprocess calls with explicit argument lists. For example, subprocess.run(["setsebool", "-P", name, value]) avoids shell injection. You should also protect against CSRF by including a token in every POST request and validating it on the server. Flask-WTF or a simple custom token stored in session can handle this.

Another security concern is logging sensitive information. Your audit log should include user IDs and boolean names, but not passwords or session tokens. If you store logs in files, ensure file permissions restrict access. The dashboard should also be cautious about error messages: do not leak stack traces or system details to unauthenticated users. Use generic error pages and log the details server-side.

Finally, consider the runtime environment. Running the dashboard as root is risky; instead, run it as an unprivileged user and use sudo with a limited sudoers rule for setsebool and getsebool. This limits the blast radius if the web app is compromised. The UI can also run locally on localhost only for this project, reducing exposure. These practices mirror real-world secure tooling patterns.

Operational expansion for rite a line to an append-only file with those fields.: 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 rite a line to an append-only file with those fields. 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.

How this fit on projects

Change management appears in §3.7 (audit logs in Real World Outcome) and §5.10 Phase 3. It also influences P12-enterprise-selinux-security-platform.md.

Further depth on rite a line to an append-only file with those fields.: 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 rite a line to an append-only file with those fields.: 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

  • audit log -> immutable record of changes
  • rollback -> restore previous state
  • dry-run -> show changes without applying
  • authorization -> permissions to execute sensitive operations

Mental model diagram

User action -> validation -> apply change -> audit log -> optional rollback

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

  1. User selects booleans and submits changes.
  2. System validates permissions and input.
  3. setsebool is executed with or without -P.
  4. Audit log entry is written.
  5. Dashboard refreshes state.

Invariants: every change is logged; only authorized users can apply changes. Failure modes: missing permissions, inconsistent state after partial failure.

Minimal concrete example

2026-01-01T00:00:00Z user=admin action=set boolean=httpd_can_network_connect old=off new=on reason="enable outbound API"

Common misconceptions

  • “Audit logs are optional.” -> They are essential for security tooling.
  • “Rollback is just re-run setsebool.” -> You need the previous state to know what to revert.

Check-your-understanding questions

  1. Why should boolean changes be logged with a reason?
  2. What information is required to support rollback?
  3. Why is read-only mode useful?

Check-your-understanding answers

  1. It provides accountability and context for security changes.
  2. Boolean name and previous value at minimum.
  3. It allows safe visibility without granting write privileges.

Real-world applications

  • Compliance audits for security controls.
  • Production operations with change review processes.

Where you’ll apply it

References

  • “Clean Architecture” (Martin), accountability and audit trails
  • Red Hat SELinux Guide, administration best practices

Key insights

A boolean manager without auditability is a liability, not a tool.

Summary

Safe operations require audit logs, rollbacks, and permissions for SELinux boolean changes.

Homework/Exercises to practice the concept

  1. Design a log schema for boolean changes.
  2. Simulate a change and write the log entry.
  3. Describe a rollback procedure for a mistaken toggle.

Solutions to the homework/exercises

  1. Use fields: timestamp, user, boolean, old, new, reason.
  2. Write a line to an append-only file with those fields.
  3. Run setsebool -P <boolean> <old> using the stored value.

3. Project Specification

3.1 What You Will Build

A small web dashboard named selbool that lists SELinux booleans, shows their descriptions and current values, allows safe toggling with confirmation, and records an audit log.

Included features:

  • Boolean list with search/filter
  • Detail view with description
  • Toggle action with persistence option
  • Audit log and rollback

Excluded features:

  • Multi-tenant support
  • Remote agent architecture

3.2 Functional Requirements

  1. List Booleans: Show name, current value, default value, description.
  2. Toggle: Allow enabling/disabling with persistence option.
  3. Audit Log: Record every change with user, timestamp, reason.
  4. Search/Filter: Filter by name or description.
  5. Security: Require login and CSRF protection.

3.3 Non-Functional Requirements

  • Security: No shell injection; restricted sudo scope.
  • Reliability: Handle partial failures and report errors.
  • Usability: Clear confirmations and rollback actions.

3.4 Example Usage / Output

Web UI:
- /login
- /booleans (list)
- /booleans/httpd_can_network_connect (detail)
- /audit (change history)

3.5 Data Formats / Schemas / Protocols

Audit log JSON (v1):

{
  "time": "2026-01-01T00:00:00Z",
  "user": "admin",
  "boolean": "httpd_can_network_connect",
  "old": "off",
  "new": "on",
  "persistent": true,
  "reason": "enable outbound API"
}

3.6 Edge Cases

  • Boolean name does not exist
  • setsebool fails due to missing sudo
  • Concurrent updates (stale UI state)

3.7 Real World Outcome

3.7.1 How to Run (Copy/Paste)

export FLASK_APP=selbool.app
export SELBOOL_CONFIG=./config.yml
flask run --host 127.0.0.1 --port 5000

3.7.2 Golden Path Demo (Deterministic)

Use fixtures for boolean list and descriptions. Run the app in “fixture mode” so the UI renders a stable dataset.

3.7.3 If Web App (screen-by-screen flow)

  • Login screen: username/password fields, login button
  • Boolean list: table with name, value, description, toggle button
  • Detail page: boolean description, default value, current value, toggle
  • Audit log: list of changes with timestamps and reason

ASCII wireframe:

+------------------------------+
| SELinux Booleans             |
| search [__________] [Go]     |
+------------------------------+
| name        | value | toggle |
| httpd_can...| off   | [ON]   |
| sshd_use... | on    | [OFF]  |
+------------------------------+

3.7.4 Error/Failure Demo

Attempt: toggle unknown_boolean
Result: 404 Not Found, message: "Boolean not found"

4. Solution Architecture

4.1 High-Level Design

Browser -> Flask UI -> Boolean Service -> SELinux tools
                         |
                         v
                    Audit Log Store

4.2 Key Components

Component Responsibility Key Decisions
Boolean Service Fetch and set booleans Use getsebool + semanage boolean
UI Layer Render pages and forms Simple server-rendered templates
Audit Log Persist changes Append-only JSONL file
Auth Layer Login and roles Local config for MVP

4.3 Data Structures (No Full Code)

Boolean = {
  "name": "httpd_can_network_connect",
  "current": True,
  "default": False,
  "description": "Allow httpd to connect to network"
}

4.4 Algorithm Overview

Key Algorithm: Toggle with Validation

  1. Validate boolean name against whitelist.
  2. Apply setsebool with or without -P.
  3. Refresh boolean list and log change.

Complexity Analysis:

  • Time: O(n) for listing booleans
  • Space: O(n) for UI list

5. Implementation Guide

5.1 Development Environment Setup

sudo dnf install -y policycoreutils-python-utils
pip install flask

5.2 Project Structure

selbool/
├── selbool/
│   ├── app.py
│   ├── auth.py
│   ├── booleans.py
│   ├── audit.py
│   └── templates/
├── config.yml
└── audit.jsonl

5.3 The Core Question You’re Answering

“How can I safely toggle SELinux booleans with accountability?”

5.4 Concepts You Must Understand First

  1. Booleans and conditional policy.
  2. Audit logging and rollback.
  3. Web UI security for privileged actions.

5.5 Questions to Guide Your Design

  1. How will you authenticate admins and protect POST requests?
  2. How will you display default vs current boolean values?
  3. How will you implement rollback?

5.6 Thinking Exercise

Pick three booleans and rank them by risk. Decide which should require extra confirmation.

5.7 The Interview Questions They’ll Ask

  1. “What is a SELinux boolean and why is it useful?”
  2. “Why do you need audit logs for boolean changes?”
  3. “How do you prevent command injection in this tool?”

5.8 Hints in Layers

Hint 1: Start with read-only list view

Hint 2: Add toggle with setsebool and confirm in UI

Hint 3: Add audit log and rollback

5.9 Books That Will Help

Topic Book Chapter
SELinux booleans “SELinux System Administration” Policy tuning
Web security “Web Application Security” CSRF and auth
Ops discipline “Clean Architecture” Change accountability

5.10 Implementation Phases

Phase 1: Foundation (3-4 days)

Goals:

  • Read and display booleans.
  • Implement authentication.

Tasks:

  1. Parse getsebool -a output.
  2. Create login and session handling.

Checkpoint: Booleans list renders for admin user.

Phase 2: Core Functionality (3-5 days)

Goals:

  • Toggle booleans safely.
  • Add audit logging.

Tasks:

  1. Implement POST endpoint with CSRF.
  2. Write JSONL audit log entries.

Checkpoint: Toggles work and audit entries recorded.

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

Goals:

  • Add rollback and diff view.
  • Handle errors gracefully.

Tasks:

  1. Add “revert” action per log entry.
  2. Display default vs current values.

Checkpoint: UI shows diff and rollback works.

5.11 Key Implementation Decisions

Decision Options Recommendation Rationale
Auth basic auth vs local login local login allows role control
Audit storage JSONL vs DB JSONL simple and append-only
Privilege model run as root vs sudo sudo with whitelist safer

6. Testing Strategy

6.1 Test Categories

Category Purpose Examples
Unit Tests Parse booleans, log entries list parser
Integration Tests Toggle flow POST /toggle
Security Tests CSRF and auth invalid token rejected

6.2 Critical Test Cases

  1. Toggle boolean with valid CSRF token succeeds.
  2. Toggle with invalid token fails and logs nothing.
  3. Audit log entries include old and new values.

6.3 Test Data

fixtures/booleans.txt
fixtures/descriptions.txt

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall Symptom Solution
Using shell=True Command injection risk Use argument list
Forgetting -P Changes lost after reboot Allow persistent toggle
No audit logs No traceability Write JSONL log entries

7.2 Debugging Strategies

  • Log all subprocess stderr for failed toggles.
  • Use fixture mode for deterministic UI tests.

7.3 Performance Traps

  • Re-running getsebool on every page render without caching.

8. Extensions & Challenges

8.1 Beginner Extensions

  • Add CSV export of boolean list.
  • Add tag filters (httpd, ssh, samba).

8.2 Intermediate Extensions

  • Add notification webhook on changes.
  • Add diff view of default vs current.

8.3 Advanced Extensions

  • Integrate with LDAP or SSO.
  • Multi-host boolean management.

9. Real-World Connections

9.1 Industry Applications

  • Admin consoles for hardening settings.
  • Compliance dashboards for security controls.
  • Cockpit (server management UI).
  • setroubleshoot (SELinux diagnostics).

9.3 Interview Relevance

  • Secure web tooling and privilege separation.
  • SELinux operational best practices.

10. Resources

10.1 Essential Reading

  • “SELinux System Administration” (booleans)
  • OWASP guidelines for web security

10.2 Video Resources

  • SELinux booleans tutorial sessions

10.3 Tools & Documentation

  • getsebool, setsebool, semanage boolean

11. Self-Assessment Checklist

11.1 Understanding

  • I can explain how booleans map to policy rules.
  • I can justify audit logging requirements.
  • I can explain the security model of the dashboard.

11.2 Implementation

  • UI supports listing and toggling booleans.
  • Audit log entries are recorded for every change.
  • CSRF and auth are enforced.

11.3 Growth

  • I can explain trade-offs between temporary and persistent toggles.
  • I documented rollback procedures.

12. Submission / Completion Criteria

Minimum Viable Completion:

  • Read-only list of booleans with search.
  • Toggle action with confirmation.

Full Completion:

  • Audit log and rollback support.
  • Authentication and CSRF protection.

Excellence (Going Above & Beyond):

  • Multi-host support and SSO integration.

13 Additional Content Rules (Hard Requirements)

13.1 Determinism

  • Provide fixture mode for stable UI snapshots.

13.2 Outcome Completeness

  • Include success and failure flows in the UI description.

13.3 Cross-Linking

  • Link to related projects and relevant sections.

13.4 No Placeholder Text

  • All content is explicit and actionable.