Minimum Password Length ...

Steve Grubb sgrubb at redhat.com
Wed Mar 26 22:20:10 UTC 2014


On Tuesday, March 25, 2014 10:17:07 AM Jan Lieskovsky wrote:
> > There should be no check of login.defs for minlen.
> 
> Maybe this misunderstanding sources from RHEL-5 USGCB content? Having look
> at relevant kickstart:
>   http://usgcb.nist.gov/usgcb/content/configuration/workstation-ks.cfg
> 
> suggests:
> ..
> # CCE-4154-1 (Row 69)
> sed -i "/PASS_MIN_LEN/s/[0-9]/12/" /etc/login.defs
> ..

That CCE has 3 parts, login.defs, passwdqc, and cracklib. The cracklib 
settings is done a couple lines later in the same spec file. We assumed that no 
one is using passwdqc.


> The particular CCE (CCE-4154-1) is then implemented as follows (checking
> both the login.defs & also the /etc/pam.d/system-auth part):
>   http://ovaldb.altx-soft.ru/Definition.aspx?id=oval:gov.nist.usgcb.rhel:def
> :20071
> 
> That form is included in USGCB content currently.
> 
> Is it possible that on Red Hat Enterprise Linux 5 the minimum password
> length requirement for the system was ensured via /etc/login.defs means
> (thus via shadow-utils, and that's why there's that bit in aforementioned
> kickstart)?

No.


> But from that time things changed, thus in Red Hat Enterprise Linux 6 the
> way how to enforce minimum length requirement for user's password on the
> system has changed. More exactly from that time PAM has become centre of
> mass (IOW should be used as primary mechanism for user password
> requirements management) and therefore in RHEL-6 now there should be check
> for minlen in /etc/pam.d/system-auth and no check via /etc/login.defs?
> 
> > You also have to
> > understand, there has been no engineering check of the validity of SSG
> > settings from top to bottom to compare against what we _designed_ as the
> > lockdown settings for common criteria.
> 
> Meaning there hasn't been (so far) engineering check / comparison if the
> actual SSG content corresponds to the requirements as specified in Common
> Criteria specification?

Sort of. That and a correctness check. Not correctness of OVAL/XCCDF, but 
correctness as in changing the right settings and making sure that all of the 
right settings are included.

> Who should perform such a comparison? (once we know this we can schedule
> a correction)

That has been the Security Technologies Team. There is some RHEL5 USGCB work 
that is needed and then I think we can turn attention to this.

-Steve


More information about the scap-security-guide mailing list