PolicyKit Authentication Framework: From Authentication to Authorization

virtual-identity-69996_640

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.

Don’t Let The Users Flip The Switch

According to the manual pages for halt, poweroff, shutdown, and 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_rootok.so or 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

Everything Changes With RHEL 7

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 root.

How are unprivileged users still allowed to shut down and reboot, and how can we control that?

Authentication versus Authorization

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 there is a fingerprint scanner, and the user places their finger
    on the scanner and they are recognized, let them in.
  • If they are still trying (no scanner present, or it didn’t recognize
    their finger), ask them for a password. If it can be verified by the traditional UNIX test, let them in.
  • If they still aren’t in, deny them.

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.

Enter the PolicyKit Authorization Framework

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 reboot or 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.

Type to search blog.learningtree.com

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.