Hi, This is a very interesting issue that we haven't hit so far.
I checked on updated RHEL 7 machine which contains: - openscap-1.2.17-9.el7.x86_64 - scap-security-guide-0.1.46-11.el7.noarch The scap-security-guide-0.1.46-11.el7.noarch contains 2 RHEL 7 datastreams: - /usr/share/xml/scap/ssg/content/ssg-rhel7-ds-1.2.xml - /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml File ssg-rhel7-ds-1.2.xml is SCAP 1.2 conformant, ssg-rhel7-ds.xml is SCAP 1.3 conformant. We ship the ssg-rhel7-ds-1.2.xml for compatibility with other third-party tools, but oscap should be able to consume both. Their content is mostly the same, there are very small differences to conform to respective SCAP standard versions. I have tried the scan against a tailored STIG profile using both these files on this machine. But, both work for me, the HTML reports are complete. :-) However, I used my own tailoring file. I suspect that the problem might be in the tailoring file you're using. If the tailoring file was created against an older version of scap-security-guide, it might become incompatible with the STIG profile in scap-security-guide-0.1.46-11.el7.noarch. First, try a scan without --tailoring-file, with a different profile ID, eg. oscap xccdf eval --fetch-remote-resources --results-arf report.xml --report report.html --profile xccdf_org.ssgproject.content_profile_stig /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml There was a change in the STIG profile ID. It used to be xccdf_org.ssgproject.content_profile_stig-rhel7-disa, but starting from scap-security-guide 0.1.44 it is just xccdf_org.ssgproject.content_profile_stig. If the scan without tailoring works fine, inspect the tailoring file. Check if it references the correct profile in "extends" attribute in <Profile> element. For example: <xccdf:Profile id="xccdf_org.ssgproject.content_profile_stig_customized" extends="xccdf_org.ssgproject.content_profile_stig"> Also, check the <select> elements if they don't refer to a non-existing rule. If the scan without tailoring doesn't work either, there can be something preventing oscap from accessing /opt directory. HTH Regards On Mon, May 4, 2020 at 5:04 PM Fen Labalme <[email protected]> wrote: > > Hi Jan, > > Thanks for the bugzilla link that mentions "0.1.44 SCAP Security Guide > produces SCAP 1.3 conformant datastreams" which I believe is cause of the > problem I am seeing, as my last complete scans were with SSG 0.1.43. > > As to what is broken, the HTML report has empty lines for "Rule results" and > "Severity of failed rules", and nothing between the "Title | Severity | > Result" heading and the "Show all results details" at the bottom. > > I expect I'll be using OpenSCAP 1.2. 17 for a while, as building on > production servers is unlikely. With an improved pipeline (in the works) this > may change, but not immediately. > > This is the failingOpenSCAP invocation: > === > oscap xccdf eval > --fetch-remote-resources > --results-arf /opt/compliance/openscap/reports/{{ SCAP_TARGET > }}-report.xml > --report /opt/compliance/openscap/reports/{{ SCAP_TARGET > }}-report.html > --profile xccdf_org.globalnet_profile_stig-rhel7-disa_tailored > --tailoring-file > /opt/compliance/openscap/config/ssg-rhel7-ds-tailoring.xml > /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml > === > > I believe adding a "-1.2" to the xccdf:benchmark in > 'ssg-rhel7-ds-tailoring.xml' may be the bandaid I need (as described in [1])? > === > <xccdf:benchmark href="/usr/share/xml/scap/ssg/content/ssg-rhel7-ds-1.2.xml"/> > === > > Unsure. Will test. Is there a preferred mechanism that I am missing? > > [1] https://github.com/ComplianceAsCode/content/releases/tag/v0.1.46 > > =Fen > > > On Mon, May 4, 2020 at 4:55 AMJan Cerny <[email protected]> wrote: >> >> Hi Fen, >> >> On RHEL7 you can build OpenSCAP 1.3.3 from source code. Check [1] for >> instructions. Unfortunately, RHEL 7 won't ship OpenSCAP 1.3.x as a >> RPM package, because OpenSCAP 1.3.x isn't API compatible with the >> 1.2.x versions. >> >> But, OpenSCAP and SSG in RHEL7 should work together. There was a fix >> [2] in RHEL7 for OpenSCAP to work with SCAP 1.3 data streams. Can you >> tell us how your scans are broken? >> >> Regards >> >> [1] >> https://github.com/OpenSCAP/openscap/blob/maint-1.3/docs/developer/developer.adoc#building-openscap-on-linux >> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1709423 >> >> >> >> On Mon, May 4, 2020 at 5:06 AM Fen Labalme <[email protected]> >> wrote: >> > >> > Awesome - great work - thank you! >> > >> > Is there an easy way to have 1.3.x installed on RHEL/7 instances? Yum is >> > installing 1.2.17 and since (the default) SSG 0.1.46 is now defaulting to >> > 1.3 data streams, my scans are broken. >> > >> > Thanks again! >> > =Fen >> > >> > CivicActions Inc. | Making Compliance Secure >> > +1.412.996.4113 | civicactions.com >> > >> > >> > On Sun, May 3, 2020 at 3:38 PM Evgeny Kolesnikov <[email protected]> >> > wrote: >> >> >> >> Hello! >> >> >> >> We are proud to announce the OpenSCAP release 1.3.3. This release is >> >> based on the main-1.3 branch, and it is backward-compatible >> >> with 1.3.x releases. >> >> >> >> Notable improvements in this release: >> >> - a Python script that can be used for CLI tailoring (autotailor) >> >> (thank you, Matěj Týč); >> >> - timezone for XCCDF TestResult start and end time (thank you, Jan Černý); >> >> - new yamlfilecontent independent probe (draft implementation), >> >> see the proposal https://github.com/OVAL-Community/OVAL/issues/91 >> >> for additional information. >> >> >> >> There are other changes as well, here is the list: >> >> - Introduced `urn:xccdf:fix:script:kubernetes` fix type in XCCDF; >> >> - Added ability to generate `machineconfig` fix; >> >> - Detect ambiguous scan target (utils/oscap-podman); >> >> - Fixed #170: The rpmverifyfile probe can't verify files from '/bin' >> >> directory; >> >> - The data system_info probe return for offline and online modes is >> >> consistent and actual; >> >> - Prevent crashes when complicated regexes are executed in >> >> textfilecontent58 probe; >> >> - Fixed #1512: Severity refinement lost in generated guide; >> >> - Fixed #1453: Pointer lost in Swig API; >> >> - Evaluation Characteristics of the XCCDF report are now consistent >> >> with OVAL entities; >> >> from system_info probe; >> >> - Fixed filepath pattern matching in offline mode in textfilecontent58 >> >> probe; >> >> - Fixed infinite recursion in systemdunitdependency probe; >> >> - Fixed the case when CMake couldn't find libacl or xattr.h. >> >> >> >> Also thanks to all our contributors, who helped to make this release. >> >> >> >> Download: >> >> https://github.com/OpenSCAP/openscap/archive/1.3.3.tar.gz >> >> >> >> SHA512: >> >> e230668cdf900a2f31ccabc20787dce6c4174740aa7d2cc7b91c1c095e2a5b73d81bb614aa767d2e51383b5472def360c4204e9a6c4c85110c58b9999566613e >> >> >> >> Enjoy! >> >> >> >> On behalf of OpenSCAP contributors >> >> >> >> Evgenii Kolesnikov, >> >> Red Hat, Inc. >> >> >> >> >> >> _______________________________________________ >> >> Open-scap-list mailing list >> >> [email protected] >> >> https://www.redhat.com/mailman/listinfo/open-scap-list >> > >> > _______________________________________________ >> > Open-scap-list mailing list >> > [email protected] >> > https://www.redhat.com/mailman/listinfo/open-scap-list >> >> >> >> -- >> Jan Černý >> Security Technologies | Red Hat, Inc. >> -- Jan Černý Security Technologies | Red Hat, Inc. _______________________________________________ Open-scap-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/open-scap-list
