I'd like to encourage you to help OpenSCAP upstream with development.
Installing the latests oscap tool and testing both SSG content and
OpenSCAP together is beneficial.
You don't need to build it yourself. We provide packages for Fedora,
RHEL and CentOS.
My testing procedure:
--- VALIDATE INPUT ---
$ oscap xccdf validate-xml
$ oscap oval validate-xml --schematron
--- EVAL ---
$ oscap xccdf eval --profile common --results ssg-xccdf-results.xml
--- VALIDATE OUTPUT ---
$ oscap xccdf validate-xml ssg-xccdf-results.xml
$ oscap oval validate-xml --results --schematron
When running `oscap oval eval rhel6-oval-scap-security-guide.xml`the
scan hangs right after having processed
oval:scap-security-guide:def:1344. I did some digging around and found
that this is caused by
RHEL6/input/checks/wireless_disable_drivers.xml. The check contains a
pattern in the unix:path tag :
<unix:file_object comment="all local files"
<unix:filename operation="pattern match">.*</unix:filename>
Analyzing the run with strace shows that oscap scans the _whole_
filesystem instead of just /lib/modules. When I replace the pattern
with a kernel version the check runs fine. Maybe this is a oscap bug?
I plan to remove all CCE references from within the OVAL definitions (in
favor of storing CCEs only as idents in the XCCDF Rules).
This should simplify maintenance.
If users wish to reference CCEs from associated OVAL defintions, then we
can insert them during the transformation to final output -- if this
even necessary. If so, please let me know.
Just wondering what the community thinks about the appropriate standard
for disable kernel modules. All of these solutions seem valuable in
their own right, but as far as I know, none of them ensure the actual
presence/absence of kernel modules at run-time.
- I know this only prevents loading of the module in the rd=ramdisk,
but how does this affect dracut at runtime?
2) /etc/modprobe.d blacklists
- This approach is very similar to /bin/true.
3) install kernel_module /bin/true
- This ensures that an entry in a textfile is present, but what if
someone runs insmod on a kernel_module? This will not reflect the true
status of the kernel module in the system.
- Seems to be the most accurate reflection of the current system
status, though I'm no expert, so call me out on this.
I look forward to your input.