Before you start
Environment: A disposable Ubuntu 24.04 LTS VM using systemd. The service example assumes an existing, nonessential demo-api.service and a dedicated non-root account named demo-api.
Use Linux practice first if chmod, ownership, or systemctl are new. Replace the example service and paths only after inspecting your unit. Keep a copy of the existing unit and its drop-ins.
Commands run in your own terminal. This website cannot inspect or secure your environment.
Practice · temporary files only
1. Give private files a deliberate owner
Broad file permissions can expose tokens even when the application itself has no public endpoint.
lab_dir=$(mktemp -d)
(umask 077; printf "demo-value-only\n" > "$lab_dir/demo.env")
stat -c "%a %U:%G %n" "$lab_dir/demo.env"
namei -l "$lab_dir/demo.env"What to check
The new file has mode 600 and belongs to your current user. The temporary directory should be private. This exercise deliberately uses synthetic data.
Try it deliberately
Explain why chmod 777 is a poor response to a permission error. For a real service, check which account reads the file and grant only that account or a narrowly scoped group access.
Recovery & cleanup
Remove only this synthetic file with rm -- "$lab_dir/demo.env", then rmdir -- "$lab_dir". Do not recursively change ownership or permissions across system directories.
Official guidance: GNU Coreutils file permissions ↗
Change · service restart required
2. Sandbox one nonessential service
A compromised process should have fewer places to write and fewer opportunities to gain privilege.
systemctl cat demo-api.service
sudo systemctl edit demo-api.service[Service]
User=demo-api
Group=demo-api
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes
StateDirectory=demo-apisudo systemctl daemon-reload
sudo systemctl restart demo-api.service
systemctl is-active demo-api.service
systemctl show demo-api.service -p User -p NoNewPrivileges -p ProtectSystem
sudo journalctl -u demo-api.service -n 30 --no-pagerWhat to check
The process runs under demo-api and the application health check still succeeds. StateDirectory creates /var/lib/demo-api with suitable ownership; configure the app to write its state there.
Try it deliberately
The account must already exist. Code under /home will be hidden; use a suitable application directory such as /opt/demo-api. Test uploads, temporary files, and startup writes. systemd sandbox support depends on the kernel and execution environment.
Recovery & cleanup
Remove just the lines or new drop-in you added, restore any previous version, then daemon-reload and restart. Do not use systemctl revert blindly: it can remove other administrator customizations.
Official guidance: systemd execution sandbox options ↗
Inspect · logs may contain sensitive information
3. Collect evidence without leaking secrets
An alert is easier to investigate when service events, ownership, and the last change are known.
sudo journalctl -u demo-api.service --since "30 minutes ago" --no-pager
systemctl --failed
df -h
systemctl show demo-api.service -p ExecMainStatus -p ActiveEnterTimestampWhat to check
You can identify the service start time, recent failures, and available disk space. A healthy process alone does not prove a healthy application; check its normal request path too.
Try it deliberately
Write a short runbook: symptom, log location, health check, last change, owner, and restore procedure. Redact tokens and personal data before sharing evidence; test log retention and backup restoration.
Recovery & cleanup
Inspection does not require restarting the service. Preserve relevant evidence before rotating logs or rebuilding the VM.
Official guidance: journalctl reference ↗
Reviewed 31 October 2026. Adapt to your installed versions and environment; these guides cover selected controls, not a compliance certification.