it's my pleasure and honor to announce that SCAP Security Guide
release 0.1.30 has been created and is now available for download.
Highlights of this release:
* CNSS No.1253 (nist-CL-IL-AL) profile has been ported to Red Hat
Enterprise Linux 7,
* SCAP benchmark for Red Hat Enterprise Linux 7 now passes official
NIST SCAP ScapVal-18.104.22.168 content validation tool requirements,
* The XCCDF rules for Red Hat Enterprise Linux 7 has been equipped
with CCE identifiers,
* New CJIS "Criminal Justice Information Services (CJIS) Security Policy"
profile has been added to Red Hat Enterprise Linux 7 benchmark,
* Profile for each ANSSI hardening level for NP targets has been
added to Debian 8 benchmark,
* Remediation scripts don't rely on external
/usr/share/scap-security-guide/remediation_functions shell library
any more (instead starting from this release the remediation scripts
are part of the specific benchmark itself). This allows to perform
remediation without the need to have scap-security-guide RPM package
For a more detailed overview of changes (bug fixes, enhancements)
implemented in this release please have a look at more detailed changelog:
Full changelog at:
Zip archives with pre-built benchmarks in DataStream form:
(Zip archive using OVAL-5.11.1 language version)
(Zip archive using OVAL-5.10 language version)
Jan iankko Lieskovsky (on behalf of the SCAP Security Guide upstream team)
Is there a roadmap for a final implementation of the RHEL 7 SSG? I'm curious when I can build a security baseline based off of the SCAP Security Guide for RHEL 7.
We happen to be running Oracle Linux if there's any impact based on that particular OS.
Thanks so much,
Matthew Wilkinson | Lead Server Administrator, Unix
200 1st St. SE | Cedar Rapids, IA 52401
Office: (319) 786-7694
alliantenergy.com<http://www.alliantenergy.com/> I MatthewWilkinson(a)alliantenergy.com<mailto:MatthewWilkinson@alliantenergy.com>
This e-mail message is intended only for the personal use of the recipient(s) named above. This message may be an attorney-client communication and as such privileged and confidential. If you are not an intended recipient, you may not review, copy or distribute this message. If you have received this communication in error, please notify us immediately by e-mail and delete the original message.
I am having an issue with OVAL test file_permissions_ungroupowned in CentOS
5. I believe it is a bug in the oscap version that it is available in
CentOS 5 (kind of old, v1.0.8).
Here is the procedure I am doing:
1. Download and build scap-security-guide for RHEL5 in my Fedora 23
machine; then copy the output to my CentOS 5 testing server:
tar -zxf scap-security-guide-0.1.29.tar.gz
make -C scap-security-guide-0.1.29/RHEL/5 dist
scp -r scap-security-guide-0.1.29/RHEL/5/dist/content centos5-test:
Now in the CentOS 5 testing server, create a tailoring file to run
file_permissions_ungroupowned test alone:
cat >ssg-centos5-xccdf-tailoring.xml <<"EOF"
<?xml version="1.0" encoding="UTF-8"?>
<title>CentOS 5 [TAILORED]</title>
<select idref="file_permissions_ungroupowned" selected="true"/>
Create a file without corresponding group in /etc/group:
chgrp 4567 /an_unowned_group_file
find / -nogroup 2>/dev/null
/an_unowned_group_file <-- Check that it is found
Finally run oscap:
oscap xccdf eval \
--tailoring-file ssg-centos5-xccdf-tailoring.xml \
--profile xccdf_my_profile_stig-centos5-upstream_tailored \
--cpe content/ssg-rhel5-cpe-dictionary.xml \
... and output is:
Title Ensure All Files Are Owned by a Group
I would expect that the test fails since there is at least one file without
I took a look at the OVAL definition
but I do not see anything wrong.
Do you have any idea why this test is passing when it should fail?
After many hours playing with SSG and OpenSCAP and not able to do what
I want I need some help.
Forgive me if I use SCAP or OpenSCAP terms incorrectly, I am new to
SSG and I am still getting familiar.
The following OVAL test searches for system accounts (UID < 500) in
/etc/at.allow (I am showing just the relevant parts of
RHEL/5/input/oval/at_system_accounts.xml to explain my problem):
<criterion test_ref="test_at_system_accounts_at_allow" />
<unix:password_test check="all" check_existence="none_exist"
comment="Testing system accounts in /etc/at.allow"
<unix:object object_ref="object_at_system_accounts_at_allow" />
<unix:password_object id="object_at_system_accounts_at_allow" version="1">
var_ref="var_at_system_accounts_allow_list" var_check="at least one"
comment="Accounts Allowed" datatype="string" version="1">
<ind:pattern operation="pattern match">^(.*)$</ind:pattern>
<ind:instance operation="greater than or equal"
<unix:password_state id="state_at_system_accounts_at_allow_uid" version="1">
<unix:user_id datatype="int" operation="less than">500</unix:user_id>
The test above gets the users information from the sources specified
in NSS (/etc/nsswitch.conf) which is correct, however I want to create
a version that uses /etc/passwd directly. Why? We have many
(thousands?) of RHEL 5 based servers with LDAP integration, and many
(thousands?) of accounts in the LDAP servers.
Simple tests like RHEL/5/input/oval/at_system_accounts.xml and
RHEL/5/input/oval/cron_system_accounts.xml can take hours to run
because they retrieve *all* users information from the LDAP servers
and they do it *for each entry* in /etc/at.allow and /etc/cron.allow.
Also, if we run OpenSCAP (oscap) at the same time in a few servers
they hit the LDAP servers really bad.
I have been trying to replace password_test and password_object by
textfilecontent54_test and textfilecontent54_object without any luck.
If you want, I can share my at_system_accounts.xml file that I thought
it was going to work.
I would really appreciate any help or hint?