scap-security-guide October 2015

scap-security-guide@lists.fedorahosted.org

12 participants
9 discussions

when is dual ARCH required in audit.rules?
by Robert Jacobson 04 Nov '15

04 Nov '15

I've recently been trying to reconcile the audit.rules on my systems vs. the scap-security-guide, and I'm confused about the ARCH rules. When is it required to check both 32- and 64-bit architectures? e.g. the guide says both 32- and 64-bit rules are required to check for unauthorized access attempts: # Unauthorized Access attempts (audit_rules_unsuccessful_file_modification) -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=500 -F auid!=4294967295 -k access -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=500 -F auid!=4294967295 -k access -a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=500 -F auid!=4294967295 -k access -a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=500 -F auid!=4294967295 -k access But for modifying the network environment, only the 64-bit rule is required: # Network changes ( audit_rules_networkconfig_modification ) -a always,exit -F arch=b64 -S sethostname -S setdomainname -k audit_rules_networkconfig_modification I don't understand why the 32-bit check is required for open() calls but not sethostname() calls? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Robert Jacobson Robert.C.Jacobson(a)nasa.gov Lead System Admin Solar Dynamics Observatory (SDO) Bldg 14, E222 (301) 286-1591

5 7

[PATCH 1/1] Update LUKS Disk encryption URL
by Steve Grubb 22 Oct '15

22 Oct '15

The link to the advice on how to setup a LUKS encrypted partition points to the wrong place. This patch corrects the link so that clicking the link takes you to the text. Signed-off-by: sgrubb <sgrubb(a)redhat.com> --- RHEL/6/input/system/software/disk_partitioning.xml | 2 +- shared/references/disa-stig-rhel6-v1r5-xccdf-manual.xml | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/RHEL/6/input/system/software/disk_partitioning.xml b/RHEL/6/input/system/software/disk_partitioning.xml index 521003e..677b446 100644 --- a/RHEL/6/input/system/software/disk_partitioning.xml +++ b/RHEL/6/input/system/software/disk_partitioning.xml @@ -148,7 +148,7 @@ installer to pause and interactively ask for the passphrase during installation. <br /><br /> Detailed information on encrypting partitions using LUKS can be found on the Red Hat Documentation web site:<br /> -https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html +https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-Security_Guide-Encryption.html#sect-Security_Guide-LUKS_Disk_Encryption </description> <ocil clause="encryption must be used and is not employed"> Determine if encryption must be used to protect data on the system. diff --git a/shared/references/disa-stig-rhel6-v1r5-xccdf-manual.xml b/shared/references/disa-stig-rhel6-v1r5-xccdf-manual.xml index aeba70b..c9d362b 100644 --- a/shared/references/disa-stig-rhel6-v1r5-xccdf-manual.xml +++ b/shared/references/disa-stig-rhel6-v1r5-xccdf-manual.xml @@ -9698,7 +9698,7 @@ part / --fstype=ext3 --size=100 --onpart=hda1 --encrypted --passphrase=[PASSPHRA Any [PASSPHRASE] is stored in the Kickstart in plaintext, and the Kickstart must then be protected accordingly. Omitting the "--passphrase=" option from the partition definition will cause the installer to pause and interactively ask for the passphrase during installation. Detailed information on encrypting partitions using LUKS can be found on the Red Had Documentation web site: -https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html</fixtext> +https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-Security_Guide-Encryption.html#sect-Security_Guide-LUKS_Disk_Encryption</fixtext> <fix id="F-43609r1_fix"/> <check system="C-46220r1_chk"> <check-content-ref name="M" href="DPMS_XCCDF_Benchmark_RHEL_6_STIG.xml"/> @@ -9764,7 +9764,7 @@ part / --fstype=ext3 --size=100 --onpart=hda1 --encrypted --passphrase=[PASSPHRA Any [PASSPHRASE] is stored in the Kickstart in plaintext, and the Kickstart must then be protected accordingly. Omitting the "--passphrase=" option from the partition definition will cause the installer to pause and interactively ask for the passphrase during installation. Detailed information on encrypting partitions using LUKS can be found on the Red Had Documentation web site: -https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html</fixtext> +https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-Security_Guide-Encryption.html#sect-Security_Guide-LUKS_Disk_Encryption</fixtext> <fix id="F-43610r1_fix"/> <check system="C-46221r1_chk"> <check-content-ref name="M" href="DPMS_XCCDF_Benchmark_RHEL_6_STIG.xml"/> @@ -9799,7 +9799,7 @@ part / --fstype=ext3 --size=100 --onpart=hda1 --encrypted --passphrase=[PASSPHRA Any [PASSPHRASE] is stored in the Kickstart in plaintext, and the Kickstart must then be protected accordingly. Omitting the "--passphrase=" option from the partition definition will cause the installer to pause and interactively ask for the passphrase during installation. Detailed information on encrypting partitions using LUKS can be found on the Red Had Documentation web site: -https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html</fixtext> +https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-Security_Guide-Encryption.html#sect-Security_Guide-LUKS_Disk_Encryption</fixtext> <fix id="F-43611r1_fix"/> <check system="C-46222r1_chk"> <check-content-ref name="M" href="DPMS_XCCDF_Benchmark_RHEL_6_STIG.xml"/> -- 2.4.3

2 1

[PATCH 1/1] Wrong SE Linux type used
by Steve Grubb 22 Oct '15

22 Oct '15

During a recent review, it was found that the text written did not use the correct selinux type. This means it will not find the system problem that the text was describing. Signed-off-by: sgrubb <sgrubb(a)redhat.com> --- Fedora/input/system/selinux.xml | 9 ++++----- RHEL/6/input/checks/selinux_all_devicefiles_labeled.xml | 10 +++++----- RHEL/6/input/system/selinux.xml | 7 +++---- RHEL/7/input/system/selinux.xml | 5 ++--- shared/references/disa-stig-rhel6-v1r5-xccdf-manual.xml | 6 +++--- 5 files changed, 17 insertions(+), 20 deletions(-) diff --git a/Fedora/input/system/selinux.xml b/Fedora/input/system/selinux.xml index f0e234b..f837dba 100644 --- a/Fedora/input/system/selinux.xml +++ b/Fedora/input/system/selinux.xml @@ -167,17 +167,16 @@ or allow privileges that the daemon does not require. </Rule> <Rule id="selinux_all_devicefiles_labeled"> -<title>Ensure No Device Files are Unlabeled by SELinux</title> +<title>Ensure No Device Files are Unknown to SELinux</title> <description>Device files, which are used for communication with important system resources, should be labeled with proper SELinux types. If any device -files carry the SELinux type <tt>unlabeled_t</tt>, investigate the cause and -correct the file's context. +files carry the SELinux type <tt>device_t</tt>, report the bug so that policy can be corrected. Supply information about what the device is and what programs use it. </description> -<ocil clause="there is output">To check for unlabeled device files, run the following command: +<ocil clause="there is output">To check for unknown device files, run the following command: <pre>$sudo find /dev -context *:device_t:* $ -type c -o -type b $ -printf "%p %Z\n"</pre> It should produce no output in a well-configured system.</ocil> <rationale> -If a device file carries the SELinux type <tt>unlabeled_t</tt>, then SELinux +If a device file carries the SELinux type <tt>device_t</tt>, then SELinux cannot properly restrict access to the device file. </rationale>  diff --git a/RHEL/6/input/checks/selinux_all_devicefiles_labeled.xml b/RHEL/6/input/checks/selinux_all_devicefiles_labeled.xml index 3e99347..094225f 100644 --- a/RHEL/6/input/checks/selinux_all_devicefiles_labeled.xml +++ b/RHEL/6/input/checks/selinux_all_devicefiles_labeled.xml @@ -5,23 +5,23 @@ <affected family="unix"> <platform>Red Hat Enterprise Linux 6</platform> </affected> - <description>All device files in /dev should be assigned an SELinux security context other than 'unlabeled_t'.</description> + <description>All device files in /dev should be assigned an SELinux security context other than 'device_t'.</description> </metadata> <criteria> - <criterion comment="unlabeled_t in /dev" test_ref="test_selinux_all_devicefiles_labeled" /> + <criterion comment="device_t in /dev" test_ref="test_selinux_all_devicefiles_labeled" /> </criteria> </definition> - <linux:selinuxsecuritycontext_test check="none satisfy" check_existence="any_exist" comment="unlabeled_t in /dev" id="test_selinux_all_devicefiles_labeled" version="2"> + <linux:selinuxsecuritycontext_test check="none satisfy" check_existence="any_exist" comment="device_t in /dev" id="test_selinux_all_devicefiles_labeled" version="2"> <linux:object object_ref="object_selinux_all_devicefiles_labeled" /> <linux:state state_ref="state_selinux_all_devicefiles_labeled" /> </linux:selinuxsecuritycontext_test> - <linux:selinuxsecuritycontext_object comment="unlabeled_t in /dev" id="object_selinux_all_devicefiles_labeled" version="1"> + <linux:selinuxsecuritycontext_object comment="device_t in /dev" id="object_selinux_all_devicefiles_labeled" version="1"> <linux:behaviors recurse_direction="down" /> <linux:path>/dev</linux:path> <linux:filename operation="pattern match">^.*$</linux:filename> <filter action="include">state_selinux_all_devicefiles_labeled</filter> </linux:selinuxsecuritycontext_object> <linux:selinuxsecuritycontext_state comment="do it" id="state_selinux_all_devicefiles_labeled" version="1"> - <linux:type datatype="string" operation="equals">unlabeled_t</linux:type> + <linux:type datatype="string" operation="equals">device_t</linux:type> </linux:selinuxsecuritycontext_state> </def-group> diff --git a/RHEL/6/input/system/selinux.xml b/RHEL/6/input/system/selinux.xml index 5118427..e54f6ef 100644 --- a/RHEL/6/input/system/selinux.xml +++ b/RHEL/6/input/system/selinux.xml @@ -191,17 +191,16 @@ or allow privileges that the daemon does not require. </Rule> <Rule id="selinux_all_devicefiles_labeled"> -<title>Ensure No Device Files are Unlabeled by SELinux</title> +<title>Ensure No Device Files are Unknown to SELinux</title> <description>Device files, which are used for communication with important system resources, should be labeled with proper SELinux types. If any device -files carry the SELinux type <tt>unlabeled_t</tt>, investigate the cause and -correct the file's context. +files carry the SELinux type <tt>device_t</tt>, report the bug so that policy can be corrected. Supply information about what the device is and what programs use it. </description> <ocil clause="there is output">To check for unlabeled device files, run the following command: <pre>$ sudo find /dev -context *:device_t:* $ -type c -o -type b $ -printf "%p %Z\n"</pre> It should produce no output in a well-configured system.</ocil> <rationale> -If a device file carries the SELinux type <tt>unlabeled_t</tt>, then SELinux +If a device file carries the SELinux type <tt>device_t</tt>, then SELinux cannot properly restrict access to the device file. </rationale> <ident cce="26774-0" stig="RHEL-06-000025" /> diff --git a/RHEL/7/input/system/selinux.xml b/RHEL/7/input/system/selinux.xml index 98d5b83..ed3896a 100644 --- a/RHEL/7/input/system/selinux.xml +++ b/RHEL/7/input/system/selinux.xml @@ -177,14 +177,13 @@ or allow privileges that the daemon does not require. <title>Ensure No Device Files are Unlabeled by SELinux</title> <description>Device files, which are used for communication with important system resources, should be labeled with proper SELinux types. If any device -files carry the SELinux type <tt>unlabeled_t</tt>, investigate the cause and -correct the file's context. +files carry the SELinux type <tt>device_t</tt>, report the bug so that policy can be corrected. Supply information about what the device is and what programs use it. </description> <ocil clause="there is output">To check for unlabeled device files, run the following command: <pre>$sudo find /dev -context *:device_t:* $ -type c -o -type b $ -printf "%p %Z\n"</pre> It should produce no output in a well-configured system.</ocil> <rationale> -If a device file carries the SELinux type <tt>unlabeled_t</tt>, then SELinux +If a device file carries the SELinux type <tt>device_t</tt>, then SELinux cannot properly restrict access to the device file. </rationale> <ident cce="27326-8" /> diff --git a/shared/references/disa-stig-rhel6-v1r5-xccdf-manual.xml b/shared/references/disa-stig-rhel6-v1r5-xccdf-manual.xml index aeba70b..24feac9 100644 --- a/shared/references/disa-stig-rhel6-v1r5-xccdf-manual.xml +++ b/shared/references/disa-stig-rhel6-v1r5-xccdf-manual.xml @@ -11306,7 +11306,7 @@ If it does not, this is a finding. </check-content> <Rule id="SV-65589r1_rule" severity="low" weight="10.0"> <version>RHEL-06-000025</version> <title>All device files must be monitored by the system Linux Security Module.</title> - <description><VulnDiscussion>If a device file carries the SELinux type "unlabeled_t", then SELinux cannot properly restrict access to the device file. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls></description> + <description><VulnDiscussion>If a device file carries the SELinux type "device_t", then SELinux cannot properly restrict access to the device file. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls></description> <reference> <dc:title>DPMS Target Red Hat 6</dc:title> <dc:publisher>DISA FSO</dc:publisher> @@ -11315,13 +11315,13 @@ If it does not, this is a finding. </check-content> <dc:identifier>2367</dc:identifier> </reference> <ident system="http://iase.disa.mil/cci">CCI-000366</ident> - <fixtext fixref="F-56179r1_fix">Device files, which are used for communication with important system resources, should be labeled with proper SELinux types. If any device files carry the SELinux type "unlabeled_t", investigate the cause and correct the file's context. </fixtext> + <fixtext fixref="F-56179r1_fix">Device files, which are used for communication with important system resources, should be labeled with proper SELinux types. If any device files carry the SELinux type "device_t", report the bug so that policy can be corrected. Supply information about what the device is and what programs use it. </fixtext> <fix id="F-56179r1_fix"/> <check system="C-53719r1_chk"> <check-content-ref name="M" href="DPMS_XCCDF_Benchmark_RHEL_6_STIG.xml"/> <check-content>To check for unlabeled device files, run the following command: -# ls -RZ /dev | grep unlabeled_t +# ls -RZ /dev | grep device_t It should produce no output in a well-configured system. -- 2.4.3

2 1

SCAP Security Guide 0.1.26 is now available for download
by Jan Lieskovsky 20 Oct '15

20 Oct '15

Hello folks, we are pleased to announce the latest 0.1.26 version of the SCAP Security Guide project is now available for download. Highlights include: * New OS Protection Profile for Red Hat Enterprise Linux 7 Server, * PCI-DSS profile implementation (all OVALs, remediations, and official ID mappings) for Red Hat Enterprise Linux 7 Server finished, * Remediation scripts now support multi_platform tags (replacement for former use of symbolic links), * The version of SCAP Security Guide is now included in the RHEL/5, RHEL/6, RHEL/7, Chromium, Fedora, JRE, RHEVM3, Webmin, and Firefox benchmarks, * Numerous XCCDF, OVAL, and remediation scripts enhancements and bug fixes For a more detailed list of XCCDF / OVAL / remediations / infrastructure changes (bug fixes and enhancements) please check the 0.1.26 release notes page: [1] https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.26 For a convenience provided are also Zip archives of the both versions of the new release. Be sure to check them out: * https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.26/s… contains collection of DataStream formatted benchmarks for most recent OVAL-5.11 language version, while * https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.26/s… contains collection of DataStream formatted benchmarks produced for OVAL-5.10 language version. Should you experience an issue with any of these, please report here or at: [2] https://github.com/OpenSCAP/scap-security-guide/issues/new Many thanks to all of the contributors who have made this new release possible! Happy hardening, Jan -- Jan iankko Lieskovsky (on behalf of the SCAP Security Guide upstream team)

1 0

Re: [Open-scap] Contribution to OpenSCAP with Jenkins - blogpost
by Jan Lieskovsky 20 Oct '15

20 Oct '15

Hello Zbynek, ----- Original Message ----- > From: "Zbynek Moravec" <zmoravec(a)redhat.com> > To: open-scap-list(a)redhat.com > Sent: Tuesday, October 20, 2015 11:12:25 AM > Subject: [Open-scap] Contribution to OpenSCAP with Jenkins - blogpost > > Hello, > > I have written short blog post which should gives you some basic information > about > testing of pull requests to OpenSCAP/SSG with Jenkins. > > https://blog-zbynek.rhcloud.com/2015/10/12/contribution-to-openscap-with-je… > > Feedback is welcome. Very nice!, adding SSG mailing list to the CC too (for wider audience). Thank you && Regards, Jan -- Jan iankko Lieskovsky / Red Hat Security Technologies Team > > Zbyněk Moravec > Security Technologies | Red Hat, Inc. > > _______________________________________________ > Open-scap-list mailing list > Open-scap-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list

1 0

Insight into release timing of RHEL7 STIG as "official" -- any help needed on the Project?
by Jeffrey Hawkins 13 Oct '15

13 Oct '15

Anyone have any insight on when the RHEL7 STIG is going to be ready for prime time to be picked up by DISA? I work for a company the delivers RHEL based Products that use the STIG as part of the Security Standards /Benchmark to follow, and right now we are middle of development cycle of migrating our Products from RHEL6 to RHEL7. We are leveraging existing RHEL6 STIG, and the early RHEL7 drafts where it make sense within our own Hardening Framework (developed and carried forward from pre-RHEL4 days). We would like to avoid what we faced with RHEL6 with chasing the Draft verses RHEL5 STIG, and speculating what would be in the final . So, thought I would raise a query of the Benchmark rollout... Are there areas where help is needed as I/we would be more than happy to help the Project? Thanks, Jeff

8 10

SCAP Evaluation of Virtual Machines
by Martin Preisler 13 Oct '15

13 Oct '15

I have written a script called `oscap-vm` that allows users to evaluate virtual machines and their images. It does not require oscap to be installed inside the virtual machine so it performs the so called "agent-less" SCAP evaluation. The script will be part of the next OpenSCAP 1.2.7 release. When evaluating it mounts the virtual machine storage in read-only mode and then performs offline oscap evaluation on it. I made the CLI syntax similar to oscap-ssh and oscap-docker so it should feel very familiar. It is possible to scan virtual machines that are powered off but you can also scan virtual machines while they are running with no risk of data loss! Examples: $ wget http://www.redhat.com/security/data/oval/Red_Hat_Enterprise_Linux_7.xml $ oscap-vm domain rhel7.2 oval eval Red_Hat_Enterprise_Linux_7.xml $ oscap-vm domain rhel7.2 xccdf eval --profile \ xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream \ /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml $ oscap-vm image /var/lib/libvirt/images/rhel7.2.qcow2 xccdf eval --profile \ xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream \ /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml Read more: http://martin.preisler.me/2015/10/evaluate-virtual-machines-for-scap-compli… https://github.com/OpenSCAP/openscap/pull/175 https://github.com/OpenSCAP/openscap/blob/maint-1.2/utils/oscap-vm.8 -- Martin Preisler Security Technologies | Red Hat, Inc.

1 0

Fed50 Voting Open: Jeff Blank for "Disruptor of the Year"
by Shawn Wells 06 Oct '15

06 Oct '15

Our fellow OpenSCAP-er, Jeff Blank, has been nominated for Fed50 "Disruptor of the Year" in recognition for his C&A work. Want to see Jeff win as bad as I do? You can help in literally 2 clicks. Voting ends 2-NOV. http://fedscoop.com/events/fedscoop50/#disruptor-of-the-year Why Jeff? He's the co-founder of the SCAP Security Guide and has been working tirelessly to make C&A less expensive, faster, and do so using open source. Jeff has also been a great ally of OpenSCAP as demonstrated at the Red Hat Summit... https://dgshow.org/2015/10/98-not-that-nsa/ Personally, I've co-presented with Jeff for the past 2 years at Red Hat Summit. You can find our decks here: - http://blog-shawndwells.rhcloud.com/wp-content/uploads/2015/06/2015-06-25-S… - http://blog-shawndwells.rhcloud.com/wp-content/uploads/2012/07/2014-04-17-S… Jeff also open sourced the development of Common Criteria protection profiles, which can be found on GitHub: https://github.com/commoncriteria To achieve this open source awesomeness, Jeff worked with DoD Legal to attain broad permissions for DoD/IC/Civ/Integrators to contribute back to open source. This alone is worth a "Disruptor" award!

2 1

Memory allocation errors on RHEL6
by Chuck Atkins 06 Oct '15

06 Oct '15

I just did a fresh install of RHEL6, with minimal desktop configuration, applied all updates, and installed scap-security-guide, openscap, and scap-workbench from the system repos. First I created a tailoring file with SCAP Workbench to adjust the STIG server profile for desktop usage (allow X, remove various server packages, etc.). The scan worked fine but when generating the results and report, I get a bunch of memory allocation errors. When I tried to evaluate from the command line instead, using the tailoring file from scap-workbench, I get: [root@rhel6-stig-vm ~]# oscap xccdf eval \ --tailoring-file ssg-rhel6-kw-desktop-xccdf.xml \ --profile xccdf_kitware.com_profile_stig-rhel6-server-upstream_desktop \ --report ssg-report.html --results ssg-results.xml \ --check-engine-results --oval-results \ /usr/share/xml/scap/ssg/content/ssg-rhel6-ds.xml ... all benchmark rules process ... XPath error : Memory allocation failed : growing nodeset hit limit growing nodeset hit limit ^ runtime error: file /usr/share/openscap/xsl/xccdf-report-oval-details.xsl line 39 element key Failed to evaluate the 'match' expression. (error repeated 4 times) The RPMs installed as reported by yum are: openscap-utils.x86_64 1.2.4-1.el6_6sat @rhel-6-workstation-satellite-tools-6.1-rpms scap-security-guide.noarch 0.1.21-3.el6 @rhel-6-workstation-rpms [root@rhel6-stig-vm ~]# Interestingly, I don't seem to get these memory errors when I run against the xccdf directly and not the combined datastream, but then I can't use the tailoring file I created. Any ideas on the memory errors? - Chuck

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide October 2015