WIUNIX ACADEMY
systemd hardening: prove the sandbox, then protect the real service
Page 3 of 3. Review the earlier steps and prerequisites before continuing.
YOUR SYSTEM. YOUR STEPS.
Where are you working?
Choose your OS and version. The prerequisites, commands and troubleshooting follow your environment.
USE YOUR OWN VALUES
Configure this tutorial
Set the example values for your environment; related explanations and copy panels update together. Never enter passwords, private keys or tokens. Values stay in this tab and are not sent to the server or share links. Check actual DNS, certificates and network policy before running commands.
Different IP addresses, domains or ports? Open the settings below, change the values and select “Apply to tutorial”, then copy the updated commands.
Set values for my environment3 editable values
LET’S BUILD
Disable only this drop-in if compatibility fails
During the same approved window, rename only the file created by this guide to the disabled sibling, refuse an existing sibling and reload/restart the one selected service. Other drop-ins remain active. This intentionally removes these restrictions for recovery; retain the failure evidence and revisit the minimum compatible scope before re-enabling them. Never use a blanket unit reversion that removes unrelated policy.
Authorized Linux terminal
sudo test ! -e '/etc/systemd/system/example-app.service.d/90-academy-hardening.conf.disabled' || exit 1
sudo mv -- '/etc/systemd/system/example-app.service.d/90-academy-hardening.conf' '/etc/systemd/system/example-app.service.d/90-academy-hardening.conf.disabled'
sudo systemctl daemon-reload
sudo systemctl restart 'example-app.service'
sudo systemctl status 'example-app.service' --no-pagerOnly the named new drop-in is disabled and application health returns; persistent data and unrelated policy are preserved.
Keep the fixture and claims proportional
Retain the tiny dedicated fixture until its result is reviewed, then remove only those known fixture files through your normal lab cleanup procedure. The article provides documented commands and a reproducible probe; its author did not execute this sandbox on your host. Record actual systemd/kernel versions, deny/allow output, unit settings and application acceptance when you run it.
GO TO THE SOURCE
Official references
Each environment states how it was reviewed. A documentation review does not claim a hands-on test of every version.
- systemd execution sandbox settings
- systemd analyzer security limitations and verification
- Transient systemd-run units
- systemctl unit editing and restart semantics
- Ubuntu release/support lifecycle
- Debian releases and support
- Supported Rocky Linux releases
- AlmaLinux releases
- RHEL9 network security and OpenSSH
- RHEL10 network security