Wiunix
Talk to an Engineer
← Start of tutorial

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.

Debian 12Reviewed against official documentation ·

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
09

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.

bash

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-pager
How do I know it worked?

Only 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.

Explore all tutorials ↗