I appreciate all the work being done to develop RHEL6 content. Thanks to everyone!
My question is based on this.... I'll be reaching a point of testing a number of RHEL5/6 systems in bulk with openscap. Initially of course they'll be offline, development and/or non-production systems. OS versions would be a diverse smattering of RHEL 5.7, 5.8, 5.9 (when it comes out), 6.1, 6.2, 6.3 and 6.4 (when it comes out). Architecture would be both intel 32 and 64 bits. Most (if not all?) of these hosts would not have openscap.rpms already installed. I can readily envision full customer production systems expressly NOT having openscap.rpms installed on them at all, ever.
- 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?
This 'bringing in' would not be via RPM nor yum, but as an expanded gzipped tar file that is made available on an NFS share, so it was centrally available (for example). At that point execution could bring the benefits of modern openscap to site/host assessment, while not perturbating the customers' environment. Proving this works in test/dev, gives value to going forward with application against production systems that customers will not want changed, to the greatest extent possible. Another reason is that one cannot assume much less ensure any given 'environment to be tested' will have a yum repo available, nor that it would have the correct/right edition of openscap to install, via RPM, if the system owners would even permit it at the time of assessment.
Thanks, R, -Joe
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
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@redhat.com To: scap-security-guide@lists.fedorahosted.org; Joe Wulf joe_wulf@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
On Thursday, September 13, 2012 10:02:51 AM Joe Wulf wrote:
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?
Yep.
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.
rpm -ql openscap | grep libexec
-Steve
scap-security-guide@lists.fedorahosted.org
-
Joe Wulf -
Steve Grubb