Bug 588893 - pam does not enforce password complexity restrictions on root
Summary: pam does not enforce password complexity restrictions on root
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: pam
Version: 6.4
Hardware: All
OS: Linux
Target Milestone: rc
: 6.4
Assignee: Tomas Mraz
QA Contact: Dalibor Pospíšil
Depends On:
Blocks: 772279 782183 836160 840699
TreeView+ depends on / blocked
Reported: 2010-05-04 19:06 UTC by Ed Sealing
Modified: 2018-12-04 14:19 UTC (History)
7 users (show)

Fixed In Version: pam-1.1.1-12.el6
Doc Type: Release Note
Doc Text:
The pam_cracklib module now supports the enforce_for_root option, which enforces complexity restrictions on new passwords for the root account.
Clone Of:
: 1065960 (view as bug list)
Last Closed: 2013-02-21 10:32:14 UTC
Target Upstream Version:

Attachments (Terms of Use)
Patch to ensure complexity is enforced for root user (2.09 KB, patch)
2010-05-04 19:06 UTC, Ed Sealing
no flags Details | Diff
Proposed untested patch (4.98 KB, patch)
2011-09-15 18:45 UTC, Tomas Mraz
no flags Details | Diff

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0521 normal SHIPPED_LIVE Moderate: pam security, bug fix, and enhancement update 2013-02-20 21:28:50 UTC

Description Ed Sealing 2010-05-04 19:06:21 UTC
Created attachment 411378 [details]
Patch to ensure complexity is enforced for root user

Description of problem:
Pam does not currently enforce password restrictions on root.

Version-Release number of selected component (if applicable):
ALL current versions of PAM

How reproducible:

Steps to Reproduce:
1. Add cracklib complexity requirements to pam in system-auth
2. Change to Root user
3. Change password that does not conform to complexity requirements
Actual results:
Password successfully changed

Expected results:
Password should have been required to follow complexity requirements

Additional info:
Recommended as part of NIST SP 800-53 IA-5(1), applying to LOW, MEDIUM, &HIGH systems

Comment 1 Trey 2011-09-15 14:30:21 UTC
I have incorporated this patch and it does not seem to enforce the required functionality. I have built it on and used it with RHEL 5.6.

While there is some additional enforcement, such as validating the provided password against the dictionary list, it still does not enforce the password requirements on root as they are defined in /etc/pam.d/system-auth.

For instance, prior to the patch I could have root change its own password to "password". After the patch, root was prevented from changing its own password to "password".

However if I set my password policy in /etc/pam.d/system-auth to the configuration required by NIST (e.g. password requisite /lib/security/pam_cracklib.so minlen=14 ucredit=-1 lcredit=-1 dcredit=-1 ocredit=-1 enforce_root), then root should be required to enter a password that is at least 14 characters and includes 1 uppercase character, 1 lowercase character, 1 numeric character and 1 special character. However, this enforcement is not performed. I can still set a non-compliant password, such as the following: "qpalzmxn".

Comment 2 Tomas Mraz 2011-09-15 14:43:02 UTC
Are you sure you have the whole patch correctly applied? It seems like you did not apply the hunk on lines 631-637.

Comment 3 Trey 2011-09-15 15:53:52 UTC
I have verified that these lines are included in my resulting pam_cracklib.c file that gets built. There are also other patches being included as pulled from the SRPM for pam (pam-, but the lines you indicated are present. I have also verified that password requirements are still enforced on users, just not root. I can include my resulting pam_cracklib.c file, if you would like.

Comment 4 Tomas Mraz 2011-09-15 18:29:37 UTC
Ah, yes, the patch is not quite correct. I was looking at the current pam-1.1.4 pam_cracklib source and there the patch would work. It would have to be changed substantially - backporting parts of the code from pam-1.1.4 - to work.

Comment 5 Tomas Mraz 2011-09-15 18:45:33 UTC
Created attachment 523425 [details]
Proposed untested patch

This patch should work. It is untested though.

Comment 6 Trey 2011-09-15 19:01:16 UTC
Thanks Tomaz! I am building it now.

Comment 7 Trey 2011-09-15 20:07:21 UTC
You are awesome Tomas! Its now working as expected. I have verified that it now properly enforces minimum length and character class requirements.

One thing I noticed though is that password reuse is still possible for root. Perhaps this is because it doesn't prompt for the current password for root as it does for users?

Does the 'remember' parameter in system-auth not apply to root?

Thanks again for your help!

Comment 8 Tomas Mraz 2011-09-15 20:46:24 UTC
This would require further changes and as root can do basically anything on a system it does not really make much sense to force him to enter the old password on password change.

Comment 9 Trey 2011-09-15 21:02:43 UTC
I couldn't agree with you more! One can easily just remove the password hash for root in /etc/shadow and have no password at all. Unfortunately, individuals writing IA requirements just don't get that and trusting an administrator to follow requirements just isn't enough if they are not forced to do so. Even though passwdqc already addresses the problem we are trying to solve, we are being required to use cracklib and are also being required to use it in a way it just hasn't been designed to be used.

Hats off to you sir for at least helping us to get this far.

Comment 14 Jamie Duncan 2012-05-07 18:25:04 UTC
Speaking with Shawn Wells, this is a blocker for DoD and Intelligence Community networks for RHEL 6 acceptance.

Currently we're not compliant with NIST 800-53. In that policy it says that password complexity requirements must be enforced on ALL accounts — to include administrative — before that OS can be used/accepted

Comment 15 Trey 2012-05-07 19:28:44 UTC
The current solution only partially addresses NIST 800-53 requirements. Without the "remember" system-auth parameter being properly enforced on the root user, password reuse cannot be addressed (e.g. each time my password expires I can change to the same password I am using).

Comment 16 Tomas Mraz 2012-05-07 21:44:47 UTC
There is the pam_pwhistory module that has enforce_for_root option and is preferred to the remember feature of pam_unix.

Comment 17 Trey 2012-05-10 20:31:34 UTC
(In reply to comment #16)
> There is the pam_pwhistory module that has enforce_for_root option and is
> preferred to the remember feature of pam_unix.

I was not aware of that module. I think that makes the solution complete. Thanks for pointing that out. I have tested it on my RHEL5 system and it works perfectly as intended.

Any chance we may see this patch for pam_cracklib.so merged in the official RHEL5 pam package? I am compiling it myself, but always prefer using RHEL official rpms.

Thanks again!

Comment 18 Jamie Duncan 2012-05-23 15:39:01 UTC
Just for clarification:

Trey in the BZ is the customer.

pam_pwhistory provides the ability to remember a password so it's not repeated, but it's his proposed patch that enforces the complexity requirements on the root user. 

This is still an open request.

Comment 20 Jamie Duncan 2012-05-24 21:16:25 UTC
changes made per tmraz request.

Comment 22 Trey 2012-06-25 16:13:51 UTC
So it appears I overlooked this before, but it does not seem that it is possible to enforce minimum time period between password changes on root. I have performed 'passwd -n 1 root' and have verified the change in /etc/shadow. But I am not prevented from continuously changing my password as root. Any help or guidance would be appreciated. Thanks!

Comment 23 Tomas Mraz 2012-06-25 17:04:17 UTC
Yes, this is not possible.

Comment 24 Trey 2012-06-25 17:48:07 UTC
Thanks for your confirmation. So it is not possible to be fully compliant with NIST 800-53.

On a side note, I noticed that when using pam_pwhistory, that my newly changed password is not getting saved. It does appear to work properly in that it provides notification when a previous password was entered and requires me to start the process over. However when an acceptable password is entered, I get the standard notification that the password was successfully changed. But when I log in, it is still validating using my old password and not the new one I created. If I comment out the line with pam_pwhistory.so, I am able to change my password as normal.

Comment 25 Tomas Mraz 2012-06-25 17:53:22 UTC
Do you have enforce_for_root option on the pam_pwhistory.so command line?

Comment 26 Trey 2012-06-25 18:20:05 UTC
Yes, I have the following two lines after pam_cracklib.so configured:

password    sufficient    pam_pwhistory.so use_authtok remember=5 enforce_for_root
password    sufficient    pam_unix.so use_authtok sha512 shadow try_first_pass

Comment 27 Tomas Mraz 2012-06-25 18:34:15 UTC
Then that would be a bug, can you please open a regular support case so it can be properly investigated and prioritized?

Comment 28 RHEL Program Management 2012-07-10 07:04:22 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 29 Ludek Smid 2012-07-11 11:29:53 UTC
This request was erroneously removed from consideration in
Red Hat Enterprise Linux 6.4, which is currently under
development.  This request will be evaluated for inclusion
in Red Hat Enterprise Linux 6.4.

Comment 31 nilesh 2012-09-26 10:49:29 UTC
The option to enforce password policies for 'root' by pam_cracklib, should be named as 'enforce_for_root' to be consistent with existing option in pam_pwhistory for the same purpose.

Comment 32 Tomas Mraz 2012-09-26 11:01:22 UTC
Yes, sure, this is already in upstream.

Comment 35 errata-xmlrpc 2013-02-21 10:32:14 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.