It shouldn't match commented out lines. Here's the pattern match line:
<ind:pattern operation="pattern
match">^[\s]*password[\s]+(?:(?:required)|(?:requisite))[\s]+[\w_\.\-=\s]+[\s]ucredit=(-?\d+)(?:[\s]|$)</ind:pattern>
- The ^ means: anchor our regex to the beginning of the line.
- The [\s]* means: match any kind of white space, zero or more times.
White space includes spaces, tabs, new lines, and return lines, but not
comment characters. (The next [\s]+ features a '+', which means: match
one or more times.)
- Paragraphs normally group things that we are matching for, it's called
capturing, but since the next few groups of parentheses begin with ?:,
the chunk "(?:(?:required)|(?:requisite))" means search for required OR
requisite, but that's not our match.
- Then we see another white space group, [\s]+, followed by a more
complicated search [\w_\.\-=\s]+, which looks for words, underscores,
periods, minus signs, equals signs, and more spaces (square brackets
mean: here is a group of individual characters or character classes that
I want to look for in the same location).
- More whitespace searching follows (just in case), followed by the all
important ucredit=.
- Here, the paragraph grouping IS what we're looking for, so it doesn't
have the combination ?:. Instead, it says, we're looking for one or more
digits "\d+", but it might be negative "-?". (To review, * means match
0
or more times, + equals match 1 or more times, ? can mean match 1 or 0
times.)
- There's some more nongrouping searching, which looks ahead for white
space OR a $, which means match end of line. (Either ucredit is the last
thing in the list, or there's going to be at least one space between it
and the end of the line. Searches with parentheses don't care about
intermediate characters. They look ahead or behind.)
I'm not a regex expert by any means. I find OVAL's regex cheatsheet to
be very helpful:
Maura,
Thank you for the quick reply. The options within the XCCDF source
for valid values now makes the "selector" wording more logical. I was
falling into the trap of coincidences with the value of "2" being
translated to a "-2" in the system-auth in my mind.
The "Less than or equal to 1 probably means first match or none." is
interesting in that for lines I modify, I typically comment out the
original so that I or others will know that the conf file has been
customized. I will test, but it feels like the regex will capture
commented lines as well and may produce false positives if the
commented line is above.
For example,
# --Modified--password requisite pam_cracklib.so try_first_pass
retry=3 type=
password requisite pam_cracklib.so try_first_pass retry=3 type=
maxrepeat=3 minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 difok=4
I will familiarize myself with the XML schema documents. I will
continue to watch the project. As my understanding becomes more in
depth, I may try to participate in some fashion.
*Robert Hayden*| Sr. Technology Architect | Cerner Corporation |
816.201.4068 | rhayden(a)cerner.com <mailto:rhayden@cerner.com> |
www.cerner.com
*From:*Maura Dailey [mailto:maura@eclipse.ncsc.mil]
*Sent:* Tuesday, July 30, 2013 5:54 PM
*To:* scap-security-guide(a)lists.fedorahosted.org
*Cc:* Hayden,Robert
*Subject:* Re: Incorrect Profile variable for stig-rhel6-server?
You're right, that doesn't look right. The error appears to be in the
refine-value section of the generated ssg-rhel6-xccdf.xml document.
When I look at ucredit's XCCDF source, I see that it has four possible
defined values:
<value>-1</value>
<value selector="2">-2</value>
<value selector="1">-1</value>
<value selector="0">0</value>
The refine-value selector value is pointing to "2", which is equal to
-2. Other profiles have the exact same refine-value settings, probably
a copy paste mistake that got propagated further. This feels like an
off by one error and deserving of a patch.
The instance element that confused you that was inside the regex
object is actually to allow you to refer to a specific match by
number. The first match is 1, the second would be 2, etc. Often, you
will see it set to greater than or equal to 1, which means "set of all
matches". Less than or equal to 1 probably means first match or none.
You may find the official OVAL language definition documentation
helpful, although they are admittedly hard to parse on the first pass.
Here's the page for the independent namespace:
http://oval.mitre.org/language/version5.10.1/ovaldefinition/documentation...
<
https://urldefense.proofpoint.com/v1/url?u=http://oval.mitre.org/language...
Here's the list of all the definitions (I find reading from the html
Documentation column to be easier than attempting to parse XML
directly):
http://oval.mitre.org/language/version5.10.1/index.html
<
https://urldefense.proofpoint.com/v1/url?u=http://oval.mitre.org/language...
Thanks for your email! If you'd like to look at friendlier syntax,
please feel free to look at the XML source in our git repository. It
has human readable ids. We are pushing out semi regular updates to the
RPM version as well.
- Maura Dailey
On 07/30/2013 05:54 PM, Hayden,Robert wrote:
All,
Please forgive my ignorance, as I am just starting to wrap my
brain around the terminology in the Security community and the
SCAP testing tools. I guess a newbie warning. I attempted to
highlight sections of text below to help in reading, but it may
get stripped out from some emailers. Jump to the bottom if you
want to see my questions and skip the investigation parts.
After the Red Hat conference, I got interested in the
SCAP-Security-Guide and OpenScap project in terms of helping to
pass the RHEL 6 STIG from the DoD. Primarily I am in R&D for a
large Healthcare software company. We are evaluating RHEL 6 now
and I wanted to incorporate as much of the DoD security components
that I could. The SCAP-Security-Guide and OpenScap seemed like a
perfect fit.
My configuration:
RHEL 6.4 +
openscap.x86_64 0.9.3-1.el6
openscap-utils.x86_64 0.9.3-1.el6
scap-security-guide.noarch 0.1-12.el6
I read through all of the pages in the SCAP Security Guide web
site, read the STIGs, and tested a eval of oscap with the Profile
set to stig-rhel6-server. I kept failing the series of checks
associated to the /etc/pam.d/system-auth setting on pam_cracklib.so.
The rhel6-guide.html (section 2.4.2.2.1) indicated to change
/etc/pam.d/system-auth to read:
password required pam_cracklib.so try_first_pass retry=3
maxrepeat=3 minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1
difok=4
Seemed simple enough. But, I was still failing the evaluation
check. The 'dcredit' would pass, but the parameters beyond that
would fail their respective checks.
Looking at the DoD STIG, version 1 release 2, it also showed that
a ucredit=-1 was the expected setting to pass V-38569.
I first read through the open tickets to see if this was a
reported defect. Nothing in particular matched, although there
was some talk about changing these checks to work on both the
/etc/pam.d/system-auth and /etc/pam.d/password-auth files.
I decided to dig into the source.
From the "accounts_password_pam_cracklib_ucredit.xml" [1], I see
that the checks appear to be a pattern match operation, searching
the file "system-auth" located in the "/etc/pam.d" directory. I
am not 100% sure what the <ind:instance> is telling me, but I
assumed it was (a) the return value of the pattern match had to be
less than or equal to 1, or (b) that the number of matches found
in the system-auth file had to be less than or equal to 1.
<ind:textfilecontent54_object id="obj_password_pam_cracklib_ucredit"
version="1">
<ind:path>/etc/pam.d</ind:path>
<ind:filename>system-auth</ind:filename>
<ind:pattern operation="pattern
match">^[\s]*password[\s]+(?:(?:required)|(?:requisite))[\s]+[\w_\.\-=\s]+[\s]ucredit=(-?\d+)(?:[\s]|$)</ind:pattern>
<ind:instance datatype="int" operation="less than or
equal">1</ind:instance>
</ind:textfilecontent54_object>
My regex skills are weak, so I went to a helpful web site[2] to
help interpret the regex. Given my line in system-auth file and
the regex listed in the check, the regex appeared to be working as
designed. A value of "-1" was being returned in the second
element of the array.
That is good.
I thought maybe my downloaded scap-security-guide content may have
been out of date compared to the source I was reviewing. The
mailing list seems to show a very active project with many patches
flowing into the project.
Since the installed files are a compilation of hundreds of source
xml files, reviewing the installed xml was interesting. I am sure
there is a simpler way to connect a check to the commands….but
here is how I completed the task.
In "ssg-rhel6-oval.xml", I find a <definition
id="oval:ssg:def:249"> that contains criteria for the ucredit
test, test_ref="oval:ssg:tst:250".
<definition class="compliance" id="oval:ssg:def:249"
version="1">
<metadata>
<title>Set Password ucredit Requirements</title>
<affected family="unix">
<platform>Red Hat Enterprise Linux 6</platform>
</affected>
<description>The password ucredit should meet minimum
requirements using pam_cracklib</description>
<reference source="ssg"
ref_id="accounts_password_pam_cracklib_ucredit"/></metadata>
<criteria>
<criterion comment="Conditions for ucredit are satisfied"
test_ref="oval:ssg:tst:250"/>
</criteria>
</definition>
Searching for "oval:ssg:tst:250", I find a stanza pointing to the
object_ref="oval:ssg:obj:1295" and
state_ref="oval:ssg:ste:1296".
<ind:textfilecontent54_test check="all" comment="check the
configuration of /etc/pam.d/system-auth" id="oval:ssg:tst:250"
version="1">
<ind:object object_ref="oval:ssg:obj:1295"/>
<ind:state state_ref="oval:ssg:ste:1296"/>
</ind:textfilecontent54_test>
Object 1295 is the check which matches the source code I found:
<ind:textfilecontent54_object id="oval:ssg:obj:1295"
version="1">
<ind:path>/etc/pam.d</ind:path>
<ind:filename>system-auth</ind:filename>
<ind:pattern operation="pattern
match">^[\s]*password[\s]+(?:(?:required)|(?:requisite))[\s]+[\w_\.\-=\s]+[\s]ucredit=(-?\d+)(?:[\s]|$)</ind:pattern>
<ind:instance datatype="int" operation="less than or
equal">1</ind:instance>
</ind:textfilecontent54_object>
That is good. My installed XML matches the source code tree I was
reviewing. But, I am still stuck with a failed check.
The state_ref="oval:ssg:ste:1296" points to a variable reference,
var_ref="oval:ssg:var:2120".
<ind:textfilecontent54_state id="oval:ssg:ste:1296"
version="1">
<ind:instance datatype="int">1</ind:instance>
<ind:subexpression datatype="int" operation="less than or
equal" var_ref="oval:ssg:var:2120"/>
</ind:textfilecontent54_state>
The variable reference, var_ref="oval:ssg:var:2120", points to
<external_variable comment="External variable for pam_cracklib
ucredit" datatype="int" id="oval:ssg:var:2120"
version="1"/>
I am not sure what an external variable is….but I did find it
referenced in the "ssg-rhel6-xccdf.xml" file as part of the Rule
id="password_require_uppercases".
<check
system="http://oval.mitre.org/XMLSchema/oval-definitions-5
<
https://urldefense.proofpoint.com/v1/url?u=http://oval.mitre.org/XMLSchem...
<check-export export-name="oval:ssg:var:2120"
value-id="var_password_pam_cracklib_ucredit"/>
<check-content-ref name="oval:ssg:def:249"
href="ssg-rhel6-oval.xml"/>
</check>
So, now I have a value-id="var_password_pam_cracklib_ucredit". I
searched some more….
Under the Profile <Profile id="stig-rhel6-server">, I find the
following:
<refine-value idref="var_password_pam_cracklib_ucredit"
selector="2"/>
I notice that the "dcredit" variable, which is passing, is
assigned a selector="1", but the others that were failing all had
a selector="2".
<refine-value idref="var_password_pam_cracklib_retry"
selector="3"/>
<refine-value idref="var_password_pam_cracklib_minlen"
selector="14"/>
<refine-value idref="var_password_pam_cracklib_dcredit"
selector="1"/>
<refine-value idref="var_password_pam_cracklib_ucredit"
selector="2"/>
<refine-value idref="var_password_pam_cracklib_ocredit"
selector="2"/>
<refine-value idref="var_password_pam_cracklib_lcredit"
selector="2"/>
<refine-value idref="var_password_pam_cracklib_difok"
selector="3"/>
On a whim, I changed my /etc/pam.d/system-auth line to use a value
of -2 as follows:
password requisite pam_cracklib.so try_first_pass retry=3
maxrepeat=3 minlen=14 dcredit=-1 ucredit=-2 ocredit=-2 lcredit=-2
difok=3
Now, I am passing the checks.
QUESTIONS:
1.Is the reasoning above correct in that a Profile can use
variables to set specific values to check against?
2.Did I uncover an incorrect variable value of selector="2" in the
stig-rhel6-server profile for the ucredit (and others) associated
to the pam_cracklib.so settings?
Thanks in advance for your time.
Robert
[1]
https://git.fedorahosted.org/cgit/scap-security-guide.git/tree/RHEL6/inpu...
<
https://urldefense.proofpoint.com/v1/url?u=https://git.fedorahosted.org/c...
[2]
http://www.myregextester.com/index.php
<
https://urldefense.proofpoint.com/v1/url?u=http://www.myregextester.com/i...
*Robert Hayden*| Sr. Technology Architect | Cerner Corporation |
816.201.4068 | rhayden(a)cerner.com <mailto:rhayden@cerner.com> |
www.cerner.com <
www.cerner.com>
CONFIDENTIALITY NOTICE This message and any included attachments
are from Cerner Corporation and are intended only for the
addressee. The information contained in this message is
confidential and may constitute inside or non-public information
under international, federal, or state securities laws.
Unauthorized forwarding, printing, copying, distribution, or use
of such information is strictly prohibited and may be unlawful. If
you are not the addressee, please promptly delete this message and
notify the sender of the delivery error by e-mail or you may call
Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1)
(816)221-1024.
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
<mailto:scap-security-guide@lists.fedorahosted.org>
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
<
https://urldefense.proofpoint.com/v1/url?u=https://lists.fedorahosted.org...
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide