Minimum Password Length ...

[Trey Henefield]

I had noticed that the RHEL6 SSG and RHEL6 STIG both require checking /etc/login.defs for the password minimum length parameter 'PASS_MIN_LEN'.

This differs from the RHEL5 STIG in which it requires it being configured via the 'minlen' parameter for cracklib.so within /etc/pam.d/system-auth.

Furthermore, the RHEL5 manpage indicates the enforcement of /etc/login.defs, as it relates to passwords, as being deprecated. However, this is not indicated in the same manpage in RHEL6.

"Much of the functionality that used to be provided by the shadow password suite is now handled by PAM. Thus, /etc/login.defs is no longer used by programs such as: login(1), passwd(1), su(1). Please refer to the corresponding PAM configuration files instead."

So I decided to test this to see if RHEL6 is actually enforcing the 'PASS_MIN_LEN' parameter in /etc/login.defs, and it is not. I have it set to 14 and I was able to configure a password with 12 characters.

So shouldn't this be changed to reflect how this is configured in RHEL5, or am I missing something?

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

[e-mail]
Tel: [phone] ext. 647
Fax: [phone]
Mobile: [phone]

www.ultra-ats.com

Disclaimer
The information contained in this communication from [e-mail] sent at 2014-02-26 10:22:15 is confidential and may be legally privileged.
It is intended solely for use by [e-mail] and others authorized to receive it. If you are not [e-mail] 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.

[Trey Henefield]

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.

Is this a bug in RHEL6, or should this be defined in /etc/pam.d/system-auth in addition to or in place of /etc/login.defs?

It does enforce the setting properly if defined in /etc/pam.d/system-auth.

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

[e-mail]
Tel: [phone] ext. 647
Fax: [phone]
Mobile: [phone]

www.ultra-ats.com

From: [e-mail] [mailto:[e-mail]] On Behalf Of Trey Henefield
Sent: Wednesday, February 26, 2014 9:22 AM
To: [e-mail]
Subject: Minimum Password Length ...

I had noticed that the RHEL6 SSG and RHEL6 STIG both require checking /etc/login.defs for the password minimum length parameter 'PASS_MIN_LEN'.

This differs from the RHEL5 STIG in which it requires it being configured via the 'minlen' parameter for cracklib.so within /etc/pam.d/system-auth.

Furthermore, the RHEL5 manpage indicates the enforcement of /etc/login.defs, as it relates to passwords, as being deprecated. However, this is not indicated in the same manpage in RHEL6.

"Much of the functionality that used to be provided by the shadow password suite is now handled by PAM. Thus, /etc/login.defs is no longer used by programs such as: login(1), passwd(1), su(1). Please refer to the corresponding PAM configuration files instead."

So I decided to test this to see if RHEL6 is actually enforcing the 'PASS_MIN_LEN' parameter in /etc/login.defs, and it is not. I have it set to 14 and I was able to configure a password with 12 characters.

So shouldn't this be changed to reflect how this is configured in RHEL5, or am I missing something?

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

[e-mail]
Tel: [phone] ext. 647
Fax: [phone]
Mobile: [phone]

www.ultra-ats.comhttp://www.ultra-ats.com

Disclaimer
The information contained in this communication from [e-mail] sent at 2014-02-26 10:22:15 is private and may be legally privileged or export controlled. It is intended solely for use by [e-mail] and others authorized to receive it. If you are not [e-mail] 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.

[Steve Grubb]

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

[Trey Henefield]

Thanks for the response Steve. That is what I had figured.

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

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

[e-mail]
Tel: [phone] ext. 647
Fax: [phone]
Mobile: [phone]

www.ultra-ats.com

-----Original Message-----
From: Steve Grubb [mailto:[e-mail]] 
Sent: Thursday, March 20, 2014 7:59 AM
To: [e-mail]
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 [e-mail] sent at 2014-03-20 09:09:38 is confidential and may be legally privileged.
It is intended solely for use by [e-mail] and others authorized to receive it. If you are not [e-mail] 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.

[Jan Lieskovsky]

Hello Trey,

thank you for checking with us.

----- Original Message -----
> From: "Trey Henefield" 
> To: "Steve Grubb" , [e-mail]
> Sent: Thursday, March 20, 2014 2:09:35 PM
> Subject: RE: Minimum Password Length ...
>
> Thanks for the response Steve. That is what I had figured.
>
> 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:2...

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

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

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
>
> [e-mail]
> Tel: [phone] ext. 647
> Fax: [phone]
> Mobile: [phone]
>
> www.ultra-ats.com
>
> -----Original Message-----
> From: Steve Grubb [mailto:[e-mail]]
> Sent: Thursday, March 20, 2014 7:59 AM
> To: [e-mail]
> 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
> [e-mail] 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
> [e-mail] and others authorized to receive
> it. If you are not [e-mail] 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
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

[Shawn Wells]

On 3/21/14, 12:40 PM, Jan Lieskovsky wrote:
> Hello Trey,
>
> thank you for checking with us.
>
> ----- Original Message -----
> > > From: "Trey Henefield"
> > > To: "Steve Grubb",[e-mail]
> > > Sent: Thursday, March 20, 2014 2:09:35 PM
> > > Subject: RE: Minimum Password Length ...
> > >
> > > Thanks for the response Steve. That is what I had figured.
> > >
> > > 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:2...
>
> 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/a...
>
> 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, 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).
>
> 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?

The intent is to ensure minimum password length (akin to the RHEL5 USGCB 
title). I don't recall why it was defined specifically against 
login.defs (other than to imagine we inherited this in RHEL5 STIG, and 
did not get close enough review during the DoD Consensus meetings).

PAM minlen should be added.

[Steve Grubb]

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

-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
> >
> > [e-mail]
> > Tel: [phone] ext. 647
> > Fax: [phone]
> > Mobile: [phone]
> >
> > www.ultra-ats.com
> >
> > -----Original Message-----
> > From: Steve Grubb [mailto:[e-mail]]
> > Sent: Thursday, March 20, 2014 7:59 AM
> > To: [e-mail]
> > 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
> > [e-mail] 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 [e-mail] and others authorized to
> > receive it. If you are not [e-mail] 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
> > [e-mail]
> > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

[Jan Lieskovsky]

Thank you for the insights, Steve.

----- Original Message -----
> From: "Steve Grubb" 
> To: "Jan Lieskovsky" 
> Cc: "SCAP Security Guide" , "Shawn Wells" 
> 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:2...

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
> > >
> > > [e-mail]
> > > Tel: [phone] ext. 647
> > > Fax: [phone]
> > > Mobile: [phone]
> > >
> > > www.ultra-ats.com
> > >
> > > -----Original Message-----
> > > From: Steve Grubb [mailto:[e-mail]]
> > > Sent: Thursday, March 20, 2014 7:59 AM
> > > To: [e-mail]
> > > 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
> > > [e-mail] 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 [e-mail] and others authorized to
> > > receive it. If you are not [e-mail] 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.

[Steve Grubb]

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

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

[Jan Lieskovsky]

Hello Steve, Shawn, folks,

----- Original Message -----
> From: "Steve Grubb" 
> To: "Jan Lieskovsky" 
> Cc: "SCAP Security Guide" , "Shawn Wells" 
> 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-Configuratio...

(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
> > >
> > > [e-mail]
> > > Tel: [phone] ext. 647
> > > Fax: [phone]
> > > Mobile: [phone]
> > >
> > > www.ultra-ats.com
> > >
> > > -----Original Message-----
> > > From: Steve Grubb [mailto:[e-mail]]
> > > Sent: Thursday, March 20, 2014 7:59 AM
> > > To: [e-mail]
> > > 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
> > > [e-mail] 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 [e-mail] and others authorized to
> > > receive it. If you are not [e-mail] 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
> > > [e-mail]
> > > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

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

[Steve Grubb]

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