Hardening the Systemd Power Management

In this lesson, you will learn how to restrict unauthorized users from triggering system power states like shutdown, reboot, or suspend via systemd.

When a system is running in a multi-user environment, the default systemd configuration often allows any logged-in user to initiate a power-off or suspend command. From a security hardening perspective, this is a significant vulnerability, as a low-privileged user could disrupt critical services or cause data loss by shutting down the machine.

Restricting Polkit Actions

systemd delegates power management permissions to polkit (the PolicyKit). To harden these capabilities, you must override the default policy files. The core of this process involves creating a local authorization file in /etc/polkit-1/rules.d/ to explicitly define who can perform these actions.

By default, power actions are governed by the org.freedesktop.login1 namespace. You can restrict these actions to the root user or a specific administrative group (e.g., wheel or admin) by creating a file named 90-power-management.rules:

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.login1.power-off" ||
        action.id == "org.freedesktop.login1.reboot" ||
        action.id == "org.freedesktop.login1.suspend" ||
        action.id == "org.freedesktop.login1.hibernate") {
        if (subject.isInGroup("admin")) {
            return polkit.Result.YES;
        } else {
            return polkit.Result.NO;
        }
    }
});

Locking Down Systemd Login

Beyond polkit, you can further restrict power management at the systemd level by editing /etc/systemd/logind.conf. By setting specific directives, you can ignore power keys or switch requests made from the hardware or software interface:

[Login]
HandlePowerKey=ignore
HandleSuspendKey=ignore
HandleHibernateKey=ignore
PowerKeyIgnoreInhibited=yes

After modifying this file, restart the login manager with systemctl restart systemd-logind. This ensures that even if an attacker attempts to trigger a state change, the system remains unresponsive to those requests unless they have the required administrative clearance defined in your policy.

Key Takeaway: By combining Polkit authorization rules with strictly configured logind.conf parameters, you prevent unauthorized users from manipulating the system's power state.