PolicyKit (commonly referred to as polkit) is a system-wide authorization framework used in Linux distributions, including Ubuntu Server. Its primary function is to define and handle policies that allow unprivileged processes to communicate with privileged processes. For example, polkit is the mechanism that allows a standard user to execute a system reboot or mount a USB drive without requiring full sudo root access. While highly useful in desktop environments, polkit is largely unnecessary on headless, strictly managed servers where administrators rely exclusively on sudo or SSH key authentication for privilege escalation. In fact, polkit has historically been the source of several severe privilege escalation vulnerabilities (such as PwnKit).
This guide explains how to completely disable the polkit daemon in Ubuntu Server, minimizing your attack surface.
Stop and Mask the Polkit Daemon via Systemctl
To safely neutralize PolicyKit, you must stop the active systemd service and mask it. Masking is critical because many higher-level system packages (like network managers or package kits) may attempt to dynamically wake the daemon if they think it is merely stopped.
- Log into your Ubuntu Server via SSH or local console using an account with
sudoprivileges. - Check the current status of the daemon to ensure it is running:
systemctl status polkit.service - Stop the active service immediately:
sudo systemctl stop polkit.service - Disable the service so it does not load during the boot sequence:
sudo systemctl disable polkit.service - Mask the service to link its configuration to
/dev/null, making it completely impossible to start:sudo systemctl mask polkit.service
Understand the Impact
Once polkit is disabled, the server will rely entirely on traditional UNIX file permissions and the sudoers file for privilege management.
If an unprivileged user attempts to run a command that previously relied on a polkit authorization prompt (such as using systemctl restart on a system service without prepending sudo), the command will simply fail with an “Access Denied” or “Authorization failed” error message. The user will be forced to use sudo explicitly, ensuring that all privileged actions are properly logged and restricted by the rigorous, traditional sudoers configuration rather than a complex XML policy engine.