OpenSCAP and SSG testing
by Peter Vrabec
Hi folks,
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.
http://www.open-scap.org/page/Download
My testing procedure:
--- VALIDATE INPUT ---
$ oscap xccdf validate-xml
ssg/RHEL6/output/rhel6-xccdf-scap-security-guide.xml
$ oscap oval validate-xml --schematron
ssg/RHEL6/output/rhel6-oval-scap-security-guide.xml
--- EVAL ---
$ oscap xccdf eval --profile common --results ssg-xccdf-results.xml
--oval-results ssg/RHEL6/output/rhel6-xccdf-scap-security-guide.xml
--- VALIDATE OUTPUT ---
$ oscap xccdf validate-xml ssg-xccdf-results.xml
$ oscap oval validate-xml --results --schematron
rhel6-oval-scap-security-guide.xml.result.xml
Regards,
Peter.
11 years, 7 months
[PATCH v2] Fix paths and requires in spec file.
by Spencer R. Shimko
The spec file was dropping things in /usr/local. Shift it to
/usr/share/doc/scap-security-guide-<version>.
Update Requires and BuildRequires based on perusal of apps leveraged
during build.
Signed-off-by: Spencer Shimko <sshimko(a)tresys.com>
---
scap-security-guide.spec | 16 +++++++++-------
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/scap-security-guide.spec b/scap-security-guide.spec
index 55e22a5..fc0f51c 100644
--- a/scap-security-guide.spec
+++ b/scap-security-guide.spec
@@ -12,8 +12,8 @@ BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
BuildArch: %{arch}
-BuildRequires: /bin/rm, /bin/mkdir, /bin/cp
-Requires: /bin/bash, /bin/date, /usr/bin/oscap
+BuildRequires: coreutils, libxslt, expat, python, openscap, openscap-utils
+Requires: filesystem
%description
The scap-security-guide project provides security configuration guidance in
@@ -28,13 +28,11 @@ requirements and specific implementation guidance.
%build
cd RHEL6 && make dist
-
%install
rm -rf $RPM_BUILD_ROOT
-#make install DESTDIR=$RPM_BUILD_ROOT
-mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/
+mkdir -p $RPM_BUILD_ROOT/%{_usr}/share/doc/%{name}-%{version}/
-cp -r RHEL6/dist/* $RPM_BUILD_ROOT/usr/local/%{name}/
+cp -r RHEL6/dist/* $RPM_BUILD_ROOT/%{_usr}/share/doc/%{name}-%{version}/
%clean
@@ -43,10 +41,14 @@ rm -rf $RPM_BUILD_ROOT
%files
%defattr(0644,root,root,0755)
-%attr(0755,root,root) /usr/local/scap-security-guide/
+%attr(0755,root,root) %{_usr}/share/doc/%{name}-%{version}/
%changelog
+* Tue Aug 28 2012 Spencer Shimko <sshimko(a)tresys.com> 1.0-4
+- Move away from using /usr/local for installation dir.
+- Fix BuildRequires and Requires.
+
* Wed Jul 3 2012 Jeffrey Blank <blank(a)eclipse.ncsc.mil> 1.0-3
- Modified install section, made description more concise.
--
1.7.1
11 years, 7 months
oscap hangs on wireless_disable_drivers.xml
by Willem Bos
Hi All,
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"
id="object_wireless_disable_drivers" version="1">
<unix:path operation="pattern
match">/lib/modules/.*/kernel/drivers/net/wireless</unix:path>
<unix:filename operation="pattern match">.*</unix:filename>
</unix:file_object>
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?
Regards,
Willem.
11 years, 7 months
removal of CCEs from OVAL definintions
by Jeffrey Blank
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.
11 years, 7 months
Accurate Run-time Kernel Module Checking
by Mike Palmiotto
All,
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.
1) rdblacklist=[kernel_module]
- 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.
4) /proc/ksyms
- 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.
--Mike
11 years, 7 months