Linux Security / Advanced: constrained design and verified change / Lesson 15

Separate encryption, access control, and recovery

Define the threat and lifecycle for data at rest, unlocked access, backup copies, and restoration evidence.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain why encrypted storage does not replace runtime authorization.
Verify backup claims through content, permissions, and application behavior rather than existence alone.

Choose the protection claim before the mechanism

Data at rest, data in use, transport, backups, and keys cross different trust boundaries. Linux dm-crypt provides block-device encryption under its selected configuration, but that fact alone does not define a complete key-management or application-authorization design. State which loss or disclosure scenario the mechanism addresses and which actors retain access. The report worker’s public schedules and private contact records need different handling. This course configures no encryption, opens no volume, generates no key, reads no device, and performs no cryptographic or storage operation; all examples are declared policy facts.

Keep runtime access distinct from encrypted media

When an approved system has unlocked storage, authorized processes can access plaintext through the normal resource path. Encryption does not make every process harmless or prevent disclosure through a permitted output. The first program models this distinction with declared booleans and a known authorized read. It performs no decryption. A real design must review credentials, keys, memory exposure, application permission, and the lifetime of unlocked access. Do not claim protection from a compromised runtime merely because the underlying volume is encrypted. Define key custody, recovery authority, and failure behavior through supported platform processes rather than classroom crypto code.

python Check an inert encryption/runtime distinction

facts = {"volumeEncrypted":True, "volumeUnlocked":True, "processMayRead":True}
plaintext_available_in_model = facts["volumeUnlocked"] and facts["processMayRead"]
assert facts["volumeEncrypted"] is True
assert plaintext_available_in_model is True
assert not (facts["volumeEncrypted"] and not plaintext_available_in_model)
print("declared encrypted storage can coexist with authorized plaintext access")

Expected output

declared encrypted storage can coexist with authorized plaintext access

The complete program evaluates three supplied facts and performs no encryption, decryption, key retrieval, mount, or file read. It establishes a logical distinction only, not the security or state of any real volume.

Treat a backup as another protected copy

A backup can preserve availability while creating another disclosure path. Define which data and metadata are included, who can read or restore it, how keys are recovered, and what retention and deletion mean for every copy. A successful backup job does not prove that restoration works or that restored permissions and application state are correct. The second program names pending verification stages in a synthetic recovery record. It performs no backup or restore. Keep tests within owned disposable resources when separately authorized, and never use private production data merely to make a teaching exercise realistic.

python Check pending recovery evidence without restoring data

required = {"content-restored", "permissions-restored", "application-behavior-verified"}
observed = {"content-restored"}
pending = sorted(required - observed)
assert pending == ["application-behavior-verified", "permissions-restored"]
assert not required <= observed
print("restoration evidence remains incomplete beyond content")

Expected output

restoration evidence remains incomplete beyond content

The complete program compares invented sets. It creates no archive, reads no backup, restores no file, and changes no ownership or permission. The pending items are requirements rather than real test results.

Review compatibility and security of the recovery state

An old backup or application artifact can reintroduce a corrected weakness or mismatch current data formats. Recovery planning must preserve the required security properties, not just return a process to running. Review secrets, authority, package revisions, mandatory policies, and audit continuity alongside data. Encryption-key loss can make a copy unusable, while overly broad recovery access can disclose it. Avoid universal key-storage or deletion prescriptions. Use the accountable organization’s reviewed architecture and verify the exact supported path. This course performs no restore drill, key operation, service start, or device change.

Report separately what each layer establishes

A precise statement distinguishes intended encryption, verified key handling, authorized runtime access, protected backup storage, and observed restoration. A label saying encrypted cannot stand in for all five. Record environment, method, actual outputs, limitations, and accountable next actions. The local examples establish only a logical access relation and missing verification items. They do not demonstrate recoverability, confidentiality of a real device, secure erasure, or operational readiness. Keeping the threat and lifecycle explicit helps engineers choose useful evidence rather than treating one storage mechanism as a universal Linux security guarantee.

Common errors and fixes

Encrypted means no running process can read data

Why it happens: At-rest protection is confused with unlocked runtime access.
How to fix it: Review actual authorized paths and process authority separately.
Prevent it next time: Define the threat each layer addresses.

Backup success proves recoverability

Why it happens: Creation is confused with verified restore behavior.
How to fix it: Verify content, metadata, permissions, and application outcomes.
Prevent it next time: Keep restore evidence and key recovery explicit.

Recovery restores a known weakness

Why it happens: Security state is ignored in the recovery target.
How to fix it: Review compatible corrected artifacts and retained protections.
Prevent it next time: Include authority and policy in recovery assumptions.

Check your understanding

1. The volume is encrypted and unlocked, and processMayRead=true. What does the model show?

Show worked solution

It shows declared authorized plaintext availability despite at-rest encryption. It performs no cryptographic operation and assesses no real volume. A real defense must separately constrain runtime authority and output channels rather than assuming encrypted media prevents every disclosure.

2. Only restored file content was checked. Why is recovery evidence incomplete?