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