Project 10: MLS/MCS Classification Demo System

Build a demo system that enforces classification rules (no read up, no write down) with SELinux MLS/MCS labels.

Quick Reference

Attribute Value
Difficulty Level 4: Expert
Time Estimate 3-4 weeks
Main Programming Language Python
Alternative Programming Languages C, Rust
Coolness Level Level 5
Business Potential 1
Prerequisites Projects 1-5, SELinux policy familiarity, MLS-enabled system
Key Topics MLS dominance, MCS categories, SELinux users/roles, classification

1. Learning Objectives

By completing this project, you will:

  1. Explain MLS and MCS differences in SELinux.
  2. Configure SELinux users and roles for clearance levels.
  3. Label files with sensitivity levels and categories.
  4. Demonstrate no-read-up and no-write-down in practice.
  5. Build a deterministic demo tool that proves enforcement.

2. All Theory Needed (Per-Concept Breakdown)

MLS and Bell-LaPadula Model

Fundamentals

MLS (Multi-Level Security) in SELinux implements classic mandatory access control rules such as Bell-LaPadula: no read up, no write down. In MLS, each subject and object has a sensitivity level, and access decisions depend on dominance. A subject can read objects at or below its clearance, but cannot write to lower levels. This project uses MLS to demonstrate classification enforcement with real SELinux labels.

Deep Dive into the concept

Bell-LaPadula (BLP) is a model designed to protect confidentiality. It defines two core rules: the simple security property (no read up) and the *-property (no write down). SELinux MLS uses sensitivity levels like s0, s1, s2 to encode clearance. A process labeled s1 can read s0 and s1, but not s2. Conversely, it can write to s1 or higher, but not to s0. This prevents information from flowing from higher to lower classifications.

SELinux MLS extends this with categories and role constraints. The MLS policy must be enabled at system install time; the default targeted policy does not enforce MLS. That is why your project must begin with an MLS-enabled system (e.g., SELinux MLS policy on RHEL/Fedora). Once enabled, the kernel enforces MLS constraints in addition to TE rules. This means even if TE allows access, MLS may still deny it if the levels do not dominate correctly.

Understanding dominance is essential. A subject dominates an object if the subject’s level is greater than or equal to the object’s level and the subject’s category set includes the object’s category set. For MLS, level comparison is ordered (s2 dominates s1). For MCS, categories are treated as tags and often require exact match. This project focuses on MLS, so you will explicitly create users with different sensitivity levels and demonstrate the rules.

The demo tool you build should make these rules visible. For example, you can create files labeled secret_t:s2 and public_t:s0, then run read/write attempts as users mapped to different levels. The tool should interpret the result as BLP enforcement, not just a random denial. This clarity is the goal of the project.

Additional operational notes on MLS and Bell-LaPadula Model: 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 MLS and Bell-LaPadula Model 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 MLS and Bell-LaPadula Model: 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 MLS and Bell-LaPadula Model: 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

MLS rules drive §3.2 and §3.7. It prepares you for P05-container-selinux-sandbox-lab.md and P12-enterprise-selinux-security-platform.md.

Definitions & key terms

  • MLS -> Multi-Level Security
  • BLP -> Bell-LaPadula confidentiality model
  • dominance -> clearance relationship between subject and object
  • sensitivity level -> ordered security level (s0, s1, s2)

Mental model diagram

s2 (Top Secret)
  |
  v
s1 (Secret)
  |
  v
s0 (Public)

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

  1. Assign sensitivity levels to users and files.
  2. SELinux checks TE rules first.
  3. MLS dominance check applies.
  4. Access allowed only if BLP rules satisfied.

Invariants: no read up, no write down. Failure modes: MLS policy not enabled, wrong user mapping.

Minimal concrete example

$ ls -Z secret.txt
system_u:object_r:secret_t:s2 secret.txt

Common misconceptions

  • “MLS is just more labels.” -> It enforces a strict confidentiality model.
  • “If TE allows, MLS must allow.” -> MLS can deny even if TE allows.

Check-your-understanding questions

  1. What does “no read up” mean?
  2. Why can MLS deny access even if TE allows?
  3. How do you compare levels for dominance?

Check-your-understanding answers

  1. A subject cannot read objects at a higher sensitivity.
  2. MLS is an additional mandatory layer.
  3. Subject level must be >= object level and categories must dominate.

Real-world applications

  • Government and defense classification systems.
  • High-assurance multi-tenant systems.

Where you’ll apply it

References

  • “SELinux by Example” (MLS chapters)
  • BLP model references in security textbooks

Key insights

MLS is a confidentiality model enforced by SELinux labels and dominance checks.

Summary

MLS adds a mandatory confidentiality layer: no read up, no write down.

Homework/Exercises to practice the concept

  1. Label two files at different levels and test read access.
  2. Attempt a write-down and observe denial.
  3. Explain why the denial is expected.

Solutions to the homework/exercises

  1. Use chcon -l s1 and s0 on test files.
  2. Write from s1 to s0 and see denial.
  3. It violates BLP *-property.

MCS Categories and Category Dominance

Fundamentals

MCS (Multi-Category Security) uses categories to isolate workloads without full MLS sensitivity levels. It treats categories as tags, and access is allowed only when categories match or dominate. In container environments, MCS is used to separate tenants. In this project, you will use categories to simulate compartments within the same sensitivity level.

Deep Dive into the concept

MCS is a simplified form of MLS where all subjects are typically at the same sensitivity level (s0), but categories (e.g., c1, c2) are used to isolate data. A subject can access an object only if its category set includes the object’s categories. In most container policies, categories must match exactly. This makes MCS ideal for lightweight isolation between tenants without the complexity of full MLS.

To demonstrate MCS, you can assign different category sets to files and users. For example, user Alice has s0:c1, Bob has s0:c2. A file labeled s0:c1 should be accessible only by Alice. If Bob tries to read it, SELinux denies access even if TE allows. This shows that categories are a mandatory dimension of the label.

MCS is often used in containers by the runtime, which assigns random category sets. For the demo system, you should make these assignments deterministic, such as by using fixed categories c1 and c2. This allows reproducible tests and clear explanations. You should also demonstrate the difference between MLS (ordered levels) and MCS (categories). This distinction is often misunderstood and is important for real-world SELinux use.

Operational expansion for MCS Categories and Category Dominance: 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 MCS Categories and Category Dominance 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 MCS Categories and Category Dominance: 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.

Micro note for MCS Categories and Category Dominance: capture one concrete failure case alongside the success case and explain the difference in terms of the concept’s rules. This small contrast sharpens understanding and helps future readers debug faster.

How this fit on projects

MLS rules drive §3.2 and §3.7. It prepares you for P05-container-selinux-sandbox-lab.md and P12-enterprise-selinux-security-platform.md.

Further depth on rite from s1 to s0 and see denial.: 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 from s1 to s0 and see denial.: 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 MCS Categories and Category Dominance: 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

  • MLS -> Multi-Level Security
  • BLP -> Bell-LaPadula confidentiality model
  • dominance -> clearance relationship between subject and object
  • sensitivity level -> ordered security level (s0, s1, s2)

Mental model diagram

s2 (Top Secret)
  |
  v
s1 (Secret)
  |
  v
s0 (Public)

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

  1. Assign sensitivity levels to users and files.
  2. SELinux checks TE rules first.
  3. MLS dominance check applies.
  4. Access allowed only if BLP rules satisfied.

Invariants: no read up, no write down. Failure modes: MLS policy not enabled, wrong user mapping.

Minimal concrete example

$ ls -Z secret.txt
system_u:object_r:secret_t:s2 secret.txt

Common misconceptions

  • “MLS is just more labels.” -> It enforces a strict confidentiality model.
  • “If TE allows, MLS must allow.” -> MLS can deny even if TE allows.

Check-your-understanding questions

  1. What does “no read up” mean?
  2. Why can MLS deny access even if TE allows?
  3. How do you compare levels for dominance?

Check-your-understanding answers

  1. A subject cannot read objects at a higher sensitivity.
  2. MLS is an additional mandatory layer.
  3. Subject level must be >= object level and categories must dominate.

Real-world applications

  • Government and defense classification systems.
  • High-assurance multi-tenant systems.

Where you’ll apply it

References

  • “SELinux by Example” (MLS chapters)
  • BLP model references in security textbooks

Key insights

MLS is a confidentiality model enforced by SELinux labels and dominance checks.

Summary

MLS adds a mandatory confidentiality layer: no read up, no write down.

Homework/Exercises to practice the concept

  1. Label two files at different levels and test read access.
  2. Attempt a write-down and observe denial.
  3. Explain why the denial is expected.

Solutions to the homework/exercises

  1. Use chcon -l s1 and s0 on test files.
  2. Write from s1 to s0 and see denial.
  3. It violates BLP *-property.

SELinux Users, Roles, and Level Mapping

Fundamentals

SELinux users and roles define which domains and levels a user can enter. In MLS systems, user mappings control the clearance and category range. Without proper user mapping, MLS and MCS rules cannot be enforced correctly. This project requires you to set up users with different clearances, making this concept essential.

Deep Dive into the concept

SELinux introduces an additional user identity layer beyond Linux users. A Linux user is mapped to an SELinux user via semanage login. The SELinux user then has associated roles and a range of MLS levels or MCS categories. For example, you can map alice to staff_u with range s0-s1 and bob to staff_u with range s0-s2. This determines the maximum clearance each user can obtain. Roles determine which domains the user can enter, and are part of RBAC. In MLS systems, the role also constrains allowed levels.

When a user logs in, SELinux assigns a default context based on these mappings. The user can potentially switch to other roles or levels within their range using newrole or semanage. Your demo system should include explicit user mappings and login steps to ensure the correct contexts are applied. Without this, your tests may appear inconsistent.

The mapping must align with your file labels. If you label files at s2, but no user has clearance s2, then no one can access them. This might be desired for demonstration, but you should document it. Similarly, categories must be included in the user’s range, otherwise access will be denied even if the level matches. The key is to make these mappings explicit and deterministic.

Operational expansion for se semanage login -m -s staff_u with category ranges.: 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 se semanage login -m -s staff_u with category ranges. 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.

Micro note for : capture one concrete failure case alongside the success case and explain the difference in terms of the concept’s rules. This small contrast sharpens understanding and helps future readers debug faster.

How this fit on projects

MCS categories are used in §3.2 and §3.7 and relate to P05-container-selinux-sandbox-lab.md.

Further depth on ap two users to different category sets.: 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 ap two users to different category sets.: 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 : 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

  • MCS -> Multi-Category Security
  • category -> tag used for isolation
  • dominance -> category superset relationship
  • compartment -> isolated category grouping

Mental model diagram

s0:c1 (Alice) -> can read s0:c1
s0:c2 (Bob)   -> denied s0:c1

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

  1. Assign category sets to users and files.
  2. SELinux checks category dominance on access.
  3. Access allowed only if categories match or dominate.

Invariants: category mismatch results in denial. Failure modes: categories not applied, wrong user mapping.

Minimal concrete example

$ chcon -l s0:c1 secret.txt

Common misconceptions

  • “MCS is optional and can be ignored.” -> It is enforced when labels include categories.
  • “Categories are just for containers.” -> They apply to any labeled object.

Check-your-understanding questions

  1. How do categories differ from sensitivity levels?
  2. Why might an s0 user be denied access to another s0 file?
  3. What is dominance in MCS?

Check-your-understanding answers

  1. Levels are ordered; categories are tags.
  2. Because categories do not match.
  3. The subject’s category set must include the object’s categories.

Real-world applications

  • Container isolation and multi-tenant workloads.
  • Compartmentalized data access in enterprises.

Where you’ll apply it

References

  • SELinux MCS documentation
  • “SELinux by Example” (MCS sections)

Key insights

Categories enforce isolation even when sensitivity levels are equal.

Summary

MCS uses category sets to isolate data within the same sensitivity level.

Homework/Exercises to practice the concept

  1. Label two files with different categories.
  2. Map two users to different category sets.
  3. Demonstrate access denial due to category mismatch.

Solutions to the homework/exercises

  1. chcon -l s0:c1 file1 and chcon -l s0:c2 file2.
  2. Use semanage login -m -s staff_u with category ranges.
  3. Log in as each user and attempt cross-read.

3. Project Specification

3.1 What You Will Build

A CLI tool named mls-demo plus a set of labeled files and user mappings that demonstrate MLS/MCS enforcement.

3.2 Functional Requirements

  1. User Setup: Create users with different MLS ranges.
  2. File Labeling: Label files at different levels and categories.
  3. Demo CLI: Provide commands for read/write attempts.
  4. Evidence: Log results and explain enforcement.
  5. Documentation: Step-by-step lab guide.

3.3 Non-Functional Requirements

  • Determinism: Fixed levels and categories for repeatability.
  • Safety: Use test directories only.
  • Clarity: Provide explicit expected outcomes.

3.4 Example Usage / Output

$ mls-demo read --user alice --file secret.txt
Denied: no read up

3.5 Data Formats / Schemas / Protocols

Demo log schema (v1):

{
  "user": "alice",
  "action": "read",
  "file": "secret.txt",
  "result": "denied",
  "reason": "no read up"
}

3.6 Edge Cases

  • MLS policy not enabled
  • User lacks clearance range
  • Categories not applied correctly

3.7 Real World Outcome

3.7.1 How to Run (Copy/Paste)

./mls-demo setup
./mls-demo run --scenario basic

3.7.2 Golden Path Demo (Deterministic)

Use fixed categories c1 and c2 and levels s0, s1, s2 in fixtures.

3.7.3 CLI Transcript (Success and Failure)

$ ./mls-demo read --user alice --file public.txt
Allowed
Exit code: 0

$ ./mls-demo read --user alice --file secret.txt
Denied: no read up
Exit code: 1

4. Solution Architecture

4.1 High-Level Design

User mappings -> Labeled files -> Demo CLI -> Result logs

4.2 Key Components

Component Responsibility Key Decisions
User setup Map users to MLS ranges Use semanage login
Labeling Apply levels/categories Use chcon and restorecon
Demo CLI Run read/write attempts deterministic scenarios
Reporter Explain results simple JSON log

4.3 Data Structures (No Full Code)

Scenario = {
  "user": "alice",
  "action": "read",
  "file": "secret.txt",
  "expected": "denied"
}

4.4 Algorithm Overview

Key Algorithm: Enforcement Demo

  1. Switch to user context.
  2. Attempt read/write on labeled file.
  3. Capture success or denial.
  4. Print explanation.

Complexity Analysis:

  • Time: O(n) scenarios
  • Space: O(1)

5. Implementation Guide

5.1 Development Environment Setup

sudo dnf install -y selinux-policy-mls policycoreutils-python-utils

5.2 Project Structure

mls-demo/
├── mls_demo.py
├── scenarios/
├── fixtures/
└── README.md

5.3 The Core Question You’re Answering

“How does SELinux enforce mandatory classification boundaries?”

5.4 Concepts You Must Understand First

  1. MLS and Bell-LaPadula rules.
  2. MCS categories.
  3. SELinux user and role mapping.

5.5 Questions to Guide Your Design

  1. How will you make scenarios deterministic?
  2. How will you explain denials clearly?
  3. How will you ensure MLS policy is enabled?

5.6 Thinking Exercise

Design a scenario where access is allowed by TE but denied by MLS, and explain why.

5.7 The Interview Questions They’ll Ask

  1. “Explain no read up and no write down.”
  2. “What is the difference between MLS and MCS?”
  3. “How do you map Linux users to SELinux users?”

5.8 Hints in Layers

Hint 1: Start with file labeling and ls -Z

Hint 2: Add user mappings with semanage login

Hint 3: Automate tests in a script

5.9 Books That Will Help

Topic Book Chapter
MLS “SELinux by Example” MLS chapters
MAC models “Security Engineering” MAC sections

5.10 Implementation Phases

Phase 1: Foundation (1 week)

Goals:

  • Enable MLS policy and verify system state.

Tasks:

  1. Install MLS policy packages.
  2. Verify sestatus shows MLS policy.

Checkpoint: MLS policy active and ls -Z shows levels.

Phase 2: Core Functionality (1 week)

Goals:

  • Create users and labeled files.

Tasks:

  1. Map users with ranges.
  2. Label files with levels and categories.

Checkpoint: Access tests show expected denials.

Phase 3: Polish & Edge Cases (1 week)

Goals:

  • Build CLI and documentation.

Tasks:

  1. Write mls-demo CLI.
  2. Add scenario scripts and logs.

Checkpoint: Demo runs with deterministic output.

5.11 Key Implementation Decisions

Decision Options Recommendation Rationale
Policy targeted vs MLS MLS policy required for classification demo
Levels s0-s2 vs s0-s3 s0-s2 simpler demo
Categories random vs fixed fixed (c1, c2) deterministic output

6. Testing Strategy

6.1 Test Categories

Category Purpose Examples
Unit Tests scenario parsing expected outcomes
Integration Tests MLS enforcement read/write attempts
Edge Case Tests missing MLS policy fail with message

6.2 Critical Test Cases

  1. User at s0 cannot read s1 file.
  2. User at s1 cannot write s0 file.
  3. User at s1 can read s1 and s0 files.

6.3 Test Data

fixtures/public.txt
fixtures/secret.txt

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall Symptom Solution
MLS policy not enabled No level enforcement Install and enable MLS policy
Wrong user mapping Access always denied Fix semanage login range
Categories missing Unexpected access Apply categories explicitly

7.2 Debugging Strategies

  • Verify id -Z for each user.
  • Use ls -Z to confirm file labels.

7.3 Performance Traps

  • None significant; focus on correctness.

8. Extensions & Challenges

8.1 Beginner Extensions

  • Add more scenarios with different levels.
  • Add a summary table of outcomes.

8.2 Intermediate Extensions

  • Add a web UI to demonstrate classification.
  • Include role transitions in the demo.

8.3 Advanced Extensions

  • Integrate with real applications and services.
  • Add MCS and MLS side-by-side comparison mode.

9. Real-World Connections

9.1 Industry Applications

  • Classified systems and defense environments.
  • High-assurance multi-tenant systems.
  • SELinux MLS policy examples.

9.3 Interview Relevance

  • MAC models and SELinux classification.

10. Resources

10.1 Essential Reading

  • “SELinux by Example” (MLS/MCS chapters)
  • BLP model references in security texts

10.2 Video Resources

  • MLS/MCS tutorials and conference talks

10.3 Tools & Documentation

  • semanage login, chcon, restorecon, id -Z

11. Self-Assessment Checklist

11.1 Understanding

  • I can explain BLP rules and MLS enforcement.
  • I understand MCS categories and dominance.
  • I can map SELinux users to clearances.

11.2 Implementation

  • Demo scenarios are deterministic.
  • Denials match expected MLS rules.
  • Logs are clear and consistent.

11.3 Growth

  • I can explain why a denial is MLS vs TE.
  • I documented setup steps clearly.

12. Submission / Completion Criteria

Minimum Viable Completion:

  • Demonstrate no read up and no write down with labeled files.

Full Completion:

  • Provide multiple users, levels, and category scenarios.

Excellence (Going Above & Beyond):

  • Integrate with a real service or app using MLS.

13 Additional Content Rules (Hard Requirements)

13.1 Determinism

  • Use fixed levels and categories in scenarios.

13.2 Outcome Completeness

  • Provide success and failure demos with exit codes.

13.3 Cross-Linking

  • Link to P05 and P12 for related MCS and enterprise usage.

13.4 No Placeholder Text

  • All sections are fully specified.