I started out working to prevent something that the manual pages said should already be impossible, and ended up exploring what was to me a whole new area of Linux security. Join me in my exploration.
According to the manual pages for
reboot, only the superuser
root should be able to execute those commands. That’s good, we don’t want unprivileged users shutting down or rebooting our critical servers!
However, many recent distributions allow this to happen. Up through Red Hat Enterprise Linux version 6, and thus CentOS 6 and the corresponding Oracle Linux, Scientific Linux, and many other distributions, users could do just that.
This was done through the magic of PAM or Pluggable Authentication Modules. A PAM-aware program looks for a configuration file with its name in the
/etc/pam.d directory. Those commands had corresponding PAM files and because of their contents, any user could reboot or halt the server.
You could prevent these unpleasant surprises by simply deleting those files. Or, you could edit them to change their logic, using the
pam_wheel.so module to limit the action to the user
root or members of group
wheel. We show you how to customize PAM logic in Learning Tree’s Linux server administration course. A better approach might be to rename the files so they still exist but aren’t used:
# cd /etc/pam.d # for file in halt poweroff reboot shutdown > do > mv $file DISABLED-$file > done
And I mean almost everything…
RHEL 7 is enormously different. The changes encountered when going from RHEL 6 to 7 are larger, much larger, than any major revision I can recall. See my list of RHEL/CentOS 5–6–7 changes for the details.
Those programs no longer have PAM files in the
/etc/pam.d directory. At first I assumed that this was because systemd now controls all this and much more. The corresponding programs were now symbolic links pointing to
/usr/sbin/systemctl which looked at how it had been called to decide what to do. But…there is no
/etc/pam.d/systemctl PAM file and the
/usr/sbin/systemctl program is not setuid as
How are unprivileged users still allowed to shut down and reboot, and how can we control that?
Authentication proves who you are, authorization specifies what you may do. Both are required, in that order, for security, but they have very different purposes.
The A in PAM stands for ”Authentication”. PAM lets you specify whatever logic and criteria you want for a user to authenticate into each PAM-aware service. Maybe graphical console login should be controlled as:
If that’s what you want, you can easily code that up with the appropriate logic in
/etc/pam.d/gdm or similar.
Now, once you have authenticated as some user, what are you allowed to do? That is an important question, but it is not the responsibility of PAM.
The old method of PAM authenticating users and that immediately corresponding to the authorization to halt or reboot the system violated the design philosophy.
The PolicyKit Authorization Framework or just polkit is how authorizations should be customized.
Polkit is an authorization system by which mechanisms (privileged programs such as
mount or other normally
root-only programs) can allow subjects (unprivileged programs such as a user’s shell) to run them.
The decision on every request is handed off to a trusted party, the polkit authority. Users may need to authenticate to polkit as either
root or the owner of the client session. Exactly how they authenticate depends on the context — are we on a graphical console, or a text-only terminal or console — and what you have set up through PAM. Its job, after all, is controlling authentication.
Usually the authentication is done by typing either the
root password or the current user’s password, either within the text console or window, or within a new graphical window that pops up on the graphical console.
That’s the background, the design philosophy clearly dividing authorization from authentication. Come back next time to see how to customize this! Meanwhile you might want to check out the polkit background or manual page.