Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →To harden a systemd service, limit what it can see and do with filesystem, privilege, network, and system-call controls; use cgroup settings such as CPU, memory, and task limits to constrain resource use. These controls are separate, version- and kernel-dependent, and can disrupt a daemon if they conflict with its normal requirements. Check the installed manuals and test changes against the service’s real workload.
Where systemd service controls are documented
Security sandboxing directives are documented in systemd.exec(5). Unit-level resource controls are documented in systemd.resource-control(5). Consult the manuals installed on the target host: available directives and behavior can vary with systemd version and kernel support.
Most service-specific settings belong in the unit’s [Service] section. Filesystem and privilege controls reduce exposure; resource controls act through the kernel’s control-group mechanism. They address different risks and should not be treated as interchangeable.
Restrict filesystem access without breaking the service
ProtectSystem=
This setting makes filesystem areas read-only to the service, with broader restrictions depending on the selected value. Check the installed manual for the exact semantics. It is not an absolute barrier: the systemd manual documents limitations, including that /tmp/ and /var/tmp/ remain writable when ProtectSystem=strict is combined with PrivateTmp=.
Free tools Windows power users keep installed
One-click scans. No signup required.
#1 Best Overall
ProtectHome=
This controls service access to /home/, /root, and /run/user. Depending on the value, these paths can be made inaccessible, read-only, or represented through temporary-filesystem behavior. The systemd execution manual recommends enabling it for long-running services, particularly network-facing ones, unless the service needs access to private user data. Verify that configuration files, credentials, sockets, or other required inputs are not located in the affected paths.
PrivateTmp=
This gives a service private temporary directories. It can prevent the service from sharing temporary files with other units or processes, so do not enable it without checking whether that sharing is part of the application’s operation.
Rank #2
Filesystem namespacing is one layer of isolation, not a guarantee that every access path disappears. In particular, read-only path restrictions do not prevent all communication through Unix sockets located in affected directories. Identify data paths and IPC dependencies before tightening access.
Reduce privilege and kernel-interface exposure
NoNewPrivileges= and CapabilityBoundingSet=
NoNewPrivileges= prevents the service and its descendants from gaining new privileges through execve() mechanisms such as set-user-ID or set-group-ID bits and filesystem capabilities. CapabilityBoundingSet= limits the capabilities available to unit processes. Determine which capabilities the daemon needs for its actual operations before removing any; a missing capability may cause startup or runtime failures.
RestrictAddressFamilies=
This limits the socket address families a service may use. Include every family required by the daemon, not just its obvious network protocol: local IPC or another address family may be necessary for normal operation.
SystemCallFilter=
This can use allow-list or deny-list styles to limit system calls. An allow-list can be highly restrictive, so validate it against real service behavior. Deny lists also need maintenance as kernel interfaces and application behavior evolve; a filter that once worked may not remain suitable after upgrades.
Rank #4
MemoryDenyWriteExecute=
Check application requirements before enabling this setting. Programs that generate executable code dynamically, including JIT engines, may be incompatible. Confirm the directive’s behavior in the installed systemd manual as well as testing the application.
Set resource ceilings for the right failure mode
| Control | What it limits | Planning considerations |
|---|---|---|
CPUQuota= |
CPU time relative to one CPU. Values above 100% permit use across more than one CPU. | The systemd resource-control manual gives CPUQuota=20% as an example that ensures executed processes never get more than 20% CPU time on one CPU. This is a manual example, not a workload recommendation. |
MemoryHigh= / MemoryMax= |
Memory controls at the unit cgroup level. | Check support in the installed systemd version and kernel. Set limits with workload peaks and the consequences of hitting a limit in mind; a ceiling that is too low can make a healthy service fail. |
TasksMax= |
Task-count limit for the unit. | Check local manual and controller/kernel support, and allow for the service’s normal concurrency and subprocess needs. |
Do not confuse cgroup controls with LimitNOFILE=, LimitNPROC=, and similar per-process limits. They have different scope and behavior; use the relevant systemd manuals to choose the control that matches the problem.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsApply restrictions in stages and verify normal behavior
- Record the platform: note the installed systemd version and consult the local
systemd.exec(5)andsystemd.resource-control(5)manuals. - Map service requirements: identify writable paths, home-directory access, shared temporary files, Unix sockets, address families, required capabilities, expected system calls, and workload peaks.
- Add compatible security controls first: apply filesystem and privilege settings that match known requirements. Add capability and syscall restrictions with particular care.
- Choose resource ceilings deliberately: base CPU, memory, and task limits on expected load and on what should happen if the service reaches a ceiling.
- Reload and test: after editing a unit, run
systemctl daemon-reload, restart the service withsystemctl restart SERVICE, and inspectsystemctl status SERVICEand its logs. ReplaceSERVICEwith the unit name, such asexample.service. Exercise the service’s ordinary functions, including its less frequent paths. - Reassess after changes: revisit the settings when the application, systemd, or kernel changes, since requirements and supported controls may change.
A generic hardening profile is not guaranteed to fit every daemon. The manuals describe what settings do; they do not establish a universally tested profile for a particular service.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
