On Wednesday, March 26, 2014 01:49:01 PM Jan Lieskovsky wrote:
Attached is the patch introducing
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.
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
> > have login.defs and PAM rules separated into sections?) But looks the
> > second part (adding "minlen" check for PAM case) wasn't realized
> > 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
SSG mailing list opinion on this point would be appreciated too (I
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.