scap-security-guide July 2013

scap-security-guide@lists.fedorahosted.org

23 participants
61 discussions

scap-security-guide v0.1-12 released
by Shawn Wells 25 Oct '13

25 Oct '13

On 2-MAY the SSG v0.1-11 update was released, reflecting the inclusion of DISA FSO feedback on the (then) Draft RHEL6 STIG and several OVAL improvements. It was a huge milestone, driving us over 1,800 unique code commits! We've since had an additional 88 commits, largely around OVAL content cleanup and the rewrite of combinefixes.py to handle parameters for OpenSCAP remediation generation (thanks, Jeff!). User feedback also prompted us to fix the build system when compiling on Fedora 18+ and the upcoming RHEL release. SSG v0.1-12 has been released to the EPEL repository to reflect these recent bugfixes and enhancements. Download instructions available on the wiki: https://fedorahosted.org/scap-security-guide/wiki/downloads CHANGELOG: > $ git log --oneline --after={2013-05-02} --no-merges > fe2a0b6 Some corrections to the PAM cracklib guidance as follows: > corrected pam_cracklib.so line to include all discussed parame > 532aeb8 Modified the DoD banner check to accept either a newline or > space between each word, as the RHEL5 version does. This al > ded2ef4 Created remediation template: create_services_disabled.py - > Based off OVAL services file > a96cdc3 Added sysctl remediation scripts - Updated template to reflect > proper naming of sysctl scripts > c3355eb Added bash templates directory, added sample sysctl script - > Makefile based off OVAL, same usage - CVS files point to > f75ad8d Module is freevxfs, not freevsfs > cd940ef Fix build of OpenStack and RHEVM3 parts on Fedora 18+ > df19413 Fix build on Fedora 18+ and the upcoming RHEL release > 2ddbbb7 Subexpression datatype shall equal to the variable datatype > 4cd7650 Ok, to fix the "error" doing an evaluation for the various > umask checks, changed the following variables referenced in t > 5fa190d changed a typo var_acocunts_umask_bashrc => > var_accounts_umask_bashrc > 7d772db Update from deprecated rpmverify_* to rpmverifyfile_* checks > 2026606 made xccdf-addfixes insert all text and child nodes of a fix > d6703f4 rewrite of combinefixes.py to handle parameters for OpenSCAP > remedation generation > c13fafa incomplete support file for bash remediations * does at least > warn when undefined variable exists > f87d817 example remediation script which takes a parameter > 24f2c2e Removing deprecated recurse="files" behavior > f078b8f Removing deprecated recurse=files behavior. > b12d669 Replacing deprecated <ind:environmentvariable_...> tags with > <ind:environmentvariable58_...> tags > 5ed6dc2 Created OVAL for ensure_gpgcheck_never_disabled XCCDF rule > called nonexisting OVAL, created it. > 0d69487 Renaming oval check no_rsh_trusted_host_files to > no_rsh_trust_files to match rule ID > 295184c Adding check for no_netrc_files > e1aede3 Adding check for pam_lastlog.so > 9c21556 additional copy editing > 3fd9f3f copy editing > 9db6e3d Renaming oval check no_rsh_trusted_host_files to > no_rsh_trust_files to match rule ID > 4109078 Adding check for no_netrc_files > 6f31c05 Adding check for pam_lastlog.so > 0e15e2d Adding check for disabling GNOME thumbnailers in gconf > d10f08e modified makefile to remove test attestation from prose guide > -- revised > 4f3ea5f corrections for typos in OVAL references > d50c71b removal of references to nonexistent OVAL for some NFS guidance > 980f686 refine verify-references to deal only with OVAL compliance > checks for OVAL > 6051ea6 removal of comments, reference to nonexistent OVAL > 8251580 removal or correction of misnamed or obsolete OVAL checks > 76e93ef removal of packages from check templates > 69f31e0 Added backslash escapes to the warning texts to fix the RegEx, > replaced line breaks with newlines, and added some m > c22ed9c Added backslash escapes to the warning texts to fix the RegEx, > replaced line breaks with newlines, and added some more f > c58ac2b Fixing indenting for external variable line. > 95d5a4b removal of unused OVAL checks > bcc1495 bugfixes for undisciplined renaming jaunt, missing OVAL references > 9a378b9 removal of unused OVAL checks > 3b82cf5 deletion of unused OVAL checks > 6a89088 removal of commented text, some redundant/unnecessary Rules > from Profiles > 9705192 deletion of unused/obsoleted OVAL checks (and commented out XCCDF) > 36a75ec deletion of unused OVAL checks > 48e9900 removal of unnecessary guidance from SSL section > 7682f9c removal of commented/obsolete text from logging section > a1f2d30 removal of commented text, invalid CCE from root logins guidance > 0a3577b update to NFS section (still perhaps incomplete) > 1a3d854 changed Dovecot Rule to Group as it is guidance and not a > compliance check > fb4a29b removal of commented/obsolete items for base services > 9a228d5 updates to the CCE verification script to be more informative > ff25fc9 cleanup of comments, unnecessary Rules in DNS (bind) service > 7a16cda Deleting duplicate check for disabling IPv6 > d9d1741 Minor typo, removing slash at end of description > 330258c added version info for RHEL, URL for project > f36ecf3 removed some now-obsolete advice from samba > 8d5ee52 added some clarifying text to the intro > 6c9f047 removing some unnecessary (for compliance-focus) text from cups > de705e9 Updated service_tftpd_disabled As reflected from update to > template file > 356405f Removed duplicate references to var_samba_private_directory > Updated OVAL to have unique IDs > 034b8b3 Removed duplicate references object_etc_skel_files Updated > OVAL to have unique names > d609d6b Removed duplicate var_ssh_config_directory references Updated > OVAL to have unique names > 8a7a3f3 Removed duplicate state_uid_root Updated OVAL to have unique names > e421d69 Modified template_OVAL_package_installed and > template_package_removed These files were causing build errors > regarding ob > 1ae4c30 Removed duplicate references to var_accounts_user_umask > Assigned unique identifiers > ea10f13 Removed duplicate references to object_lib_modules_files > Assigned unique identifiers > 882e341 Removed duplicate object_usr_lib64_files references Assigned > unique identifiers within OVAL > 9d89e61 Removed duplicate object_usr_lib64_dir references Assigned > unique identifiers in OVAL > 863aa19 Removed duplicate object_usr_lib_files references Assigned > unique identifiers to OVAL checks > 714c3c1 Removed duplicate object_usr_lib_dir Updated OVAL to have > unique names > dffd29b Removed duplicates of object_lib64_files Updated OVAL to have > unique names > bc6fbcd Removed duplicate object_lib64_dir Updated OVAL checks to have > unique names > fe089dc Removed duplicate object_lib_files Updated OVAL checks for > unique names > 7546f2e Removed duplicate object_lib_dir references Created unique > names in the OVAL templates > b376e27 Updated mount_option_* OVAL variable var_removable_partition > These OVAL files were using duplicate 'var_remove_partition > 7fae707 Updated template_permissions to place FILEID into strings > e31dc7b Updated state_gid_0 to reflect per check naming > 07380c0 Updated state_uid_0 names within OVAL Multiple OVAL checks > were using "state_uid_0" causing build errors. Updated so eve > f5b90ce Updated rpm_verify_hashes for OVAL 5.10 compliance The old > rpmverify_* is now depricated, updated check to rpmverifyfile > e3b5697 modified transform to only match test attestation > 02a19e2 transform designed to remove the 'tested by' information > a330ccf deleting files for imprecise and obsolete OVAL checks, manual > remediation > ca71cde simplification of Postfix service configuration > 14397cd Removing a newline to fix XHTML formatting > 7d1ab28 deletion of manual audit profile, OVAL for obsolete ldap > server checks > d7f3ca4 removed obsolete LDAP guidance, checks

1 1

intermittent failure of oval check, how to debug?
by Brian Millett 21 Aug '13

21 Aug '13

Ok, how do I go about debugging this: [root@deckard scap]# ./testcheck.py dir_perms_world_writable_sticky_bits.xml Evaluating with OVAL tempfile : /tmp/dir_perms_world_writable_sticky_bitshof67c.xml OpenSCAP Error: Unable to receive a message from probe [oval_probe_ext.c:583] [root@deckard scap]# ./testcheck.py dir_perms_world_writable_sticky_bits.xml Evaluating with OVAL tempfile : /tmp/dir_perms_world_writable_sticky_bitsLT_H5A.xml OpenSCAP Error: Unable to receive a message from probe [oval_probe_ext.c:583] [root@deckard scap]# ./testcheck.py dir_perms_world_writable_sticky_bits.xml Evaluating with OVAL tempfile : /tmp/dir_perms_world_writable_sticky_bits6eM3gu.xml OpenSCAP Error: Unable to receive a message from probe [oval_probe_ext.c:583] [root@deckard scap]# ./testcheck.py dir_perms_world_writable_sticky_bits.xml Evaluating with OVAL tempfile : /tmp/dir_perms_world_writable_sticky_bitsIWHsj4.xml Definition oval:scap-security-guide.testing:def:100: false The dir_perms_world_writable_sticky_bits test on ONE rhel6 machine is failing, but sometimes it does not. When I run an evaluation with the stig-rhel policy, I get OpenSCAP Error: Unable to receive a message from probe [oval_probe_ext.c:584] No definition with ID: oval:ssg:def:509 in result model. [oval_agent.c:182] -- Brian Millett "We are not through with the Centauri yet." -- [ G'Kar (to Jha'dur), "Deathwalker"]

3 5

Suggestion on the 'Ensure All Files Are Owned...' items
by Robert Sanders 07 Aug '13

07 Aug '13

I was wondering why the tests for 'Ensure all Files Are Owned by a User' and 'Ensure all Files are Owned by a Group' kept on failing. Drilling down it looks like the underlying find command being used is along the lines of : find PARTITION -xdev -nouser -print When I run this command manually I've had complaints that find can't read files in /proc. Looking at the man page suggests this can be avoided by adding the '-ignore_readdir_race' option before the -xdev option. This change may need to be added for both SSG items 2.2.3.e and 2.2.3.f -Rob

7 22

[PATCH 2/2] [bugfix] Updated XCCDF rule name of set_sysctl_ipv6_default_accept_redirects in profiles
by Shawn Wells 07 Aug '13

07 Aug '13

2 1

[PATCH 1/2] Added bash remediation check to verify-input-sanity.py
by Shawn Wells 07 Aug '13

07 Aug '13

2 1

New tested field for OVAL Checks
by Maura Dailey 06 Aug '13

06 Aug '13

Going forward, we're going to use <reference> tags inside of OVAL checks to track if they've been tested. An example is as follows: |<reference ||source="MED" ref_id="20130731" ref_url="test_attestation" />| Source should uniquely identify the tester (here, I used my initials); ref_id should be in the format YYYYMMDD. We'll probably be adding empty tags into all the checks to get everyone started. This is similar to the <tested> tag in XCCDF, which is converted into an XCCDF <reference> tag during our build process. Here is an example of the <reference> tag in an existing check. Note that it comes just after the description tag, inside of <metadata>. |<def-group>|| || <definition class="compliance" id="file_permissions_etc_group" version="1">|| || <metadata>|| || <title>Verify permissions on 'group' file</title>|| || <affected family="unix">|| || <platform>Red Hat Enterprise Linux 6</platform>|| || </affected>|| || <description>File permissions for /etc/group should be set correctly.</description>|| || <reference source="MED" ref_id="20130731" ref_url="test_attestation"/>|| || </metadata>|| || <criteria>|| || <criterion test_ref="file_permissions_etc_group_test" />|| || </criteria>|| || </definition>|| || <unix:file_test check="all" check_existence="all_exist" comment="Testing /etc/group permissions" id="file_permissions_etc_group_test" version="1">|| || <unix:object object_ref="file_permissions_etc_group_object" />|| || <unix:state state_ref="file_permissions_etc_group_state" />|| || </unix:file_test>|| || <unix:file_state id="file_permissions_etc_group_state" version="1">|| || <unix:uread datatype="boolean">true</unix:uread>|| || <unix:uwrite datatype="boolean">true</unix:uwrite>|| || <unix:uexec datatype="boolean">false</unix:uexec>|| || <unix:gread datatype="boolean">true</unix:gread>|| || <unix:gwrite datatype="boolean">false</unix:gwrite>|| || <unix:gexec datatype="boolean">false</unix:gexec>|| || <unix:oread datatype="boolean">true</unix:oread>|| || <unix:owrite datatype="boolean">false</unix:owrite>|| || <unix:oexec datatype="boolean">false</unix:oexec>|| || </unix:file_state>|| || <unix:file_object comment="/etc/group" id="file_permissions_etc_group_object" version="1">|| || <unix:path>/etc</unix:path>|| || <unix:filename>group</unix:filename>|| || </unix:file_object>|| ||</def-group>| - Maura Dailey

3 4

telnet section
by Stuart Green 05 Aug '13

05 Aug '13

Greetings All, New to this list! I think I might have found an issue with the SSG policy content. Summary: If you do not have telnet installed on the system it causes Rule ID: disable_telnet_service to fail. In no place in this rule does it consider that telnet might not be installed at all, so it fails (rather than errors, or even better does a check as a precursor to see if its installed at all and if not passes!) grep 'id="oval:ssg:tst:231"' ssg-rhel6-oval.xml.result.xml <ind-def:textfilecontent54_test id="oval:ssg:tst:231" version="1" check_existence="all_exist" check="all" comment="Disable Telnet Service"> <test test_id="oval:ssg:tst:231" version="1" check_existence="all_exist" check="all" result="false"/> <Rule id="disable_telnet_service" selected="false" severity="high"> <title xml:lang="en-US">Disable telnet Service</title> <description xmlns:xhtml="http://www.w3.org/1999/xhtml" xml:lang="en-US"> The <xhtml:code>telnet</xhtml:code> service can be disabled with the following command: <xhtml:pre># chkconfig telnet off</xhtml:pre> </description> <reference href="http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.…">AC-17(8)</reference> <reference href="http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.…">CM-7</reference> <reference href="http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.…">IA-5(1)(c)</reference> <reference href="http://iase.disa.mil/cci/index.html">68</reference> <reference href="http://iase.disa.mil/cci/index.html">1436</reference> <reference href="http://iase.disa.mil/cci/index.html">197</reference> <reference href="http://iase.disa.mil/cci/index.html">877</reference> <reference href="http://iase.disa.mil/cci/index.html">888</reference> <reference xmlns:dc="http://purl.org/dc/elements/1.1/" href="test_attestation"> <dc:contributor>DS</dc:contributor> <dc:date>20121026</dc:date> </reference> <rationale xmlns:xhtml="http://www.w3.org/1999/xhtml" xml:lang="en-US"> The telnet protocol uses unencrypted network communication, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network. The telnet protocol is also subject to man-in-the-middle attacks. </rationale> <ident system="http://cce.mitre.org">CCE-26836-7</ident> <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> <check-content-ref name="oval:ssg:def:230" href="ssg-rhel6-oval.xml"/> </check> <check system="ocil-transitional"> <check-export export-name="the service is running" value-id="conditional_clause"/> <check-content xmlns:xhtml="http://www.w3.org/1999/xhtml"> To check that the <xhtml:code>telnet</xhtml:code> service is disabled in system boot configuration, run the following command: <xhtml:pre># chkconfig <xhtml:code>telnet</xhtml:code> --list</xhtml:pre> Output should indicate the <xhtml:code>telnet</xhtml:code> service has either not been installed, or has been disabled at all runlevels, as shown in the example below: <xhtml:pre># chkconfig <xhtml:code>telnet</xhtml:code> --list <xhtml:code>telnet</xhtml:code> 0:off 1:off 2:off 3:off 4:off 5:off 6:off</xhtml:pre> Run the following command to verify <xhtml:code>telnet</xhtml:code> is disabled through current runtime configuration: <xhtml:pre># service telnet status</xhtml:pre> If the service is disabled the command will return the following output: <xhtml:pre>telnet is stopped</xhtml:pre> </check-content> </check> </Rule> Cheers, Stu

7 9

[PATCH] Adding new OVAL check that will parse /etc/passwd, looking for system accounts with real login shells (not /sbin/nologin).
by Maura Dailey 01 Aug '13

01 Aug '13

Here's one more patch to clean up 'make validate' just a teensy bit more. This one required a lot of testing due to complicated regex. - Maura Dailey Signed-off-by: Maura Dailey <maura(a)eclipse.ncsc.mil> --- .../accounts_no_shelllogin_for_systemaccounts.xml | 23 ++++++++++++++++++++ .../system/accounts/restrictions/root_logins.xml | 2 +- 2 files changed, 24 insertions(+), 1 deletions(-) create mode 100644 RHEL6/input/checks/accounts_no_shelllogin_for_systemaccounts.xml diff --git a/RHEL6/input/checks/accounts_no_shelllogin_for_systemaccounts.xml b/RHEL6/input/checks/accounts_no_shelllogin_for_systemaccounts.xml new file mode 100644 index 0000000..a5b9334 --- /dev/null +++ b/RHEL6/input/checks/accounts_no_shelllogin_for_systemaccounts.xml @@ -0,0 +1,23 @@ +<def-group> + <definition class="compliance" id="accounts_no_shelllogin_for_systemaccounts" version="1"> + <metadata> + <title>System Accounts Do Not Run a Shell</title> + <affected family="unix"> + <platform>Red Hat Enterprise Linux 6</platform> + </affected> + <description>The root account is the only system account that should have a login shell.</description> + </metadata> + <criteria> + <criterion comment="tests for the presence of login shells (not /sbin/nologin) for system accounts in /etc/passwd file" test_ref="test_accounts_no_shelllogin_for_systemaccounts" /> + </criteria> + </definition> + <ind:textfilecontent54_test check="all" check_existence="none_exist" comment="tests for the presence of login shells (not /sbin/nologin) for system accounts in /etc/passwd file" id="test_accounts_no_shelllogin_for_systemaccounts" version="1"> + <ind:object object_ref="object_accounts_no_shelllogin_for_systemaccounts" /> + </ind:textfilecontent54_test> + <ind:textfilecontent54_object id="object_accounts_no_shelllogin_for_systemaccounts" version="1"> + <ind:path>/etc</ind:path> + <ind:filename>passwd</ind:filename> + <ind:pattern operation="pattern match">^(?!.*root).*:x:[\d]*:0*([0-9]{1,2}|[1-4][0-9]{2}):[^:]*:[^:]*:(?!\/sbin\/nologin).*$</ind:pattern> + <ind:instance datatype="int">1</ind:instance> + </ind:textfilecontent54_object> +</def-group> diff --git a/RHEL6/input/system/accounts/restrictions/root_logins.xml b/RHEL6/input/system/accounts/restrictions/root_logins.xml index f9b6aa2..1f2a840 100644 --- a/RHEL6/input/system/accounts/restrictions/root_logins.xml +++ b/RHEL6/input/system/accounts/restrictions/root_logins.xml @@ -158,7 +158,7 @@ section on the root account. Doing so might cause the system to become inaccessible. </warning> <ident cce="26966-2" /> -<oval id="no_shelllogin_for_systemaccounts" /> +<oval id="accounts_no_shelllogin_for_systemaccounts" /> <ref nist="" disa="178" /> <tested by="DS" on="20121024"/> </Rule> -- 1.7.1

3 6

Incorrect Profile variable for stig-rhel6-server?
by Hayden,Robert 31 Jul '13

31 Jul '13

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"> <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/input/… [2] http://www.myregextester.com/index.php Robert Hayden | Sr. Technology Architect | Cerner Corporation | 816.201.4068 | rhayden(a)cerner.com<mailto:rhayden@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.

2 3

[PATCH 0/3] refactoring of shorthand->xccdf transforms
by Jeffrey Blank 30 Jul '13

30 Jul '13

I've moved the namespace-assignment templates from shorthand2xccdf.xslt to xccdf-addnamespaces.xslt (which is itself a renamed version of the transform Simon provided to us, to place all un-namespaced elements into the XCCDF namespace). This refactoring seemed to make sense, as it separates the macro expansion activities from the namespace assignment activities. Going forward, I plan to explore: A. Deleting the xccdf-addprofiles.xslt transform entirely, in favor of simply including its functionality directly in input/guide.xslt. B. Further simplification of some of the lines in shorthand2xccdf.xslt, with use of "{}" etc to further shorten overall number of lines. C. Activating (perhaps using xsl:import and @mode) the namespace-specific transformations currently in xccdf-addnamespace.xslt from within shorthand2xccdf.xslt. This would have the benefit of actually producing XCCDF, as the name shorthand2xccdf already suggests... This would also help simplify the Makefile. Jeffrey Blank (3): refactoring of XCCDF shorthand expansion and namespace assignments removing namespaces from no-namespace fragments, transforms renaming namespace addition file, as part of refactoring RHEL6/Makefile | 4 +- RHEL6/input/profiles/CS2.xml | 2 +- RHEL6/input/profiles/common.xml | 2 +- RHEL6/input/profiles/desktop.xml | 2 +- RHEL6/input/profiles/fisma-medium-rhel6-server.xml | 2 +- RHEL6/input/profiles/nist-CL-IL-AL.xml | 2 +- RHEL6/input/profiles/server.xml | 2 +- RHEL6/input/profiles/stig-rhel6-server.xml | 2 +- RHEL6/input/profiles/test.xml | 2 +- RHEL6/input/profiles/usgcb-rhel6-server.xml | 2 +- RHEL6/transforms/add_xccdf_namespace.xslt | 15 --- RHEL6/transforms/shorthand2xccdf.xslt | 108 ++++---------------- RHEL6/transforms/xccdf-addnamespaces.xslt | 49 +++++++++ RHEL6/transforms/xccdf-addprofiles.xslt | 6 +- 14 files changed, 81 insertions(+), 119 deletions(-) delete mode 100644 RHEL6/transforms/add_xccdf_namespace.xslt create mode 100644 RHEL6/transforms/xccdf-addnamespaces.xslt

2 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide July 2013