Nowadays, there is almost no support for OVAL content development.
The developers have to edit the XML files manually, there is no
analysis tool, no debugger or any other tool that could make
the content development faster and easier.
I have started working on a new utility that will be able to
debug OVAL checks, show step-by-step how they are evaluated,
browse collected objects and system characteristics, communicate
with probes, etc.
I'm working on design of the utility now. I'm considering many
alternatives, so I would like to ask you a few questions.
* Can you describe most common problems that you have to face
when you create the OVAL content?
* How do you usually solve these problems?
* Can you tell me an example when did you run into issues with OVAL?
* Imagine an ideal tool for an OVAL developer. What should it be
able to do? What would be its features?
I would appreciate any suggestions, remarks or other inputs.
Thank you very much for your reply.
Security Technologies | Red Hat, Inc.
thank you for checking.
----- Original Message -----
> From: "Dan Warburton" <dan.warburton(a)jvncomm.com>
> To: "SCAP Security Guide" <scap-security-guide(a)lists.fedorahosted.org>
> Sent: Monday, June 29, 2015 4:19:20 PM
> Subject: Re: [New Release] SCAP Security Guide 0.1.23 is now live
> Did you generate the per-builts? I do not see them.
No sorry, I didn't create them yet. Originally planned to make them
manually, then starting from the future versions to add new Makefile
target that would build them automatically.
But later I changed my mind - it's better to start creating them
automatically right from the scratch (read as add new SSG GitHub
repo Makefile target, that would create them upon request).
This way we can find an agreement wrt e.g. to paths, where the content
should be installed etc. (wanted to do this earlier, but in the meantime
got distracted by other issues).
I will do make that pull request tomorrow (so tomorrow in the evening
they could be available already).
Sorry for the delay (and thanks for the remainder!)
Jan iankko Lieskovsky / Red Hat Security Technologies Team
> On June 23, 2015 at 11:53 AM Jan Lieskovsky <jlieskov(a)redhat.com> wrote:
> Hello folks,
> we are thrilled to announce the GA for the SCAP Security Guide of version
> -- the highlights for this release include:
> * Start porting of PCI-DSS profile from RHEL-6 to RHEL-7
> * Add OVAL-5.11 language support for RHEL-7 product if underlying system's
> oscap version supports OVAL-5.11 already
> * Start generating benchmarks for derivative OSes (CentOS, Scientific Linux)
> * Get rid of using symbolic links mechanism for OVAL checks shared across
> multiple products (RHEL/6, RHEL/7, and Fedora)
> * Enhance XML files validation performed via make validate target for all
> (optimize speed, validate all XML files against schematron where possible
> For a more detailed Changelog / Release Notes for this release kindly have a
> look at:
>  https://github.com/OpenSCAP/scap-security-guide/releases
> For the instructions how to try the new upstream version from source tarball
> kindly have a look at:
>  https://github.com/OpenSCAP/scap-security-guide/wiki/Building-from-Source
> For the prebuilt XML files -- I will try to generate them within tomorrow and
> update the v0.1.23
> tag page appropriately when done.
> Please report any issues encountered with the newly added (but also formerly
> existing) SSG content
> via GH tickets interface:
>  https://github.com/OpenSCAP/scap-security-guide/issues/new
> Happy hardening!
> Regards, Jan
> Jan iankko Lieskovsky (on behalf of the SCAP Security Guide upstream team)
> SCAP Security Guide mailing list
> Dan Warburton / JVN Communications w: 609-485-4480 m: 609-457-0154
I am new to OpenSCAP and am stuck
Operating System is CentOS 7.1
oscap version is 1.1.1
I am using "ssg.rhel7.ds..xml" to scan with.
The Rule "Verify that Shared Library Files have Restrictive Permissions"
indicate a "FAIL"
I am using SCAP-Workbench. When I run a scan, that Rule fails. Apparently
the Rule is looking for NO Group or Other write permissions (555) But on
CentOS 7.1, the /lib and /lib64 directories do not exist by default and
Symbolic links are used instead. They point to the real directories
/usr/lib and /usr/lib64 respectively. By default, apparently, symbolic
links have file permissions of "777". This is why I think the test is
failing. I don't see how to do an effective "chmod" on a symbolic link.
So I thot I would simply take the directories of interest (/lib and /lib64)
out of the Rule criteria. But I don't know how to do that.
I need help correcting this Rule test so the test will indicate a "PASS".
I suppose I could actually delete the two symbolic links but I might break
Does anyone have the cycles to add Pandoc translators for the SCAP stack?
I was just thinking that it would make writing specs a LOT more accessible
if you could do it in JSON or RestructuredText rather than messing about
with stacks of XML.
Perhaps wishful thinking, but it would be great to be able to write a
script with comments, smash it through a simple script and Pandoc and pop
out with usable OVAL with all the appropriate linkings.
Vice President, Onyx Point, Inc
-- This account not approved for unencrypted proprietary information --
For rule id: ensure_redhat_gpgkey_installed, it appears to be looking
for /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release. I'm sure this works
fine for RHEL, but the CentOS content also references this same test,
which will fail since it should be looking for
/etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 instead. Perhaps a slightly
modified version of the test is necessary for the various derivatives of
RHEL like CentOS?
From ZDNet's coverage....
> For security, RHEL 6.7 helps prevent data leakage by allowing
> read-only mounting of removable media. */In addition, RHEL 6.7 now
> includes the/**//**/Security Content Automation Protocol (SCAP)
> <http://scap.nist.gov/>/**/Workbench. This program builds on RHEL
> 6.7's existing SCAP functionality to measure your servers against your
> company's security guidelines and criteria./*
Congrats to Martin, Simon, Jan and the Brno team! Not only did you guys
develop kickass tooling that got shipped in RHEL, but even the press is
picking it up!
Great work guys!
RHEL/7/input/profiles/stig-rhel7-server-upstream.xml has the following:
<refine-value idref="var_password_pam_difok" selector="15" />
Should this be changed from 15 to 4? The help text indicates that the DoD requirement is 4, and other documentation seems to support this.
Ray Shaw (Contractor, STG)
Army Research Laboratory
CISD, Unix Support
I am not sure whether this is the place to report issues against XCCDF
standard, XCCDF schema in particular, but I will take my chances.
Ján Lieskovský (CC-ed) has found that XSD schema validation will not
always detect malformed XCCDF. Having good XSD schema is critical for
SCAP content authors at SCAP-Security-Guide project. They use XSD
schemas to ensure reasonable quality of their output. The following case
was not detected by XCCDF XSD validation:
The PCI-DSS profile contains:
<select idref="service_chronyd_enabled" selected="true"/>
However, the content does no include Rule/Group element with such ID.
Similar defects of XCCDF content usually get caught by XSD.
What do you think?
Security Technologies, Red Hat, Inc.