Grub.conf file permissions
by Maura Dailey
When using EFI, grub.conf is stored on a vfat partition, so I have to
set the fmask on the partition if I want grub.conf to have 0600 (the
umask, by default, is 0077).
Two thoughts:
1. The STIG actually requires that /etc/grub.conf have correct owner and
file permissions, not /boot/grub.conf or /boot/efi/EFI/redhat/grub.conf
Obviously, /etc/grub.conf is a symlink. Is this something the STIG
should correct or a sign that we're just being more diligent?
2. If I set the fmask on /boot/efi, /boot/efi/EFI/redhat/grub.efi is
also going to have 0600 permissions. Does anyone know if this is a problem?
Once I have some consensus, I should have a patch to add file a file
permissions check that will cover both locations of grub.conf.
Thanks,
Maura Dailey
10 years, 6 months
[PATCH] grub.conf is not guaranteed to be in /boot/grub if the system is using EFI, so I added a test for its default location in /boot/efi/EFI/redhat
by Maura Dailey
There isn't any way to do this the clever way, following the symlink /etc/grub.conf, so for now at least, I added a second path to check, the path for EFI in a default install.
Signed-off-by: Maura Dailey <maura(a)eclipse.ncsc.mil>
---
RHEL6/input/checks/file_group_owner_grub_conf.xml | 18 +++++++++++++++---
RHEL6/input/checks/file_user_owner_grub_conf.xml | 18 +++++++++++++++---
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/RHEL6/input/checks/file_group_owner_grub_conf.xml b/RHEL6/input/checks/file_group_owner_grub_conf.xml
index 3fc076a..4856fdf 100644
--- a/RHEL6/input/checks/file_group_owner_grub_conf.xml
+++ b/RHEL6/input/checks/file_group_owner_grub_conf.xml
@@ -1,14 +1,16 @@
<def-group>
<definition class="compliance" id="file_group_owner_grub_conf" version="1">
<metadata>
- <title>File /boot/grub/grub.conf Owned By root Group </title>
+ <title>File grub.conf Owned By root Group </title>
<affected family="unix">
<platform>Red Hat Enterprise Linux 6</platform>
</affected>
- <description>The /boot/grub/grub.conf file should be owned by the root group.</description>
+ <description>The grub.conf file should be owned by the root group.</description>
+ <reference source="MED" ref_id="20130830" ref_url="test_attestation" />
</metadata>
- <criteria>
+ <criteria operator="OR">
<criterion test_ref="test_file_group_owner_grub_conf" />
+ <criterion test_ref="test_file_group_owner_efi_grub_conf" />
</criteria>
</definition>
@@ -17,11 +19,21 @@
<unix:state state_ref="state_file_group_owner_grub_conf" />
</unix:file_test>
+ <unix:file_test check="all" check_existence="all_exist" comment="/boot/efi/EFI/redhat/grub.conf owned by root" id="test_file_group_owner_efi_grub_conf" version="1">
+ <unix:object object_ref="object_file_group_owner_efi_grub_conf" />
+ <unix:state state_ref="state_file_group_owner_grub_conf" />
+ </unix:file_test>
+
<unix:file_object comment="/boot/grub/grub.conf" id="object_file_group_owner_grub_conf" version="1">
<unix:path>/boot/grub</unix:path>
<unix:filename>grub.conf</unix:filename>
</unix:file_object>
+ <unix:file_object comment="/boot/efi/EFI/redhat/grub.conf" id="object_file_group_owner_efi_grub_conf" version="1">
+ <unix:path>/boot/efi/EFI/redhat</unix:path>
+ <unix:filename>grub.conf</unix:filename>
+ </unix:file_object>
+
<unix:file_state id="state_file_group_owner_grub_conf" version="1">
<unix:group_id datatype="int">0</unix:group_id>
</unix:file_state>
diff --git a/RHEL6/input/checks/file_user_owner_grub_conf.xml b/RHEL6/input/checks/file_user_owner_grub_conf.xml
index 53d5e2f..290d883 100644
--- a/RHEL6/input/checks/file_user_owner_grub_conf.xml
+++ b/RHEL6/input/checks/file_user_owner_grub_conf.xml
@@ -1,14 +1,16 @@
<def-group>
<definition class="compliance" id="file_user_owner_grub_conf" version="1">
<metadata>
- <title>File /boot/grub/grub.conf Owned By root User</title>
+ <title>File grub.conf Owned By root User</title>
<affected family="unix">
<platform>Red Hat Enterprise Linux 6</platform>
</affected>
- <description>The /boot/grub/grub.conf file should be owned by the root user.</description>
+ <description>The grub.conf file should be owned by the root user.</description>
+ <reference source="MED" ref_id="20130830" ref_url="test_attestation" />
</metadata>
- <criteria>
+ <criteria operator="OR">
<criterion test_ref="test_file_user_owner_grub_conf" />
+ <criterion test_ref="test_file_user_owner_efi_grub_conf" />
</criteria>
</definition>
@@ -17,11 +19,21 @@
<unix:state state_ref="state_file_user_owner_grub_conf" />
</unix:file_test>
+ <unix:file_test check="all" check_existence="all_exist" comment="/boot/efi/EFI/redhat/grub.conf owned by root" id="test_file_user_owner_efi_grub_conf" version="1">
+ <unix:object object_ref="object_file_user_owner_efi_grub_conf" />
+ <unix:state state_ref="state_file_user_owner_grub_conf" />
+ </unix:file_test>
+
<unix:file_object comment="/boot/grub/grub.conf" id="object_file_user_owner_grub_conf" version="1">
<unix:path>/boot/grub</unix:path>
<unix:filename>grub.conf</unix:filename>
</unix:file_object>
+ <unix:file_object comment="/boot/efi/EFI/redhat/grub.conf" id="object_file_user_owner_efi_grub_conf" version="1">
+ <unix:path>/boot/efi/EFI/redhat</unix:path>
+ <unix:filename>grub.conf</unix:filename>
+ </unix:file_object>
+
<unix:file_state id="state_file_user_owner_grub_conf" version="1">
<unix:user_id datatype="int">0</unix:user_id>
</unix:file_state>
--
1.7.1
10 years, 6 months
[PATCH] New check for discovering bind mount on /var/tmp
by Maura Dailey
The bind option is recorded in /etc/mtab for bind mounts. Combinining it with the partition_test may be overkill.
- Maura Dailey
Maura Dailey (1):
New check uses /etc/mtab and mount partition check to look for bind
mount on /var/tmp
RHEL6/input/checks/mount_option_var_tmp_bind.xml | 44 +++++++++++++++-------
1 files changed, 30 insertions(+), 14 deletions(-)
10 years, 6 months
[PATCH] Tested partition checks, ensured they returned valid partitions.
by Maura Dailey
Added test checks for set of partition checks.
Signed-off-by: Maura Dailey <maura(a)eclipse.ncsc.mil>
---
RHEL6/input/checks/partition_for_home.xml | 18 ++++++++++--------
RHEL6/input/checks/partition_for_tmp.xml | 14 ++++++++------
RHEL6/input/checks/partition_for_var.xml | 18 ++++++++++--------
RHEL6/input/checks/partition_for_var_log.xml | 12 +++++++-----
RHEL6/input/checks/partition_for_var_log_audit.xml | 18 +++++++++++-------
5 files changed, 46 insertions(+), 34 deletions(-)
diff --git a/RHEL6/input/checks/partition_for_home.xml b/RHEL6/input/checks/partition_for_home.xml
index b784316..2081d18 100644
--- a/RHEL6/input/checks/partition_for_home.xml
+++ b/RHEL6/input/checks/partition_for_home.xml
@@ -5,20 +5,22 @@
<affected family="unix">
<platform>Red Hat Enterprise Linux 6</platform>
</affected>
- <description>If user home directories will be stored locally,
- create a separate partition for /home. If /home will be mounted
- from another system such as an NFS server, then creating a separate
- partition is not necessary at this time, and the mountpoint can
- instead be configured later.</description>
+ <description>If user home directories will be stored locally, create a
+ separate partition for /home. If /home will be mounted from another
+ system such as an NFS server, then creating a separate partition is not
+ necessary at this time, and the mountpoint can instead be configured
+ later.</description>
+ <reference source="MED" ref_id="20130830" ref_url="test_attestation" />
</metadata>
<criteria>
<criterion test_ref="test_home_partition" comment="/home on own partition" />
</criteria>
</definition>
- <linux:partition_test check="all" check_existence="all_exist" id="test_home_partition" version="1" comment="/home on own partition">
- <linux:object object_ref="object_mount_home_own_partition" />
+ <linux:partition_test check="all" check_existence="all_exist"
+ id="test_home_partition" version="1" comment="/home on own partition">
+ <linux:object object_ref="object_mount_home_own_partition" />
</linux:partition_test>
<linux:partition_object id="object_mount_home_own_partition" version="1">
- <linux:mount_point>/home</linux:mount_point>
+ <linux:mount_point>/home</linux:mount_point>
</linux:partition_object>
</def-group>
diff --git a/RHEL6/input/checks/partition_for_tmp.xml b/RHEL6/input/checks/partition_for_tmp.xml
index de93ee9..9c28c13 100644
--- a/RHEL6/input/checks/partition_for_tmp.xml
+++ b/RHEL6/input/checks/partition_for_tmp.xml
@@ -5,18 +5,20 @@
<affected family="unix">
<platform>Red Hat Enterprise Linux 6</platform>
</affected>
- <description>The /tmp directory is a world-writable directory
- used for temporary file storage. Verify that it has its own
- partition or logical volume.</description>
+ <description>The /tmp directory is a world-writable directory used for
+ temporary file storage. Verify that it has its own partition or logical
+ volume.</description>
+ <reference source="MED" ref_id="20130830" ref_url="test_attestation" />
</metadata>
<criteria>
<criterion test_ref="test_tmp_partition" comment="/tmp on own partition" />
</criteria>
</definition>
- <linux:partition_test check="all" check_existence="all_exist" id="test_tmp_partition" version="1" comment="/tmp on own partition">
- <linux:object object_ref="object_own_tmp_partition" />
+ <linux:partition_test check="all" check_existence="all_exist"
+ id="test_tmp_partition" version="1" comment="/tmp on own partition">
+ <linux:object object_ref="object_own_tmp_partition" />
</linux:partition_test>
<linux:partition_object id="object_own_tmp_partition" version="1">
- <linux:mount_point>/tmp</linux:mount_point>
+ <linux:mount_point>/tmp</linux:mount_point>
</linux:partition_object>
</def-group>
diff --git a/RHEL6/input/checks/partition_for_var.xml b/RHEL6/input/checks/partition_for_var.xml
index 58089ab..2ed1d38 100644
--- a/RHEL6/input/checks/partition_for_var.xml
+++ b/RHEL6/input/checks/partition_for_var.xml
@@ -5,20 +5,22 @@
<affected family="unix">
<platform>Red Hat Enterprise Linux 6</platform>
</affected>
- <description>Ensuring that /var is mounted on its own partition enables the
- setting of more restrictive mount options, which is used as temporary
- storage by many program, particularly system services such as daemons.
- It is not uncommon for the /var directory to contain world-writable directories,
- installed by other software packages.</description>
+ <description>Ensuring that /var is mounted on its own partition enables
+ the setting of more restrictive mount options, which is used as temporary
+ storage by many program, particularly system services such as daemons. It
+ is not uncommon for the /var directory to contain world-writable
+ directories, installed by other software packages.</description>
+ <reference source="MED" ref_id="20130830" ref_url="test_attestation" />
</metadata>
<criteria>
<criterion test_ref="test_var_partition" comment="/var on own partition" />
</criteria>
</definition>
- <linux:partition_test check="all" check_existence="all_exist" id="test_var_partition" version="1" comment="/var on own partition">
- <linux:object object_ref="object_mount_var_own_partition" />
+ <linux:partition_test check="all" check_existence="all_exist"
+ id="test_var_partition" version="1" comment="/var on own partition">
+ <linux:object object_ref="object_mount_var_own_partition" />
</linux:partition_test>
<linux:partition_object id="object_mount_var_own_partition" version="1">
- <linux:mount_point>/var</linux:mount_point>
+ <linux:mount_point>/var</linux:mount_point>
</linux:partition_object>
</def-group>
diff --git a/RHEL6/input/checks/partition_for_var_log.xml b/RHEL6/input/checks/partition_for_var_log.xml
index 8a8a6f4..94d235b 100644
--- a/RHEL6/input/checks/partition_for_var_log.xml
+++ b/RHEL6/input/checks/partition_for_var_log.xml
@@ -5,17 +5,19 @@
<affected family="unix">
<platform>Red Hat Enterprise Linux 6</platform>
</affected>
- <description>System logs are stored in the /var/log directory.
- Ensure that it has its own partition or logical volume.</description>
+ <description>System logs are stored in the /var/log directory. Ensure
+ that it has its own partition or logical volume.</description>
+ <reference source="MED" ref_id="20130830" ref_url="test_attestation" />
</metadata>
<criteria>
<criterion test_ref="test_var_log_partition" comment="/var/log on own partition" />
</criteria>
</definition>
- <linux:partition_test check="all" check_existence="all_exist" id="test_var_log_partition" version="1" comment="/var/log on own partition">
- <linux:object object_ref="object_mount_var_log_own_partition" />
+ <linux:partition_test check="all" check_existence="all_exist"
+ id="test_var_log_partition" version="1" comment="/var/log on own partition">
+ <linux:object object_ref="object_mount_var_log_own_partition" />
</linux:partition_test>
<linux:partition_object id="object_mount_var_log_own_partition" version="1">
- <linux:mount_point>/var/log</linux:mount_point>
+ <linux:mount_point>/var/log</linux:mount_point>
</linux:partition_object>
</def-group>
diff --git a/RHEL6/input/checks/partition_for_var_log_audit.xml b/RHEL6/input/checks/partition_for_var_log_audit.xml
index e88ceba..b7a7d68 100644
--- a/RHEL6/input/checks/partition_for_var_log_audit.xml
+++ b/RHEL6/input/checks/partition_for_var_log_audit.xml
@@ -6,18 +6,22 @@
<platform>Red Hat Enterprise Linux 6</platform>
</affected>
<description>Audit logs are stored in the /var/log/audit directory.
- Ensure that it has its own partition or logical volume. Make
- absolutely certain that it is large enough to store all audit logs
- that will be created by the auditing daemon.</description>
+ Ensure that it has its own partition or logical volume. Make absolutely
+ certain that it is large enough to store all audit logs that will be
+ created by the auditing daemon.</description>
+ <reference source="MED" ref_id="20130830" ref_url="test_attestation" />
</metadata>
<criteria>
<criterion test_ref="test_var_log_audit_partition" comment="/var/log/audit on own partition" />
</criteria>
</definition>
- <linux:partition_test check="all" check_existence="all_exist" id="test_var_log_audit_partition" version="1" comment="check for /var/log/audit partition">
- <linux:object object_ref="object_mount_var_log_audit_own_partition" />
+ <linux:partition_test check="all" check_existence="all_exist"
+ id="test_var_log_audit_partition" version="1"
+ comment="check for /var/log/audit partition">
+ <linux:object object_ref="object_mount_var_log_audit_own_partition" />
</linux:partition_test>
- <linux:partition_object id="object_mount_var_log_audit_own_partition" version="1">
- <linux:mount_point>/var/log/audit</linux:mount_point>
+ <linux:partition_object id="object_mount_var_log_audit_own_partition"
+ version="1">
+ <linux:mount_point>/var/log/audit</linux:mount_point>
</linux:partition_object>
</def-group>
--
1.7.1
10 years, 6 months
RE: Re: mappings to DISA STIG identifiers
by Moessbauer, David
Thanks that is the exact kind of artifact I was looking for - though I do understand that its current state may not be 4.0.
Regarding the NIST controls; yes I know this is eventually coming down the pike (at least as of last I heard), but there is a need to address accreditations in the interim. And as the Navy is my branch of interest, I expect it may still be a little while until these controls are fully replaced.
If in the future this also included the NIST controls, that would be very helpful in POA&M transitions to the newer controls.
V/r
David W. Moessbauer
System Engineer
Progeny Systems Corporation
david.moessbauer(a)progeny.net
SIPR: david.moessbauer.ctr(a)progeny.spawar-chas.navy.smil.mil
(410) 627-5633 (M)
(703) 368-6107 x315 (O) / x125 (lab)
Sent from my Verizon Wireless 4G LTE Smartphone
-------- Original message --------
From: Jeffrey Blank <blank(a)eclipse.ncsc.mil>
Date: 09/03/2013 23:13 (GMT-05:00)
To: scap-security-guide(a)lists.fedorahosted.org
Subject: (nwl) Re: mappings to DISA STIG identifiers
Ah, gotcha.
I can't find the authoritative memo that says so (DIARMF-related?),
but what I'd been hearing for a while is that the DoD will be adopting
the NIST 800-53 controls (via CNSS 1253). Can anyone else speak to
this from the policy angle? I assume this is why the older DoD IA
controls are not explicitly included with the RHEL 6 STIG. I assume
this represents represents DoD thinking (11 months ago, anyway):
http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2012-10/ispab_oct...
As for such a table, we're generating something similar already:
http://scap-securityguide.rhcloud.com/RHEL6/output/table-stig-rhel6.html
However, the STIG-related references here likely aren't accurate, as
we haven't account for any changes made by FSO, so I can't recommend
using this yet. Once we can synchronize with them and establish the
undesirability of any future private changes, it should be possible to
scalably reduce costs for C&A activities by providing such
commonly-used tables in the project.
On Tue, Sep 3, 2013 at 10:08 PM, Moessbauer, David
<david.moessbauer(a)progeny.net> wrote:
> At a minimum, I would suggest that such a table would contain
>
> a unique identifier such as the Group ID (Vulid) or the Rule Version
> (STIG-ID),
> the CCE number currently detailed in the SCAP results and
> the Severity (CAT).
>
> With this all can be easily linked back to the pertinent STIG. The IA
> Control was also presented in the prior iteration of the UNIX Checklist and
> earlier versions of the RHEL5 XCCDF.
>
>
> An IAC is the 'Information Assurance Control' as defined in DoDD 8500.01 and
> enumerated in DoDI 8500.2.
>
> The definition detailed in paragraph E2.1.19 of Directive states that "an IA
> Control is an objective IA condition of integrity, availability or
> confidentiality achieved through the application of specific safeguards or
> through the regulation of specific activities that is expressed in a
> specified format, i.e., a control number, a control name, control text, and
> a control class. Specific management, personnel, operational, and technical
> controls are applied to each DoD information system to achieve an
> appropriate level of integrity, availability, and confidentiality in
> accordance with reference"
>
> The following is an excerpt of a couple of them as displayed in this
> Instruction, where the 5 digit identifier is the IAC (IE: 'DCCB-2')
>
> DCCB-2 Control Board
> All information systems are under the control of a chartered Configuration
> Control Board
> that meets regularly according to DCPR-1. The IAM is a member of the CCB.
>
> DCCS-2 Configuration Specifications
> A DoD reference document such as a security technical implementation guide
> or security
> recommendation guide constitutes the primary source for security
> configuration or
> implementation guidance for the deployment of newly acquired IA- and
> IA-enabled IT
> products that require use of the product's IA capabilities. If a DoD
> reference document is
> not available, the system owner works with DISA or NSA to draft
> configuration guidance
> for inclusion in a Departmental reference guide.
>
> DCCT-1 Compliance Testing
> A comprehensive set of procedures is implemented that tests all patches,
> upgrades, and
> new AIS applications prior to deployment.
>
>
> BTW: apologize for my prior hijacking of subject line…
>
> v/r
>
> David Moessbauer
> (410) 627-5633 (M)
>
> The Information contained in or attached to this communication may be
> confidential and privileged proprietary intended only for the individual/s
> or entity to whom/which it is addressed. Any unauthorized use, distribution,
> copying or disclosure of this information is strictly prohibited. If you
> have received this communication in error please contact the sender
> immediately and delete from your system.
>
>
> -----Original Message-----
> From: scap-security-guide-bounces(a)lists.fedorahosted.org
> [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of
> Jeffrey Blank
> Sent: Tuesday, September 03, 2013 9:30 PM
> To: scap-security-guide(a)lists.fedorahosted.org
> Subject: (nwl) mappings to DISA STIG identifiers
>
> I have started a new subject/thread for this discussion.
>
> Please note: Subscribers to the list should never reply to any message,
> particularly one with a complex subject, and move to an off-topic
> discussion. It quickly results in confusion for mail clients which perform
> threaded display, as well as the list's web archives.
>
> As to David's question, there has been some informal discussion, but we have
> also not fully settled on how to do this. This will be a topic of an
> upcoming discussion, and it will also be key to ensuring that there is good
> correspondence between the STIG profile in SSG and the STIG which FSO
> releases.
>
> The CAT level should be identified as Severity (and this should be present
> in scan results).
>
> Assuming your desired output is a table, can you describe what columns would
> be in it?
>
> What's an IAC?
>
>
>
> On Tue, Sep 3, 2013 at 6:25 PM, Moessbauer, David
> <david.moessbauer(a)progeny.net> wrote:
>> A crucial piece of the current C&A Package is the need to appropriately
>> identify any vulnerabilities found via scans, inclusive of the CAT level,
>> both of which are identified in the STIG. Aside from this, the STIG ID
>> provides means to identify the IAC of a given vulnerability as well.
>>
>> CCI mapping would help, however, as these are not unique, it does not
>> fully accomplish the task at hand.
>>
>> Speaking as one that completes C&A Packages for purposes of ATO
>> acquisition, I would argue that this is a critical mapping.
>>
>> v/r
>>
>> David Moessbauer
>> (410) 627-5633 (M)
>>
>> The Information contained in or attached to this communication may be
>> confidential and privileged proprietary intended only for the individual/s
>> or entity to whom/which it is addressed. Any unauthorized use, distribution,
>> copying or disclosure of this information is strictly prohibited. If you
>> have received this communication in error please contact the sender
>> immediately and delete from your system.
>>
>>
>> -----Original Message-----
>> From: scap-security-guide-bounces(a)lists.fedorahosted.org
>> [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf
>> Of Shawn Wells
>> Sent: Tuesday, September 03, 2013 3:25 PM
>> Cc: scap-security-guide(a)lists.fedorahosted.org
>> Subject: Re: Possibility of Fedora SCAP content to be served by SCAP
>> security guide repository (either as subdirectory or via separated branch)?
>>
>> On 9/3/13 2:22 PM, Moessbauer, David wrote:
>>> Is there a matrix that can be referenced that will map the DISA
>>> STIG-ID (or Group ID) to the CCE Audit IDs? ...or any other mapping
>>> that can be deduced
>>>
>>> In Example:
>>> Group ID (Vulid): V-38487
>>> Group Title: SRG-OS-000103
>>> Rule ID: SV-50288r1_rule
>>> Rule Version (STIG-ID): RHEL-06-000015
>>
>>
>> That metadata hasn't been added... to be honest, nobody has found the
>> mappings meaningful enough to do. Can you help us understand how it'd
>> benefit you?
>>
>> Right now SSG rules are mapped back to the CCIs through various <ref>
>> tags, e.g.:
>> <ref nist="AC-6,AU-9" disa="22,32" />
>>
>> We could easily extend this to include a "stigid" name-pair value,
>> should (a) the community be convinced this would help end-users, and
>> (b) volunteers to perform the mapping
>> _______________________________________________
>> scap-security-guide mailing list
>> scap-security-guide(a)lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>> _______________________________________________
>> scap-security-guide mailing list
>> scap-security-guide(a)lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>
>
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
10 years, 6 months
bug: deny_password_attempts* seems broken
by Paul Tittle (Contractor)
Using deny_password_attempts as an example, it says:
Add the following lines immediately below the|pam_unix.so|statement
in|AUTH|section of|/etc/pam.d/system-auth|:
|auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800 fail_interval=900|
|auth required pam_faillock.so authsucc deny=3 unlock_time=604800 fail_interval=900|
-----------
Looking at input/checks/accounts_passwords_pam_faillock_deny.xml ,
accounts_passwords_pam_faillock_deny seems to test for the bottom line
in /etc/pam.d/system-auth and the top line in /etc/pam.d/password-auth,
but password-auth is not mentioned in the deny_password_attempts
description.
For the other two deny_password_attempts tests, it's a similar
situation. Is the test wrong or the description wrong?
Thanks,
Paul
10 years, 6 months