Steve,
If I understand what you are saying correctly: I could install/build openscap on
late-model editions of RHEL, 6.3 today, and once each for relevant architectures (32 and
64 bits). I would bring the latest edition of '/usr/lib64/libopenscap.so.x.x.x'
(and the one for x32) along with the oscap software and XML content placing them in the
NFS mount available to all hosts to be assessed. I would prefix my NFS path to
$LD_LIBRARY_PATH. So far, so good, right?
The probes you mentioned would be in an obvious place once I've got openscap compiled
or installed? Once I know that location, I'd set $OVAL_PROVE_DIR to it.
Thank you for the feedback.
R,
-Joe
________________________________
From: Steve Grubb <sgrubb(a)redhat.com>
To: scap-security-guide(a)lists.fedorahosted.org; Joe Wulf <joe_wulf(a)yahoo.com>
Sent: Thursday, September 13, 2012 12:35 PM
Subject: Re: Implementation of openscap
On Thursday, September 13, 2012 08:20:24 AM Joe Wulf wrote:
> - Can a single edition (preferably the latest) of openscap combined with
> the latest content be 'brought' into the RHEL test/dev hosts and be
> successful in executing for scoring/assessment? - Has anyone tried this
> yet?
The answer is probably...
The oscap commandline tool depends on a library in the openscap package,
/usr/lib64/libopenscap.so.1.0.0. So, you would need to export LD_LIBRARY_PATH
with this nfs location so that it finds the correct one before the one that's
possibly installed.
The other thing is that the OVAL scan uses individual probe executables to do
certain checks. So, you would have to tell it how to find the new binaries.
Fortunately, this was addressed to get the self test working. You would export
OVAL_PROBE_DIR pointing to the directory where the probes are.
There are also schemas and various supporting xml files. If your content is
complete, you might not have any problems. But this is the only area where I
think you'd need to do experimenting in.
-Steve