Linux Security / Basic: identity, resources, and evidence / Lesson 1

Define Linux security boundaries and outcomes

Connect a workload’s purpose to the authority, data, and evidence that should constrain it.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Separate an application permission from a kernel-enforced boundary.
State a protected outcome and the evidence needed to support it.

Begin with what the workload must protect

A fictional report worker reads public workshop schedules and writes derived summaries. It does not need attendee contact data, account management, or arbitrary host configuration changes. Start with that purpose before selecting hardening flags. The protected outcome is narrow access to required inputs and outputs, with unrelated data and administration outside its authority. A successful report does not prove the boundary held; a compromised or faulty worker could still have read too much. Describe both useful allowed behavior and forbidden effects so later verification can distinguish security from simply preventing all work.

Name the enforcement layer for each rule

Linux security involves process credentials, discretionary permissions, capabilities, mandatory policies, namespaces, service management, network controls, and application logic. These layers answer different questions and can depend on shared kernel and administrator trust. A directory mode does not establish application ownership policy, while an application role does not constrain every system call a process can make. The planning record separates these claims. It is fictional non-runnable data, not a system configuration or assessment of this host. Actual feature support and enforcement depend on kernel, distribution, runtime, and enabled policy.

json A fictional workload boundary record

{"workload":"report-worker-lab","allowed":["read-public-schedules","write-derived-summaries"],"excluded":["attendee-contacts","account-management","host-administration"],"claims":{"application":"workshop-scope","operatingSystem":"reviewed-resource-boundaries"},"actualHostAssessed":false}

The non-runnable record assigns no permissions and configures no service. Its exclusions are requirements rather than verified host restrictions. No real account, path, process, or operating-system state is inspected.

Model required authority before granting more

An authority inventory can compare required operations with proposed grants. The first local calculation identifies an unnecessary administration capability in a fictional proposal. It does not inspect Linux capabilities or decide a real service’s needs. A useful review asks why each grant exists, what input can influence it, and which protected resource it reaches. Broad convenience grants increase the effects of a defect. Conversely, removing a needed operation without understanding the workflow can break legitimate work. Keep the actual requirement and the proposed mechanism separate so the choice remains reviewable.

python Compare synthetic required and proposed authority

required = {"read-schedules", "write-summaries"}
proposed = {"read-schedules", "write-summaries", "manage-host"}
extra = proposed - required
assert extra == {"manage-host"}
assert required <= proposed
print("fictional excess authority identified")

Expected output

fictional excess authority identified

The complete program compares ordinary sets in memory. These labels are not actual kernel capabilities or account permissions. It performs no host audit, policy change, privilege transition, or service operation.

Identify the environment rather than guessing it

This course uses Ubuntu 24.04 LTS as an identified distribution reference for selected administrative concepts, with upstream Linux, systemd, AppArmor, and OpenSSH documentation where relevant. It does not claim that this host runs those versions or that every upstream feature is available in that release. Record the actual kernel, package, service manager, and policy assumptions for a real authorized design. Configuration examples remain illustrative and non-runnable. No commands are supplied as an instruction to alter this machine, and no account, firewall, service, device, or network operation is executed.

Keep security claims tied to observed boundaries

A policy model can establish a declared decision, a configuration review can show intended settings, and an approved integration test can observe actual enforcement. None automatically replaces the others. A local set comparison cannot establish containment, and a hardening score cannot prove the application’s protected outcome. Record positive and negative cases, exact environment, actual outputs, and untested limits. The course’s executable examples are standard-library computations only. Their value is clear reasoning about authority, while actual kernel, service, authentication, and deployment behavior remain separate evidence questions.

Common errors and fixes

A completed report proves least privilege

Why it happens: Useful output is confused with constrained authority.
How to fix it: Verify allowed and denied resource effects at the actual boundary.
Prevent it next time: Write protected outcomes before selecting controls.

An application role is called an OS sandbox

Why it happens: Different enforcement layers are collapsed.
How to fix it: Name the specific application and kernel claims.
Prevent it next time: Document dependencies and shared trust assumptions.

Upstream documentation proves host feature support

Why it happens: The actual distribution and version are unverified.
How to fix it: Record selected baselines and confirm support only in an authorized environment.
Prevent it next time: Keep platform fragments illustrative until verified.

Check your understanding

1. The report worker receives manage-host so setup is easier. What should the review ask?

Show worked solution

Identify the exact operation that supposedly requires it, whether that operation belongs in the worker at all, and whether a narrower reviewed setup boundary can perform it. Keep report execution separate from administration. The synthetic set difference identifies a question, not a validated replacement design.

2. Can a local model prove the host blocks attendee contact files?