[PATCH] [RHEL/6] Introduce accounts_password_pam_cracklib_minlen OVAL check [was: Re: Minimum Password Length ...]

Jan Lieskovsky jlieskov at redhat.com
Wed Mar 26 17:49:01 UTC 2014


Hello Steve, Shawn, folks,

----- 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".

Has had further look into this and mainly based on:
  [1] http://h20331.www2.hp.com/enterprise/downloads/RHEL5-CC-EAL4-HP-Configuration-Guide.pdf

(sections "3.14 Configuring default account properties" and
          "3.13.1 /etc/pam.d/system-auth" of it)

(now) I understand what you meant when referring to /etc/login.defs setting as "having no effect".

Attached is the patch introducing accounts_password_pam_cracklib_minlen OVAL check
for existing accounts password requirements check. The existing login.defs has been
kept there (due to results from testing I will speak further about below), but it's
title was changed to explicitly mention it changes only future account's password
requirements (and explicit bold paragraph stating it was added too). Please review.

Performed also wider (RHEL-6) testing and noticed the following:
* /etc/login.defs settings are honoured by tools like useradd or system-config-users
  (when creating new users) - so keeping the /etc/login.defs checks seems to make sense
  at least from the PoV of administrators accustomed to manage user accounts via these tools,

* kuser tool from the kdeadmin package seems to load the warning_age / min_age / max_age
  values from /etc/default/useradd file. So probably we should add yet another rule
  checking /etc/default/useradd settings to have the kuser use case covered too?
  Opinion on this appreciated.

* didn't look / test the behaviour / configuration of libuser tools (luseradd, lpasswd etc.)
  tools yet. This needs to be done yet.

> 
> 
> > 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. 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. 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.

FWIW regarding that CC document -- maybe we could create a new common_criteria
profile for RHEL-6 content and within that review the instructions from that document
section by section to ensure they are reflected in RHEL-6's SCAP content (IOW
adding the rules to the proposed common_criteria profile only in moment the relevant
section from that document has been reviewed and particular test as implemented in
the profile to comply with the behaviour described in the document).

SSG mailing list opinion on this point would be appreciated too (I can do that,
we just need to define priority of it and include it into some of the upcoming
sprints for our team).

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

P.S.: Couple of margin notes to the patch itself yet:

* the check was intentionally placed under RHEL/6/input/checks directory
  (rather than into shared/oval one). The reason being different modules
  (pam_cracklib in RHEL-6 vs pam_pwquality in Fedora and RHEL-7. While pam_pwquality
  functionality / options look / work similar to those from pam_cracklib, it didn't
  look correct to me merge the checks (and possibly introduce yet more confusion)

* the patch testing uncovered some invalid sysctl selectors (typos in the names)
  in OpenStack / RHEVM3 profiles => the patch fixes these too

* the RHEL/6/input/profiles/CS2.xml profile has also invalid selectors (typos
  s/acount/account/ and the three sysctl ones), but besides that it contains
  some whitespace noise yet, so will create a dedicated / specific patch just
  for this case (not to mix unrelated things)

* it has been tested on RHEL-6 and seems to be working properly. But review / testing
  appreciated as always.

> 
> -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.
> > > 
> > > 
> > > _______________________________________________
> > > scap-security-guide mailing list
> > > scap-security-guide at lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-RHEL-6-Introduce-accounts_password_pam_cracklib_minl.patch
Type: text/x-patch
Size: 16695 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20140326/589b6d5a/attachment-0001.bin>


More information about the scap-security-guide mailing list