On Friday, September 28, 2012 02:53:22 PM Spencer R. Shimko wrote:
On Sep 28, 2012, at 9:50 AM, Steve Grubb <sgrubb(a)redhat.com>
> On Friday, September 28, 2012 01:27:25 PM Spencer R. Shimko wrote:
>> Is anyone strongly bound to pam_cracklib? The reason I ask is that the
>> prose and OVAL checks are currently written for pam_cracklib.
>> doesn't enforce complexity requirements on UID 0. pam_passwdqc can
>> password complexity requirements on root with the "enforce=everyone"
>> option. Many requirement sets do not differentiate between privilege
>> and unprivileged users in the I&A sections. As a result I'd like to
>> to passwdqc. Unless there is opposition we'll put together a patch to
>> the switch.
> Yes, I would prefer to stay with pam_cracklib for a number of reasons. If
> there were a deficiency in it, I'd rather open a bug report and fix it.
We did open a bug - way back in 2010 :P
I had hoped the feature would have been integrated into a release by this
point but at least it is being considered for RHEL 6.4.
It will be in the 6.4 release. the bug was filed against RHEL5 and that's why
it languished. Its on its way now.
Until the feature is released I'm going to have to stick with
will use SecState's mitigation feature to explain why we fail that check and
why it is a false negative.
Can you share those reasons you prefer cracklib?
Because of 2 reasons. 1) when password requirements come in, we have 2
packages to update. The pam package always has priority and gets updated more
often than pam_passwdqc. 2) Because of this, it also has capabilities that
pam_passwdqc does not have like the maxclassrepeat and reject_username
directives that were also govt requirements. See bz 673398.
I'm perfectly fine sticking with cracklib if this feature is
added. I do
like passwdqc's simplicity though.
I'd suggest enforcing this on 6.4 and higher. Its unfortunate the bug didn't
get reclassified to rhel6 faster. But its the best path forward for everyone's