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

Steve Grubb sgrubb at redhat.com
Wed Mar 26 22:35:27 UTC 2014


On Wednesday, March 26, 2014 01:49:01 PM Jan Lieskovsky wrote:
> 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,

Agreed.

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

On RHEL5 USGCB, CCE-17816-0 looks in /etc/libuser.conf to ensure we have 
login_defs = /etc/login.defs. RHEL6 should still be the same.


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

Doing something like that for RHEL7 would be great. Doing it for RHEL6...not 
so sure. One thing to remember about CC is that its mostly a technology 
demonstrator. The config demonstrates different requirements. But its not how 
you would normally run your system. For example, the capp.rules audit file 
demonstrates the requirements of CC. However, its not advisable to run like 
that.

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

In a way, I'd say doing the review is more important than actually making 
RHEL6 CC content since the eval was so long ago.

-Steve


More information about the scap-security-guide mailing list