In this lesson, you will learn how to bridge systemd unit files with Mandatory Access Control (MAC) policies to create a robust, layered security sandbox for your background services.
The Power of Layered Hardening
While MAC systems like AppArmor define what a process is allowed to touch on the filesystem, systemd provides a set of directives that control how a process interacts with the kernel and system resources before it even hits your MAC policy. By combining these, you create a "defense-in-depth" architecture where systemd acts as the first gatekeeper and your MAC profile acts as the final arbiter.
Integrating Directives with MAC Policies
When hardening a service, you should prioritize systemd directives that restrict the execution environment. For instance, using PrivateDevices=true isolates the service from physical hardware devices. When combined with an AppArmor profile, you no longer need to write complex rules to deny /dev/sda access; the kernel-level namespace isolation provided by systemd handles it natively.
Consider this snippet for a hypothetical service unit file:
[Service]
# Namespace isolation
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
# Limit kernel-level capabilities
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
# Restrict IPC and kernel interfaces
RestrictAddressFamilies=AF_INET AF_INET6
RestrictNamespaces=true
When you apply these settings, you significantly shrink the attack surface. If an attacker gains code execution within your service, they are already trapped in a restricted view of the filesystem and denied access to arbitrary kernel namespaces. Your AppArmor profile can then focus strictly on application-specific constraints, such as limiting the service to only read from its designated configuration directory and write to its specific log path.
Because systemd settings are enforced at process startup, they simplify your MAC policy maintenance. You won't need to craft broad "deny" rules for hardware or system directories within your profile because the systemd sandbox effectively makes those paths invisible or inaccessible to the service binary. Always verify your systemd hardening by checking systemd-analyze security <service-name> to ensure your MAC policies are not overlapping with unnecessary security gaps.
Key Takeaway: Use systemd unit directives to create a baseline sandbox that isolates the service environment, allowing your MAC policies to focus exclusively on refined, high-level access control rules.