To expound on the use of PAM to disable use of su by an account,
let's take a look at what PAM is, and what it does.
Before I get into the specifics of the PAM configuration that
prevents using su, even for accounts that know the root password,
I'd like to revisit some foundational concepts of PAM.
Let me begin by identifying PAM as a system for handling authentication
and authorization for applications. In the configuration that I performed,
the application is su, and authentication is certainly required when using su.
Now, let's have a look at some key concepts of PAM:
- Modules: PAM relies on dynamically loaded shared libraries called modules
that perform specific authentication tasks (e.g., username/password authentication).
In my configuration example, I'm using the module pam_wheel.so to achieve the
necessary outcome.
- Configuration Files: PAM uses configuration files (typically found in /etc/pam.d/)
to define which modules to use for different services/applications, and how to
manage the authentication process. In my configuration example, I'm using the file
/etc/pam.d/su.
- Function Types: Configuration files specify function types like auth (for authentication),
account (for account management), password (for password changes), and session
(for session management). Looking at my configuration example, you'll see that the
function type that is being specified is auth - because the module that is going to be called is going to perform authentication.
- Control Arguments: These arguments (required, requisite, sufficient, optional), also
referred to as Control Flags, dictate how PAM evaluates the rules within a module stack.
Again, looking at my configuration example, you'll see that I specify the Control Flag
required.
- Stacking: PAM evaluates modules in a specific order - this allows for authentication
scenarios where multiple modules might be involved. In the /etc/pam.d/su configuration
file, there are multiple modules. I don't show this in my configuration example, but
if you were to look at the contents of the /etc/pam.d/su configuration file on your
system, you will see not only multiple modules, but multiple modules that involve authentication.
Remember the function types I mentioned earlier! The function type that I'm
using offers flexibility. PAM allows system admins to easily switch authentication
methods, add new ones, and tailor authentication policies to specific applications
and services. Tailoring an authentication policy to a specific application is exactly
what I did in my configuration example, with the line
auth required pam_wheel.so use_uid
added to the /etc/pam.d/su file.
Now, let's examine the line auth required pam_wheel.so use_uid a little closer:
auth -> function type
required -> control argument
pam_wheel.so -> PAM library module
use_uid -> paramter to used by PAM library module
We've looked briefly at the function type, and control argument. Now,
let's take a closer look at the piece that's providing the magic for this
solution: pam_wheel.so
First, this module, along with a host of other modules, can be found in
the /usr/lib64/security directory.
I'll use the man command to examine the man page for the pam_wheel.so
module: $ man pam_wheel
Looking at the man page for this module, you can see right away this
module's purpose/function. This same man page will explain the purpose/function
of the use_uid option.
Pause!!!! Before reading any further, login to a RHEL system, and
take a look at this man page!!!
Okay, welcome back!
Now, in case you didn't already know this, the su application is PAM-aware.
What does that mean? That means that su relies on PAM to manage the
authentication process through configured modules.
Note: If you ever wish to verify that an application is PAM-aware, you can
use the ldd command to see if the application is linked to the PAM library
(libpam.so).
On my RHEL system, the line auth required pam_wheel.so use_uid already
exist, but it is commented. So, I just needed to remove the hash (#) at the
beginning of the line. Now that I've done that, any user account that wishes
to su to root, MUST be added to the group named wheel - even if the root
password is known.
In summary, all I needed to do to achieve my goal, was to make sure that
the line auth required pam_wheel.so use_uid is (uncommented) in the
/etc/pam.d/su file, and I'm done!!! If I need to have a user account to be
able to su to root, simply add that account name to the wheel group - and
take an extra 30 minutes for lunch!
Additional Commentary:
Earlier, in my writeup, I mentioned the Control Arguments (Control Flags).
I wanted to provide just a little bit more content on those here. I didn't
want to do so earlier because it was very PAM specific, and would have
taken the focus away from the specifics of my configuration example.
All PAM modules generate a success or failure result when called. Control flags tell
PAM what do with the result. Since modules can be stacked in a particular order,
control flags decide how important the success or failure of a particular module is
to the overall goal of authenticating the user to the service.
There are four predefined control flags:
required — The module result must be successful for authentication to continue. If a required module result fails, the user is not notified until results on all modules referencing that interface are completed.
requisite — The module result must be successful for authentication to continue. However, if a requisite module result fails, the user is notified immediately with a message reflecting the first failed required or requisite module.
sufficient — The module result is ignored if it fails. However, if a sufficient flagged module result is successful and no required flagged modules above it have failed, then no other results are required and the user is authenticated to the service.
optional — The module result is ignored. A module flagged as optional only becomes necessary for successful authentication when there are no other modules referencing
the interface.
Chetan, was this: Too much? Not enough? Too high level? Too low level?
Too _____ ? Just right?
Trevor "Red Hat Evangelist" Chandler
.png "Commander"){kind=icon}
