Minimum Password Length ...

Jan Lieskovsky jlieskov at redhat.com
Tue Mar 25 14:17:07 UTC 2014


Thank you for the insights, Steve.

----- Original Message -----
> From: "Steve Grubb" <sgrubb at redhat.com>
> To: "Jan Lieskovsky" <jlieskov at redhat.com>
> Cc: "SCAP Security Guide" <scap-security-guide at lists.fedorahosted.org>, "Shawn Wells" <shawn at redhat.com>
> Sent: Tuesday, March 25, 2014 1:41:07 PM
> Subject: Re: Minimum Password Length ...
> 
> On Friday, March 21, 2014 12:40:40 PM Jan Lieskovsky wrote:
> > > But because both the RHEL6 SSG and RHEL6 STIG require this functionality
> > > to be configured only in /etc/login.defs as opposed to
> > > /etc/pam.d/system-auth, it was questionable.
> > > 
> > > While system certifications simply require checking that a system is
> > > configured in accordance with a published STIG, DSS will actually check
> > > to
> > > see that the intended requirements are actually enforced (i.e. actually
> > > attempt a non-compliant password as opposed to checking for applied
> > > settings).
> > > 
> > > So if we are all in agreement, could the SSG check and fix for this
> > > please
> > > be changed to include the setting that gets enforced (minlen=14 in
> > > /etc/pam.d/system-auth)?
> > 
> > You are truly right that on Red Hat Enterprise Linux 5 the rule checks both
> > conditions:
> >  
> > http://ovaldb.altx-soft.ru/Definition.aspx?id=oval:gov.nist.usgcb.rhel:def:
> > 20071
> > 
> > while in SSG content for Red Hat Enterprise Linux 6 just /etc/login.defs
> > condition:
> > https://git.fedorahosted.org/cgit/scap-security-guide.git/tree/shared/oval/
> > accounts_password_minlen_login_defs.xml
> > 
> > But (slight) uncertainty comes from the following:
> > * in RHEL-5 the rule is titled "CCE-4541-1: Set password minimum length"
> > (thus somehow implying this should be system-wide check). While
> > * on RHEL-6 it is titled "2.4.1.3.a. Set Password Minimum Length in
> > login.defs (CCE-27002-5)" (thus somehow implying it should be checking just
> > login.defs file due the login.defs being emphasized in the title).
> > 
> > This makes me believe the original intention when creating RHEL-6 content
> > was to have just login.defs specific rule,
> 
> I strongly suspect that this is entirely a misunderstanding. Login.defs is
> intended for use with shadow-utils. It provides a number of utilities that we
> do not use at all. They are deleted in the build stage. Those same utilities
> are provided by other packages such at util-linux. The other utilities not
> being part of shadow-utils have no integration with that file except when the
> upstream decided to use it. It is for this reason we labelled the setting as
> "has no effect".

Was checking this just to have explicit SSG list opinion about the proper way
how they want to have password minimum length requirement for a particular system to be
enforced implemented (to know the form a potential patch should have).

So we shouldn't be checking /etc/login.defs settings, but rather util-linux config
files settings?

> 
> 
> > and then add a pam_cracklib
> > specific rule into / under: "Set Password Quality Requirements" subsection
> > of "Protect Accounts by Configuring PAM" section (maybe to have login.defs
> > and PAM rules separated into sections?) But looks the second part (adding
> > "minlen" check for PAM case) wasn't realized later.
> > 
> > The summary being -- you are correct, the PAM minlen check should be added
> > to the current form of RHEL-6 SSG content. The question is where we want to
> > have this check being added -- if into minimum password length login.defs
> > rule (like it's done on RHEL-5) or under the PAM section (where it might
> > seem to be more logical to belong to).
> 
> 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
..

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)?

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?

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

> Common Criteria is the starting point
> for the locking don of the system because that is where we had to demonstrate
> everything to a third party lab assessing the security.

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team

> 
> -Steve
> 
> > I can come with a patch proposal, just first need someone on the list to
> > clarify the expected rule location. Shawn, can you possibly hint on this?
> > 
> > Thank you && Regards, Jan.
> > --
> > Jan iankko Lieskovsky / Red Hat Security Technologies Team
> > 
> > > Thanks!
> > > 
> > > Best regards,
> > > 
> > > 
> > > Trey Henefield, CISSP
> > > Senior IAVA Engineer
> > > 
> > > Ultra Electronics
> > > Advanced Tactical Systems, Inc.
> > > 4101 Smith School Road
> > > Building IV, Suite 100
> > > Austin, TX 78744 USA
> > > 
> > > Trey.Henefield at ultra-ats.com
> > > Tel: +1 512 327 6795 ext. 647
> > > Fax: +1 512 327 8043
> > > Mobile: +1 512 541 6450
> > > 
> > > www.ultra-ats.com
> > > 
> > > -----Original Message-----
> > > From: Steve Grubb [mailto:sgrubb at redhat.com]
> > > Sent: Thursday, March 20, 2014 7:59 AM
> > > To: scap-security-guide at lists.fedorahosted.org
> > > Cc: Trey Henefield
> > > Subject: Re: Minimum Password Length ...
> > > 
> > > On Thursday, March 20, 2014 07:28:34 AM Trey Henefield wrote:
> > > > Nobody has seemed to respond to this. But this is an issue.
> > > > 
> > > > In /etc/login.defs, I have PASS_MIN_LEN set to 14, yet as a user, I
> > > > can set the following password 56tyghbn%^TY which only has 12
> > > > characters via the passwd command.
> > > 
> > > In our common criteria setup, we have annotated the login.defs file with
> > > the following:
> > > 
> > > # The evaluated configuration constraints are:
> > > # PASS_MAX_DAYS MAY be changed, must be <= 60 # PASS_MAX_DAYS MAY be
> > > changed, 0 < PASS_MIN_DAYS < PASS_MAX_DAYS # PASS_MIN_LEN has no effect
> > > in the evaluated configuration # PASS_WARN_AGE MAY be changed
> > > 
> > > 
> > > Note...has no effect...
> > > 
> > > The intended way can be seen in system-auth:
> > > 
> > > password requisite pam_cracklib.so try_first_pass retry=3 type=
> > > password sufficient pam_unix.so sha512 shadow nullok try_first_pass
> > > use_authtok
> > > password required pam_deny.so
> > > 
> > > Of these, cracklib is responsible for enforcing password policy. Checking
> > > its man page, it has something called minlen. Looking at the RHEL5 USGCB
> > > settings, this is in fact how it's set:
> > > 
> > > sed -i "/pam_cracklib.so/s/retry=3/retry=3 minlen=12 dcredit=-1
> > > ucredit=-1
> > > ocredit=-1 lcredit=-1 difok=3/" /etc/pam.d/system-auth
> > > 
> > > So, to have 14, alter the above settings to correct it.
> > > 
> > > -Steve
> > > 
> > > 
> > > 
> > > 
> > > Disclaimer
> > > The information contained in this communication from
> > > trey.henefield at ultra-ats.com sent at 2014-03-20 09:09:38 is private and
> > > may
> > > be legally privileged or export controlled. It is intended solely for use
> > > by scap-security-guide at lists.fedorahosted.org and others authorized to
> > > receive it. If you are not scap-security-guide at lists.fedorahosted.org you
> > > are hereby notified that any disclosure, copying, distribution or taking
> > > action in reliance of the contents of this information is strictly
> > > prohibited and may be unlawful.
> > > 
> > > 


More information about the scap-security-guide mailing list