Linux Security / Intermediate: service, policy, and lifecycle boundaries / Lesson 7
Review service execution boundaries with systemd
Connect a service’s identity, filesystem view, privilege transitions, and legitimate writable state.
On this page
Lesson goals
- Explain what selected execution directives intend and what they do not prove.
- Separate filesystem write exposure from discretionary permission.
Derive the service boundary from its workflow
The report worker needs public inputs, a small writable state directory, and reviewed runtime dependencies. It should not gain host administration because a launcher happens to start it. A systemd service can express identity and execution-environment restrictions, but the directives must fit the actual workload and supported version. Ubuntu 24.04 systemd documentation is the selected reference for this fragment; no unit is installed or started. Record how the program reads inputs, creates state, communicates, and fails so a restriction can be assessed against useful behavior rather than collected as an unexplained score.
Read an illustrative execution fragment
The fragment selects an invented service account, proposes no_new_privs, makes much of the filesystem read-only under ProtectSystem=strict semantics, and names a writable exception. PrivateTmp changes temporary-directory visibility; it is not a complete isolation guarantee. ReadWritePaths does not grant ownership or discretionary write permission and cannot make an underlying read-only filesystem writable. This is not a complete unit and has no executable. Account existence, directory ownership, dependencies, feature support, and actual enforcement remain unverified. Do not paste it into a host configuration as a universal profile.
[Service]
User=report-lab
NoNewPrivileges=yes
ProtectSystem=strict
ReadWritePaths=/var/lib/report-lab
PrivateTmp=yesThe fragment is reviewed against selected documented concepts only. It is never installed, parsed by systemd, or applied. The account and path are illustrative labels, and no service or permission on this host is changed.
Model complementary write conditions
The local program treats discretionary permission, service filesystem exposure, and application scope as separately reviewed facts. All must be true under this fictional decision policy. It does not simulate the kernel or every systemd bypass and interaction. The purpose is to show why adding a writable path exception cannot repair an unrelated DAC or application denial automatically. A real service may also have inherited descriptors, namespaces, mandatory policy, and mounts that require separate consideration. Keep the decision model’s assumptions visible rather than calling three booleans a complete access-control implementation.
def write_allowed(dac, service_view, application_scope):
return dac is True and service_view is True and application_scope is True
assert write_allowed(True, True, True) is True
assert write_allowed(False, True, True) is False
assert write_allowed(True, False, True) is False
assert write_allowed(True, True, False) is False
print("four complementary write-policy cases checked")four complementary write-policy cases checkedThe complete program evaluates declared booleans in memory. It performs no file write or permission check and queries no service manager. Passing the model establishes only the chosen policy relation, not actual sandbox enforcement.
Review dependencies and persistent state together
A restricted service may still need libraries, sockets, name resolution, certificates, or data directories. Identify each dependency rather than broadening the whole filesystem when startup fails. Separate read-only inputs, writable state, temporary work, and secrets by purpose and lifetime. A private temporary view does not remove the need for safe file creation or cleanup. Logging and failure reporting must not expose protected values. Do not disable every restriction to obtain a successful start and then call the service hardened. A narrow correction should preserve the intended boundary and the legitimate work.
Distinguish intended unit text from effective behavior
An approved disposable verification should establish the actual loaded configuration and observe permitted input/output work plus denied unrelated operations. Record the systemd/kernel version and which features were available, ignored, or incompatible. No such operation is run here; the fragment stays non-runnable and the Python example is local arithmetic over facts. A configuration score or reviewed file alone cannot prove containment. Report which design claims are supported by inspection and which runtime boundaries remain pending, including account, path, capability, mandatory-policy, and service lifecycle assumptions.
Common errors and fixes
ReadWritePaths grants DAC write access
- Why it happens
- Filesystem exposure and ownership permissions are conflated.
- How to fix it
- Review actual identity, modes, ACLs, and policy separately.
- Prevent it next time
- Test complementary conditions rather than one directive.
A service fragment is called a complete sandbox
- Why it happens
- Dependencies and effective enforcement are unverified.
- How to fix it
- State the fragment’s scope and obtain approved runtime evidence.
- Prevent it next time
- Keep intended, loaded, and observed states distinct.
Startup failure removes all restrictions
- Why it happens
- The failing dependency is not localized.
- How to fix it
- Identify the exact required resource and narrow correction.
- Prevent it next time
- Pair successful work with denied unrelated effects.
Check your understanding
1. The writable exception exists but DAC is false. What does the local model decide?
Show worked solution
It refuses under the declared intersection policy. The exception describes service-view exposure, not an ownership grant. Actual diagnostics must identify which boundary denied access in an authorized environment; this course changes no permissions or unit settings.
2. Why is a reviewed systemd file insufficient to prove the worker is confined?
Show worked solution
The selected unit may not be loaded or may have overrides, unsupported settings, different credentials, inherited resources, or untested dependencies. Verify the effective environment and actual allowed/denied behavior separately. Preserve the file review as intent evidence without expanding it into a runtime guarantee.
Key takeaways
- Execution directives must fit the workload and selected version.
- A writable view does not grant discretionary permission.
- Actual confinement needs effective-state and behavior evidence.