More granular/additional hash algorithm Rules.
Jeffrey Blank (2):
added 3 more granular password hash rules to common profile
made hash algorithm Rules more granular, added new for one specified
RHEL6/input/profiles/common.xml | 4 +-
RHEL6/input/system/accounts/pam.xml | 110 +++++++++++++++++++++++-----------
2 files changed, 77 insertions(+), 37 deletions(-)
For those working on hashing out the Severity Category Codes (e.g. CAT
levels) of the <rule>'s, our friends at DISA FSO have provided an
updated "category code definitions" table. Thank you!
I have posted it the the STIG Wiki Page:
And a direct link:
Note that we must use "low," "medium," and "high" and not the CAT
CAT I == High
CAT II == Medium
CAT III = Low
As a reminder, all rules default to "low" unless otherwise specified via
the "severity" tag, examples:
services/obsolete.xml:180:<Rule id="no_rsh_trust_files" severity="high">
U.S. Intelligence Programs
The modification of the password lockout rule to use pam_tally2 was
based on the following:
This was written specifically for RHEL6, for what it's worth. Taking
Steve's guidance in mind, I went looking for guidance for pam_faillock,
which led to:
...which references a pam_unix.so line -- I see no such line in
The pam_faillock man page shows two configuration examples, both
referring to /etc/pam.d/login -- neither example resembles that file on
my RHEL6 system. My /pam.d/login file contains several references to
system-auth, unlike the man page example which just lists pam modules.
Does anyone have definitive documentation on proper implementation of
pam_faillock that will serve our purposes here?
So in digging through all this, I'm finding a couple of things that either
aren't working right or that will require alterations to my current
configuration to comply.
Where do I ask the following questions? It seems that this group isn't the
place, but my google-fu is coming up short.
auth pam_tally2 ... deny=5
in /etc/pam.d/system_auth doesn't appear to reset if I successfully enter
my password after a failure. Eventually I get locked out and the audit
scripts do not appear to allow "unlock="
What is the best practice for application of pam_tally2?
SRG requires no .forward files. I currently do some data processing on
automated emails via procmail configured in .forward in a dedicated user.
What is the best practice for configuring such?
Jeffrey Blank (4):
new transform to add counter/placeholder for Vuln-ID into html table
added activation of Vuln-ID placeholder insertion transform
corrected check-content output
added severity (CAT) column to CCI table output
> Hey Andrew----long time. :)
Hey Joe! This is a healthier venue, I think. :)
The site you are looking for is "http://www.linux-pam.org", they have
> online and offline docs, as well as pointers to their mailing list.
I think I found it, the ks script I was working with didn't add pam_tally2
to the account module, so the success was not recorded. Sorted, although
sorting through internet "documentation" seems to be more of a chore every
However, my second question went unanswered:
> >SRG requires no .forward files. I currently do some data processing on
> automated emails via procmail configured in .forward in a dedicated user.
> What is the best practice for configuring such?
Flurry of minor fixes, many of which relate to comprehensive proofreading of
Rules in the pre-draft STIG profile.
Jeffrey Blank (7):
added smartcard/CAC use as a Rule
added CAC usage to STIG Profile
added alternate title text for STIG profile rules
corrections / updates to macros
ipv6 edits for consistency, linebreak fixes
updates to consensus notes from most recent call
added stig submission content to Make all
RHEL6/Makefile | 2 +-
RHEL6/input/auxiliary/alt-titles-stig.xml | 23 +++++-
RHEL6/input/auxiliary/transition_notes.xml | 23 +++++-
RHEL6/input/profiles/STIG-server.xml | 3 +-
RHEL6/input/system/accounts/physical.xml | 40 +++++++---
RHEL6/input/system/network/ipv6.xml | 122 +++++++++++++++++++---------
RHEL6/input/system/network/kernel.xml | 4 +-
RHEL6/transforms/shorthand2xccdf.xslt | 20 ++---
8 files changed, 166 insertions(+), 71 deletions(-)
> > Where is the right place to put changes like these? Should I be
> changing /var/lib/gdm/.gconf?
> The gconftool-2 utility can persistently chance the various values. I'm
> a big proponent of letting tools do their job, versus writing scripts to
> edit .gconf files directly (why write a script/tool when one already
> gconftool-2 -s to set a boolean, -g to verify it seems simple enough.
I'm all about letting tools do their job, I was asking whether to change
/etc/gconf/gconf.xml.mandatory as root, or
change the gdm user settings.
I expect that for banner, greeter changes, it's gdm, for the thumbnailers,
screensaver, etc., it's /etc/gconf.