I have been trying to get oscap working on my CentOS6.5 network core, without luck.
Everything comes back with "Result notapplicable".
I am pretty new to SCAP and XCCDF, but am a long-time user of Nessus and Security Center (prior to ACAS program by DISA).
Does anyone have suggestions where I can find some in depth guidance to adjust the rhel6 configs to CentOS?
-- Jeff
v/r, Jeffrey D. Pettorino, GCIH, CISSP Systems Engineer High Performance Computing Research Center United States Air Force Academy Jeffrey.Pettorino.ctr@USAFA.edu 719/333-9391 ---- The use of the Unix philosophy just for UNIX was a great waste. Fortunately, Linux came along. - Bellevue Linux User Group member, 2005
Every single check is hard coded to look for the platform Red Hat Enterprise Linux 6 (and in some cases now, Fedora and RHEL 7 as well). You need a different identifier for CentOS. A glance at the CPE dictionary at cpe.mitre.org suggests that the cpe value is "cpe:/o:centos:centos:6" which has the human readable name CentOS-6. Navigate to scap-security-guide/RHEL/6/input/checks and open a check. Near the top, you'll see an XML section, affected. The <platform> tag is key. Note that the <platform> tag inside is set to Red Hat Enterprise Linux 6. That's why you get not applicable when you run the commands as is.
- Maura Dailey
On 06/17/2014 05:01 PM, Pettorino, Jeffrey D CTR USAF USAFA USAFA/DFAN wrote:
I have been trying to get oscap working on my CentOS6.5 network core, without luck.
Everything comes back with "Result notapplicable".
I am pretty new to SCAP and XCCDF, but am a long-time user of Nessus and Security Center (prior to ACAS program by DISA).
Does anyone have suggestions where I can find some in depth guidance to adjust the rhel6 configs to CentOS?
-- Jeff
v/r, Jeffrey D. Pettorino, GCIH, CISSP Systems Engineer High Performance Computing Research Center United States Air Force Academy Jeffrey.Pettorino.ctr@USAFA.edu 719/333-9391
The use of the Unix philosophy just for UNIX was a great waste. Fortunately, Linux came along.
- Bellevue Linux User Group member, 2005
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
The check for Red Hat 6 is pulled from:
scap-security-guide\RHEL\6\input\checks\installed_OS_is_rhel6.xml
Simply change the two references to 'redhat-release' to state 'centos-release' instead. Then rebuild.
That should do it.
Best regards,
Trey Henefield, CISSP Senior IAVA Engineer
Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA
Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.com
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Pettorino, Jeffrey D CTR USAF USAFA USAFA/DFAN Sent: Tuesday, June 17, 2014 4:01 PM To: 'scap-security-guide@lists.fedorahosted.org' Subject: Anyone using rhel6 ssg for centos6?
I have been trying to get oscap working on my CentOS6.5 network core, without luck.
Everything comes back with "Result notapplicable".
I am pretty new to SCAP and XCCDF, but am a long-time user of Nessus and Security Center (prior to ACAS program by DISA).
Does anyone have suggestions where I can find some in depth guidance to adjust the rhel6 configs to CentOS?
-- Jeff
v/r, Jeffrey D. Pettorino, GCIH, CISSP Systems Engineer High Performance Computing Research Center United States Air Force Academy Jeffrey.Pettorino.ctr@USAFA.edu 719/333-9391 ---- The use of the Unix philosophy just for UNIX was a great waste. Fortunately, Linux came along. - Bellevue Linux User Group member, 2005
Disclaimer The information contained in this communication from trey.henefield@ultra-ats.com sent at 2014-06-18 07:30:57 is confidential and may be legally privileged. It is intended solely for use by scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.
It requires an extra hack because ‘version’ on CentOS won’t match the specified pattern; here is how I did it to keep it compatible with RHEL: 1. Add an extra criterion: <criteria operator="OR"> <criterion comment="Red Hat Enterprise Linux 6 Workstation is installed" test_ref="test_rhel_workstation" /> <criterion comment="Red Hat Enterprise Linux 6 Server is installed" test_ref="test_rhel_server" /> <criterion comment="CentOS 6 is installed" test_ref="test_centos" /> </criteria> 2. Add an extra test: <linux:rpminfo_test check="all" check_existence="at_least_one_exists" comment="centos-release is version 6" id="test_centos" version="1"> <linux:object object_ref="obj_centos" /> <linux:state state_ref="state_centos" /> </linux:rpminfo_test> <linux:rpminfo_state id="state_centos" version="1"> <linux:version operation="pattern match">^6</linux:version> </linux:rpminfo_state> <linux:rpminfo_object id="obj_centos" version="1"> linux:namecentos-release</linux:name> </linux:rpminfo_object>
Another weirder issue on the original SSG check: I don’t think this check works on ‘pure’ RHEL6 either but the platform still matches for some reason I do not understand.
When I use ‘—oval-results’, the CPE result file (ssg-rhel6-cpe-oval.xml.result.xml), the test_rhel_* tests all fail for the same reason, i.e: lin-sys:version6Server</lin-sys:version> Won’t match: <lin-def:version operation="pattern match">^6.\d+$</lin-def:version>
Thus resulting in ‘false’ for test_rhel_server: <test test_id="oval:ssg:tst:103" version="1" check="all" result="false"> <tested_item item_id="1046111" result="false"/> </test>
and consequently for installed_OS_is_rhel6: <definition definition_id="oval:ssg:def:100" result="false" version="1">
But the definition still works ok, although it doesn’t on CentOS… What am I getting wrong were?
Thanks!
From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Trey Henefield Sent: quarta-feira, 18 de Junho de 2014 12:31 To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
The check for Red Hat 6 is pulled from:
scap-security-guide\RHEL\6\input\checks\installed_OS_is_rhel6.xml
Simply change the two references to 'redhat-release' to state 'centos-release' instead. Then rebuild.
That should do it.
Best regards,
Trey Henefield, CISSP Senior IAVA Engineer
Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA
Trey.Henefield@ultra-ats.commailto:Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.comhttp://www.ultra-ats.com
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Pettorino, Jeffrey D CTR USAF USAFA USAFA/DFAN Sent: Tuesday, June 17, 2014 4:01 PM To: 'scap-security-guide@lists.fedorahosted.org' Subject: Anyone using rhel6 ssg for centos6?
I have been trying to get oscap working on my CentOS6.5 network core, without luck.
Everything comes back with "Result notapplicable".
I am pretty new to SCAP and XCCDF, but am a long-time user of Nessus and Security Center (prior to ACAS program by DISA).
Does anyone have suggestions where I can find some in depth guidance to adjust the rhel6 configs to CentOS?
-- Jeff
v/r, Jeffrey D. Pettorino, GCIH, CISSP Systems Engineer High Performance Computing Research Center United States Air Force Academy Jeffrey.Pettorino.ctr@USAFA.edumailto:Jeffrey.Pettorino.ctr@USAFA.edu 719/333-9391 ---- The use of the Unix philosophy just for UNIX was a great waste. Fortunately, Linux came along. - Bellevue Linux User Group member, 2005
Disclaimer The information contained in this communication from trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com sent at 2014-06-18 07:30:57 is private and may be legally privileged or export controlled. It is intended solely for use by scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.
… it seems OpenSCAP is using it’s own ‘openscap-cpe-dict.xml’ and that’s why the SSG platform check “works”. The checks in ‘ssg-rhel6-cpe-dictionary.xml’ fail always.
From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Rui Pedro Bernardino Sent: quarta-feira, 18 de Junho de 2014 13:21 To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
It requires an extra hack because ‘version’ on CentOS won’t match the specified pattern; here is how I did it to keep it compatible with RHEL: 1. Add an extra criterion: <criteria operator="OR"> <criterion comment="Red Hat Enterprise Linux 6 Workstation is installed" test_ref="test_rhel_workstation" /> <criterion comment="Red Hat Enterprise Linux 6 Server is installed" test_ref="test_rhel_server" /> <criterion comment="CentOS 6 is installed" test_ref="test_centos" /> </criteria> 2. Add an extra test: <linux:rpminfo_test check="all" check_existence="at_least_one_exists" comment="centos-release is version 6" id="test_centos" version="1"> <linux:object object_ref="obj_centos" /> <linux:state state_ref="state_centos" /> </linux:rpminfo_test> <linux:rpminfo_state id="state_centos" version="1"> <linux:version operation="pattern match">^6</linux:version> </linux:rpminfo_state> <linux:rpminfo_object id="obj_centos" version="1"> linux:namecentos-release</linux:name> </linux:rpminfo_object>
Another weirder issue on the original SSG check: I don’t think this check works on ‘pure’ RHEL6 either but the platform still matches for some reason I do not understand.
When I use ‘—oval-results’, the CPE result file (ssg-rhel6-cpe-oval.xml.result.xml), the test_rhel_* tests all fail for the same reason, i.e: lin-sys:version6Server</lin-sys:version> Won’t match: <lin-def:version operation="pattern match">^6.\d+$</lin-def:version>
Thus resulting in ‘false’ for test_rhel_server: <test test_id="oval:ssg:tst:103" version="1" check="all" result="false"> <tested_item item_id="1046111" result="false"/> </test>
and consequently for installed_OS_is_rhel6: <definition definition_id="oval:ssg:def:100" result="false" version="1">
But the definition still works ok, although it doesn’t on CentOS… What am I getting wrong were?
Thanks!
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Trey Henefield Sent: quarta-feira, 18 de Junho de 2014 12:31 To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
The check for Red Hat 6 is pulled from:
scap-security-guide\RHEL\6\input\checks\installed_OS_is_rhel6.xml
Simply change the two references to 'redhat-release' to state 'centos-release' instead. Then rebuild.
That should do it.
Best regards,
Trey Henefield, CISSP Senior IAVA Engineer
Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA
Trey.Henefield@ultra-ats.commailto:Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.comhttp://www.ultra-ats.com
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Pettorino, Jeffrey D CTR USAF USAFA USAFA/DFAN Sent: Tuesday, June 17, 2014 4:01 PM To: 'scap-security-guide@lists.fedorahosted.org' Subject: Anyone using rhel6 ssg for centos6?
I have been trying to get oscap working on my CentOS6.5 network core, without luck.
Everything comes back with "Result notapplicable".
I am pretty new to SCAP and XCCDF, but am a long-time user of Nessus and Security Center (prior to ACAS program by DISA).
Does anyone have suggestions where I can find some in depth guidance to adjust the rhel6 configs to CentOS?
-- Jeff
v/r, Jeffrey D. Pettorino, GCIH, CISSP Systems Engineer High Performance Computing Research Center United States Air Force Academy Jeffrey.Pettorino.ctr@USAFA.edumailto:Jeffrey.Pettorino.ctr@USAFA.edu 719/333-9391 ---- The use of the Unix philosophy just for UNIX was a great waste. Fortunately, Linux came along. - Bellevue Linux User Group member, 2005
Disclaimer The information contained in this communication from trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com sent at 2014-06-18 07:30:57 is private and may be legally privileged or export controlled. It is intended solely for use by scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.
On 06/18/2014 03:41 PM, Rui Pedro Bernardino wrote:
… it seems OpenSCAP is using it’s own ‘openscap-cpe-dict.xml’ and that’s why the SSG platform check “works”. The checks in ‘ssg-rhel6-cpe-dictionary.xml’ fail always.
Hello,
I am sorry for the late response, but I would like to put a bit of light into this.
OpenSCAP uses its inbuilt CPE dictionary when the CPE is not provided from the outside. This behavior is in line with SCAP requirements for certified scanner.
If you are not satisfied with inbuilt CPE name you may need to specify --cpe command-line option to the scanner.
For review of inbuilt CPE names run:
# oscap --version
In OpenSCAP upstream we try to give good guidance on: how a particular CPE name shall be implemented [1]. We welcome comments, patches, as well as implementation of new platforms.
I remember, I have recently added CPE names for CentOS 5, 6, and 7. However, I am unsure whether this new names are been released to the downstreams.
[1]: OpenSCAP upstream implementation of selected CPE names: https://git.fedorahosted.org/cgit/openscap.git/tree/cpe/openscap-cpe-oval.xm...
Best regards,
----- Original Message -----
From: "Simon Lukasik" slukasik@redhat.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Tuesday, July 1, 2014 1:05:10 PM Subject: Re: Anyone using rhel6 ssg for centos6?
On 06/18/2014 03:41 PM, Rui Pedro Bernardino wrote:
… it seems OpenSCAP is using it’s own ‘openscap-cpe-dict.xml’ and that’s why the SSG platform check “works”. The checks in ‘ssg-rhel6-cpe-dictionary.xml’ fail always.
Hello,
I am sorry for the late response, but I would like to put a bit of light into this.
OpenSCAP uses its inbuilt CPE dictionary when the CPE is not provided from the outside. This behavior is in line with SCAP requirements for certified scanner.
If you are not satisfied with inbuilt CPE name you may need to specify --cpe command-line option to the scanner.
For review of inbuilt CPE names run:
# oscap --version
In OpenSCAP upstream we try to give good guidance on: how a particular CPE name shall be implemented [1]. We welcome comments, patches, as well as implementation of new platforms.
I remember, I have recently added CPE names for CentOS 5, 6, and 7. However, I am unsure whether this new names are been released to the downstreams.
This is the commit in question:
https://git.fedorahosted.org/cgit/openscap.git/commit/?id=e09f29496081a0525c...
It is part of the master branch, there have been no releases that contain it yet. The next release with this change will be openscap 1.1.0. This commit may be a good candidate for a downstream patch in the CentOS package.
----- Original Message -----
From: "Simon Lukasik" slukasik@redhat.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Tuesday, July 1, 2014 1:05:10 PM Subject: Re: Anyone using rhel6 ssg for centos6?
On 06/18/2014 03:41 PM, Rui Pedro Bernardino wrote:
… it seems OpenSCAP is using it’s own ‘openscap-cpe-dict.xml’ and that’s why the SSG platform check “works”. The checks in ‘ssg-rhel6-cpe-dictionary.xml’ fail always.
Hello,
I am sorry for the late response, but I would like to put a bit of light into this.
OpenSCAP uses its inbuilt CPE dictionary when the CPE is not provided from the outside. This behavior is in line with SCAP requirements for certified scanner.
If you are not satisfied with inbuilt CPE name you may need to specify --cpe command-line option to the scanner.
For review of inbuilt CPE names run:
# oscap --version
In OpenSCAP upstream we try to give good guidance on: how a particular CPE name shall be implemented [1]. We welcome comments, patches, as well as implementation of new platforms.
I remember, I have recently added CPE names for CentOS 5, 6, and 7. However, I am unsure whether this new names are been released to the downstreams.
This is the commit in question:
https://git.fedorahosted.org/cgit/openscap.git/commit/?id=e09f29496081a0525c...
It is part of the master branch, there have been no releases that contain it yet. The next release with this change will be openscap 1.1.0. This commit may be a good candidate for a downstream patch in the CentOS package.
Yes please!!
----- Original Message -----
From: "Stuart Green" stuart.green@doccentrics.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Wednesday, July 2, 2014 2:54:57 PM Subject: Re: Anyone using rhel6 ssg for centos6?
----- Original Message -----
From: "Simon Lukasik" slukasik@redhat.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Tuesday, July 1, 2014 1:05:10 PM Subject: Re: Anyone using rhel6 ssg for centos6?
On 06/18/2014 03:41 PM, Rui Pedro Bernardino wrote:
… it seems OpenSCAP is using it’s own ‘openscap-cpe-dict.xml’ and that’s why the SSG platform check “works”. The checks in ‘ssg-rhel6-cpe-dictionary.xml’ fail always.
Hello,
I am sorry for the late response, but I would like to put a bit of light into this.
OpenSCAP uses its inbuilt CPE dictionary when the CPE is not provided from the outside. This behavior is in line with SCAP requirements for certified scanner.
If you are not satisfied with inbuilt CPE name you may need to specify --cpe command-line option to the scanner.
For review of inbuilt CPE names run:
# oscap --version
In OpenSCAP upstream we try to give good guidance on: how a particular CPE name shall be implemented [1]. We welcome comments, patches, as well as implementation of new platforms.
I remember, I have recently added CPE names for CentOS 5, 6, and 7. However, I am unsure whether this new names are been released to the downstreams.
This is the commit in question:
https://git.fedorahosted.org/cgit/openscap.git/commit/?id=e09f29496081a0525c...
It is part of the master branch, there have been no releases that contain it yet. The next release with this change will be openscap 1.1.0. This commit may be a good candidate for a downstream patch in the CentOS package.
Yes please!!
Please lobby at the appropriate place - https://bugs.centos.org
----- Original Message -----
From: "Stuart Green" stuart.green@doccentrics.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Wednesday, July 2, 2014 2:54:57 PM Subject: Re: Anyone using rhel6 ssg for centos6?
----- Original Message -----
From: "Simon Lukasik" slukasik@redhat.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Tuesday, July 1, 2014 1:05:10 PM Subject: Re: Anyone using rhel6 ssg for centos6?
On 06/18/2014 03:41 PM, Rui Pedro Bernardino wrote:
… it seems OpenSCAP is using it’s own ‘openscap-cpe-dict.xml’ and that’s why the SSG platform check “works”. The checks in ‘ssg-rhel6-cpe-dictionary.xml’ fail always.
Hello,
I am sorry for the late response, but I would like to put a bit of light into this.
OpenSCAP uses its inbuilt CPE dictionary when the CPE is not provided from the outside. This behavior is in line with SCAP requirements for certified scanner.
If you are not satisfied with inbuilt CPE name you may need to specify --cpe command-line option to the scanner.
For review of inbuilt CPE names run:
# oscap --version
In OpenSCAP upstream we try to give good guidance on: how a particular CPE name shall be implemented [1]. We welcome comments, patches, as well as implementation of new platforms.
I remember, I have recently added CPE names for CentOS 5, 6, and 7. However, I am unsure whether this new names are been released to the downstreams.
This is the commit in question:
https://git.fedorahosted.org/cgit/openscap.git/commit/?id=e09f29496081a0525c...
It is part of the master branch, there have been no releases that contain it yet. The next release with this change will be openscap 1.1.0. This commit may be a good candidate for a downstream patch in the CentOS package.
Yes please!!
Please lobby at the appropriate place - https://bugs.centos.org
To clarify, you're asking me to raise a request detailing Simon's commit on bugs.centos.org?
I would like to start this thread up again.
Any good Urls to explanations on all this is appreciated!
I'm about to spend the rest of the day trying to understand CPE and why I was able to get results scanning CentOS 6.5 on one AMI I configured back in Jan/Feb without rebuilding the source but and now getting "not applicable" across the board for CentOS 6.5. (I may have git cloned the Fedora Repo in Jan/Feb while I am using EPEL repos more recently.)
My plan is to examine the respective installs, read whatever docs I can find, and look at NIST SP 800-126 (the SCAP spec - http://csrc.nist.gov/publications/nistpubs/800-126-rev2/SP800-126r2.pdf).
Help in anyway to speed me on my journey is appreciated!
Greg Elin http://govready.org - Making FISMA compliance easier for innovators
email: gregelin@gitmachines.com phone: 917-304-3488
On Thu, Jul 3, 2014 at 11:35 AM, Stuart Green stuart.green@doccentrics.com wrote:
----- Original Message -----
From: "Stuart Green" stuart.green@doccentrics.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Wednesday, July 2, 2014 2:54:57 PM Subject: Re: Anyone using rhel6 ssg for centos6?
----- Original Message -----
From: "Simon Lukasik" slukasik@redhat.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Tuesday, July 1, 2014 1:05:10 PM Subject: Re: Anyone using rhel6 ssg for centos6?
On 06/18/2014 03:41 PM, Rui Pedro Bernardino wrote:
… it seems OpenSCAP is using it’s own ‘openscap-cpe-dict.xml’ and that’s why the SSG platform check “works”. The checks in ‘ssg-rhel6-cpe-dictionary.xml’ fail always.
Hello,
I am sorry for the late response, but I would like to put a bit of light into this.
OpenSCAP uses its inbuilt CPE dictionary when the CPE is not provided from the outside. This behavior is in line with SCAP requirements for certified scanner.
If you are not satisfied with inbuilt CPE name you may need to specify --cpe command-line option to the scanner.
For review of inbuilt CPE names run:
# oscap --version
In OpenSCAP upstream we try to give good guidance on: how a particular CPE name shall be implemented [1]. We welcome comments, patches, as well as implementation of new platforms.
I remember, I have recently added CPE names for CentOS 5, 6, and 7. However, I am unsure whether this new names are been released to the downstreams.
This is the commit in question:
https://git.fedorahosted.org/cgit/openscap.git/commit/?id= e09f29496081a0525cda0b18299bccb9803baf76
It is part of the master branch, there have been no releases that contain it yet. The next release with this change will be openscap 1.1.0. This commit may be a good candidate for a downstream patch in the CentOS package.
Yes please!!
Please lobby at the appropriate place - https://bugs.centos.org
To clarify, you're asking me to raise a request detailing Simon's commit on bugs.centos.org?
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
I'm using it for SL6. The problem is in openscap-cpe-oval.xml. The test for release is searching on RedHat only.
I've changed mine to the following: notice the (redhat|sl) on the second line. You should be able to change it to whatever the centos-release rpm says. I can't remember right now if SSG is where I got the original xml file, or if it's the one from open-scap. It's very possible that you'll have to make sure that you'll have to alter the ssg-rhel6-cpe-dictionary.xml to point to your altered cpe-oval file. I've attached them just incase, but it took some tweaking.
<rpminfo_state id="oval:org.open-scap.cpe.rhel:ste:6" version="1" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#linux%22%3E <name operation="pattern match">^(redhat|sl)-release</name> <version operation="pattern match">^6[^\d]</version> </rpminfo_state>
On Thu, Aug 14, 2014 at 3:46 PM, Greg Elin gregelin@gitmachines.com wrote:
I would like to start this thread up again.
Any good Urls to explanations on all this is appreciated!
I'm about to spend the rest of the day trying to understand CPE and why I was able to get results scanning CentOS 6.5 on one AMI I configured back in Jan/Feb without rebuilding the source but and now getting "not applicable" across the board for CentOS 6.5. (I may have git cloned the Fedora Repo in Jan/Feb while I am using EPEL repos more recently.)
My plan is to examine the respective installs, read whatever docs I can find, and look at NIST SP 800-126 (the SCAP spec - http://csrc.nist.gov/publications/nistpubs/800-126-rev2/SP800-126r2.pdf).
Help in anyway to speed me on my journey is appreciated!
Greg Elin http://govready.org - Making FISMA compliance easier for innovators
email: gregelin@gitmachines.com phone: 917-304-3488
On Thu, Jul 3, 2014 at 11:35 AM, Stuart Green stuart.green@doccentrics.com wrote:
----- Original Message -----
From: "Stuart Green" stuart.green@doccentrics.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Wednesday, July 2, 2014 2:54:57 PM Subject: Re: Anyone using rhel6 ssg for centos6?
----- Original Message -----
From: "Simon Lukasik" slukasik@redhat.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Tuesday, July 1, 2014 1:05:10 PM Subject: Re: Anyone using rhel6 ssg for centos6?
On 06/18/2014 03:41 PM, Rui Pedro Bernardino wrote: > > … it seems OpenSCAP is using it’s own ‘openscap-cpe-dict.xml’ and > that’s > why the SSG platform check “works”. The checks in > ‘ssg-rhel6-cpe-dictionary.xml’ fail always. > Hello,
I am sorry for the late response, but I would like to put a bit of light into this.
OpenSCAP uses its inbuilt CPE dictionary when the CPE is not provided from the outside. This behavior is in line with SCAP requirements for certified scanner.
If you are not satisfied with inbuilt CPE name you may need to specify --cpe command-line option to the scanner.
For review of inbuilt CPE names run:
# oscap --version
In OpenSCAP upstream we try to give good guidance on: how a particular CPE name shall be implemented [1]. We welcome comments, patches, as well as implementation of new platforms.
I remember, I have recently added CPE names for CentOS 5, 6, and 7. However, I am unsure whether this new names are been released to the downstreams.
This is the commit in question:
https://git.fedorahosted.org/cgit/openscap.git/commit/?id=e09f29496081a0525c...
It is part of the master branch, there have been no releases that contain it yet. The next release with this change will be openscap 1.1.0. This commit may be a good candidate for a downstream patch in the CentOS package.
Yes please!!
Please lobby at the appropriate place - https://bugs.centos.org
To clarify, you're asking me to raise a request detailing Simon's commit on bugs.centos.org?
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
In a nut shell, I get the sense that the distributions SL and CentOS are not altering these for their respective distributions.
On Thu, Aug 14, 2014 at 4:25 PM, Jeremiah Jahn jeremiah@goodinassociates.com wrote:
I'm using it for SL6. The problem is in openscap-cpe-oval.xml. The test for release is searching on RedHat only.
I've changed mine to the following: notice the (redhat|sl) on the second line. You should be able to change it to whatever the centos-release rpm says. I can't remember right now if SSG is where I got the original xml file, or if it's the one from open-scap. It's very possible that you'll have to make sure that you'll have to alter the ssg-rhel6-cpe-dictionary.xml to point to your altered cpe-oval file. I've attached them just incase, but it took some tweaking.
<rpminfo_state id="oval:org.open-scap.cpe.rhel:ste:6" version="1" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#linux%22%3E <name operation="pattern match">^(redhat|sl)-release</name> <version operation="pattern match">^6[^\d]</version> </rpminfo_state>
On Thu, Aug 14, 2014 at 3:46 PM, Greg Elin gregelin@gitmachines.com wrote:
I would like to start this thread up again.
Any good Urls to explanations on all this is appreciated!
I'm about to spend the rest of the day trying to understand CPE and why I was able to get results scanning CentOS 6.5 on one AMI I configured back in Jan/Feb without rebuilding the source but and now getting "not applicable" across the board for CentOS 6.5. (I may have git cloned the Fedora Repo in Jan/Feb while I am using EPEL repos more recently.)
My plan is to examine the respective installs, read whatever docs I can find, and look at NIST SP 800-126 (the SCAP spec - http://csrc.nist.gov/publications/nistpubs/800-126-rev2/SP800-126r2.pdf).
Help in anyway to speed me on my journey is appreciated!
Greg Elin http://govready.org - Making FISMA compliance easier for innovators
email: gregelin@gitmachines.com phone: 917-304-3488
On Thu, Jul 3, 2014 at 11:35 AM, Stuart Green stuart.green@doccentrics.com wrote:
----- Original Message -----
From: "Stuart Green" stuart.green@doccentrics.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Wednesday, July 2, 2014 2:54:57 PM Subject: Re: Anyone using rhel6 ssg for centos6?
----- Original Message ----- > > From: "Simon Lukasik" slukasik@redhat.com > To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org > Sent: Tuesday, July 1, 2014 1:05:10 PM > Subject: Re: Anyone using rhel6 ssg for centos6? > > On 06/18/2014 03:41 PM, Rui Pedro Bernardino wrote: >> >> … it seems OpenSCAP is using it’s own ‘openscap-cpe-dict.xml’ and >> that’s >> why the SSG platform check “works”. The checks in >> ‘ssg-rhel6-cpe-dictionary.xml’ fail always. >> > Hello, > > I am sorry for the late response, but I would like to put a bit of > light > into this. > > OpenSCAP uses its inbuilt CPE dictionary when the CPE is not provided > from the outside. This behavior is in line with SCAP requirements for > certified scanner. > > If you are not satisfied with inbuilt CPE name you may need to specify > --cpe command-line option to the scanner. > > For review of inbuilt CPE names run: > > # oscap --version > > In OpenSCAP upstream we try to give good guidance on: how a particular > CPE name shall be implemented [1]. We welcome comments, patches, as > well > as implementation of new platforms. > > I remember, I have recently added CPE names for CentOS 5, 6, and 7. > However, I am unsure whether this new names are been released to the > downstreams.
This is the commit in question:
https://git.fedorahosted.org/cgit/openscap.git/commit/?id=e09f29496081a0525c...
It is part of the master branch, there have been no releases that contain it yet. The next release with this change will be openscap 1.1.0. This commit may be a good candidate for a downstream patch in the CentOS package.
Yes please!!
Please lobby at the appropriate place - https://bugs.centos.org
To clarify, you're asking me to raise a request detailing Simon's commit on bugs.centos.org?
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
On 8/14/14, 5:25 PM, Jeremiah Jahn wrote:
I'm using it for SL6. The problem is in openscap-cpe-oval.xml. The test for release is searching on RedHat only.
I've changed mine to the following: notice the (redhat|sl) on the second line. You should be able to change it to whatever the centos-release rpm says. I can't remember right now if SSG is where I got the original xml file, or if it's the one from open-scap. It's very possible that you'll have to make sure that you'll have to alter the ssg-rhel6-cpe-dictionary.xml to point to your altered cpe-oval file. I've attached them just incase, but it took some tweaking.
<rpminfo_state id="oval:org.open-scap.cpe.rhel:ste:6" version="1" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#linux%22%3E <name operation="pattern match">^(redhat|sl)-release</name> <version operation="pattern match">^6[^\d]</version> </rpminfo_state>
To illustrate how CPE works, as part of Greg's question....
Step 1: In your OVAL check, you define which platforms the check is written for. This is done by the <affected> stanzas, such as:
<affected family="unix"> <platform>Red Hat Enterprise Linux 6</platform> </affected>
Step 2: When an SCAP interpreter parses each OVAL rule, it will parse the <affected> tag above. For each <platform> listed, it will find the associated <cpi-item> to find what <check> needs to be ran. This will tell the SCAP interpreter if the OVAL rule is applicable for the system being scanned.
For example, from SSG's CPE dictionary:
<cpe-item name="cpe:/o:redhat:enterprise_linux:6"> <title xml:lang="en-us">Red Hat Enterprise Linux 6</title> <!-- the check references an OVAL file that contains an inventory definition --> <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5" href="filename">installed_OS_is_rhel6</check> </cpe-item>
In this case, if the <platform> tag matches the cpe-item/title, then the cpe-item/check will be ran. In the case of "Red Hat Enterprise Linux 6" the OVAL check "installed_OS_is_rhel6" will be ran.
The installed_OS_is_rhel6 OVAL check queries the system to see if the redhat-release-{server workstation}-6 RPM is installed, for example:
https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/6/input/che...
<linux:rpminfo_test check="all" check_existence="at_least_one_exists" comment="redhat-release-server is version 6" id="test_rhel_server" version="1"> <linux:object object_ref="obj_rhel_server" /> <linux:state state_ref="state_rhel_server" /> </linux:rpminfo_test> <linux:rpminfo_state id="state_rhel_server" version="1"> <linux:version operation="pattern match">^6.\d+$</linux:version> </linux:rpminfo_state> <linux:rpminfo_object id="obj_rhel_server" version="1"> linux:nameredhat-release-server</linux:name> </linux:rpminfo_object>
If the the check passes, the SCAP interpreter knows the particular OVAL rule is applicable to the system, executes the probes, and you get a pass/fail result. If the installed_OS_is_rhel6 check fails, the OVAL rule will be marked as "Not Applicable."
For users running derivative operating systems (CentOS, Scientific...) you can edit your CPE dictionary's regex like Jeremiah outlined. This will "fake" the system into thinking it's running RHEL6 and allow the check to be ran.
Shawn, thanks for the detailed explanation. Rather than faking the system into thinking it's running RHEL6, would it be possible to update the oval definitions to include CentOS as an applicable platform?
On Fri, Aug 15, 2014 at 1:10 PM, Shawn Wells shawn@redhat.com wrote:
On 8/14/14, 5:25 PM, Jeremiah Jahn wrote:
I'm using it for SL6. The problem is in openscap-cpe-oval.xml. The test for release is searching on RedHat only.
I've changed mine to the following: notice the (redhat|sl) on the second line. You should be able to change it to whatever the centos-release rpm says. I can't remember right now if SSG is where I got the original xml file, or if it's the one from open-scap. It's very possible that you'll have to make sure that you'll have to alter the ssg-rhel6-cpe-dictionary.xml to point to your altered cpe-oval file. I've attached them just incase, but it took some tweaking.
<rpminfo_state id="oval:org.open-scap.cpe.rhel:ste:6" version="1" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#linux%22%3E <name operation="pattern
match">^(redhat|sl)-release</name>
<version operation="pattern match">^6[^\d]</version> </rpminfo_state>
To illustrate how CPE works, as part of Greg's question....
Step 1: In your OVAL check, you define which platforms the check is written for. This is done by the <affected> stanzas, such as:
<affected family="unix"> <platform>Red Hat Enterprise Linux 6</platform> </affected>
Step 2: When an SCAP interpreter parses each OVAL rule, it will parse the <affected> tag above. For each <platform> listed, it will find the associated <cpi-item> to find what <check> needs to be ran. This will tell the SCAP interpreter if the OVAL rule is applicable for the system being scanned.
For example, from SSG's CPE dictionary:
<cpe-item name="cpe:/o:redhat:enterprise_linux:6"> <title xml:lang="en-us">Red Hat Enterprise Linux 6</title> <!-- the check references an OVAL file that contains an
inventory definition -->
<check system="
http://oval.mitre.org/XMLSchema/oval-definitions-5" href="filename">installed_OS_is_rhel6</check>
</cpe-item>
In this case, if the <platform> tag matches the cpe-item/title, then the cpe-item/check will be ran. In the case of "Red Hat Enterprise Linux 6" the OVAL check "installed_OS_is_rhel6" will be ran.
The installed_OS_is_rhel6 OVAL check queries the system to see if the redhat-release-{server workstation}-6 RPM is installed, for example:
https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/6/input/che...
<linux:rpminfo_test check="all" check_existence="at_least_one_exists"
comment="redhat-release-server is version 6" id="test_rhel_server" version="1">
<linux:object object_ref="obj_rhel_server" /> <linux:state state_ref="state_rhel_server" />
</linux:rpminfo_test> <linux:rpminfo_state id="state_rhel_server" version="1"> <linux:version operation="pattern match">^6.\d+$</linux:version> </linux:rpminfo_state> <linux:rpminfo_object id="obj_rhel_server" version="1"> linux:nameredhat-release-server</linux:name> </linux:rpminfo_object>
If the the check passes, the SCAP interpreter knows the particular OVAL rule is applicable to the system, executes the probes, and you get a pass/fail result. If the installed_OS_is_rhel6 check fails, the OVAL rule will be marked as "Not Applicable."
For users running derivative operating systems (CentOS, Scientific...) you can edit your CPE dictionary's regex like Jeremiah outlined. This will "fake" the system into thinking it's running RHEL6 and allow the check to be ran. -- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
I have a similar problem on AWS' AMI. OpenSCAP used to run fine, and few weeks ago it just stopped working, all checks show up as 'not applicable.' Is there a way to force it to just recognize it as RHEL/CentOS 6?
Thanks, Marcin
On Fri, Aug 15, 2014 at 1:46 PM, James Ford james.t.ford@gmail.com wrote:
Shawn, thanks for the detailed explanation. Rather than faking the system into thinking it's running RHEL6, would it be possible to update the oval definitions to include CentOS as an applicable platform?
On Fri, Aug 15, 2014 at 1:10 PM, Shawn Wells shawn@redhat.com wrote:
On 8/14/14, 5:25 PM, Jeremiah Jahn wrote:
I'm using it for SL6. The problem is in openscap-cpe-oval.xml. The test for release is searching on RedHat only.
I've changed mine to the following: notice the (redhat|sl) on the second line. You should be able to change it to whatever the centos-release rpm says. I can't remember right now if SSG is where I got the original xml file, or if it's the one from open-scap. It's very possible that you'll have to make sure that you'll have to alter the ssg-rhel6-cpe-dictionary.xml to point to your altered cpe-oval file. I've attached them just incase, but it took some tweaking.
<rpminfo_state id="oval:org.open-scap.cpe.rhel:ste:6" version="1" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#linux%22%3E <name operation="pattern
match">^(redhat|sl)-release</name>
<version operation="pattern match">^6[^\d]</version> </rpminfo_state>
To illustrate how CPE works, as part of Greg's question....
Step 1: In your OVAL check, you define which platforms the check is written for. This is done by the <affected> stanzas, such as:
<affected family="unix"> <platform>Red Hat Enterprise Linux 6</platform> </affected>
Step 2: When an SCAP interpreter parses each OVAL rule, it will parse the <affected> tag above. For each <platform> listed, it will find the associated <cpi-item> to find what <check> needs to be ran. This will tell the SCAP interpreter if the OVAL rule is applicable for the system being scanned.
For example, from SSG's CPE dictionary:
<cpe-item name="cpe:/o:redhat:enterprise_linux:6"> <title xml:lang="en-us">Red Hat Enterprise Linux 6</title> <!-- the check references an OVAL file that contains an
inventory definition -->
<check system="
http://oval.mitre.org/XMLSchema/oval-definitions-5" href="filename">installed_OS_is_rhel6</check>
</cpe-item>
In this case, if the <platform> tag matches the cpe-item/title, then the cpe-item/check will be ran. In the case of "Red Hat Enterprise Linux 6" the OVAL check "installed_OS_is_rhel6" will be ran.
The installed_OS_is_rhel6 OVAL check queries the system to see if the redhat-release-{server workstation}-6 RPM is installed, for example:
https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/6/input/che...
<linux:rpminfo_test check="all" check_existence="at_least_one_exists"
comment="redhat-release-server is version 6" id="test_rhel_server" version="1">
<linux:object object_ref="obj_rhel_server" /> <linux:state state_ref="state_rhel_server" />
</linux:rpminfo_test> <linux:rpminfo_state id="state_rhel_server" version="1"> <linux:version operation="pattern match">^6.\d+$</linux:version> </linux:rpminfo_state> <linux:rpminfo_object id="obj_rhel_server" version="1"> linux:nameredhat-release-server</linux:name> </linux:rpminfo_object>
If the the check passes, the SCAP interpreter knows the particular OVAL rule is applicable to the system, executes the probes, and you get a pass/fail result. If the installed_OS_is_rhel6 check fails, the OVAL rule will be marked as "Not Applicable."
For users running derivative operating systems (CentOS, Scientific...) you can edit your CPE dictionary's regex like Jeremiah outlined. This will "fake" the system into thinking it's running RHEL6 and allow the check to be ran. -- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
-- Sincerely,
James
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
I'm experiencing what Marci has described as well. I would agree with the goal of creating an OVAL for CentOs as well. On a similar note when I run the scan inside a Docker container "running" CentOs I get a complete scan. I'm all in with goal of creating an OVAL for CentOs and Docker containers.
Rodney Cobb rocobb@gitmachines.com @facetherathe 202-602-7077
On Aug 15, 2014, at 1:48 PM, Marcin Pohl marcinpohl@gmail.com wrote:
I have a similar problem on AWS' AMI. OpenSCAP used to run fine, and few weeks ago it just stopped working, all checks show up as 'not applicable.' Is there a way to force it to just recognize it as RHEL/CentOS 6?
Thanks, Marcin
On Fri, Aug 15, 2014 at 1:46 PM, James Ford james.t.ford@gmail.com wrote: Shawn, thanks for the detailed explanation. Rather than faking the system into thinking it's running RHEL6, would it be possible to update the oval definitions to include CentOS as an applicable platform?
On Fri, Aug 15, 2014 at 1:10 PM, Shawn Wells shawn@redhat.com wrote: On 8/14/14, 5:25 PM, Jeremiah Jahn wrote:
I'm using it for SL6. The problem is in openscap-cpe-oval.xml. The test for release is searching on RedHat only.
I've changed mine to the following: notice the (redhat|sl) on the second line. You should be able to change it to whatever the centos-release rpm says. I can't remember right now if SSG is where I got the original xml file, or if it's the one from open-scap. It's very possible that you'll have to make sure that you'll have to alter the ssg-rhel6-cpe-dictionary.xml to point to your altered cpe-oval file. I've attached them just incase, but it took some tweaking.
<rpminfo_state id="oval:org.open-scap.cpe.rhel:ste:6" version="1" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#linux%22%3E <name operation="pattern match">^(redhat|sl)-release</name> <version operation="pattern match">^6[^\d]</version> </rpminfo_state>
To illustrate how CPE works, as part of Greg's question....
Step 1: In your OVAL check, you define which platforms the check is written for. This is done by the <affected> stanzas, such as:
<affected family="unix"> <platform>Red Hat Enterprise Linux 6</platform> </affected>
Step 2: When an SCAP interpreter parses each OVAL rule, it will parse the <affected> tag above. For each <platform> listed, it will find the associated <cpi-item> to find what <check> needs to be ran. This will tell the SCAP interpreter if the OVAL rule is applicable for the system being scanned.
For example, from SSG's CPE dictionary:
<cpe-item name="cpe:/o:redhat:enterprise_linux:6"> <title xml:lang="en-us">Red Hat Enterprise Linux 6</title> <!-- the check references an OVAL file that contains an inventory definition --> <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5" href="filename">installed_OS_is_rhel6</check> </cpe-item>
In this case, if the <platform> tag matches the cpe-item/title, then the cpe-item/check will be ran. In the case of "Red Hat Enterprise Linux 6" the OVAL check "installed_OS_is_rhel6" will be ran.
The installed_OS_is_rhel6 OVAL check queries the system to see if the redhat-release-{server workstation}-6 RPM is installed, for example:
https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/6/input/che...
<linux:rpminfo_test check="all" check_existence="at_least_one_exists" comment="redhat-release-server is version 6" id="test_rhel_server" version="1"> <linux:object object_ref="obj_rhel_server" /> <linux:state state_ref="state_rhel_server" /> </linux:rpminfo_test> <linux:rpminfo_state id="state_rhel_server" version="1"> <linux:version operation="pattern match">^6.\d+$</linux:version> </linux:rpminfo_state> <linux:rpminfo_object id="obj_rhel_server" version="1"> linux:nameredhat-release-server</linux:name> </linux:rpminfo_object>
If the the check passes, the SCAP interpreter knows the particular OVAL rule is applicable to the system, executes the probes, and you get a pass/fail result. If the installed_OS_is_rhel6 check fails, the OVAL rule will be marked as "Not Applicable."
For users running derivative operating systems (CentOS, Scientific...) you can edit your CPE dictionary's regex like Jeremiah outlined. This will "fake" the system into thinking it's running RHEL6 and allow the check to be ran. -- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
-- Sincerely,
James
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
It looks like you could also just replace:
<linux:rpminfo_object id="obj_rhel_server" version="1"> linux:nameredhat-release-server</linux:name> </linux:rpminfo_object>
with: <linux:rpminfo_object id="obj_rhel_server" version="1"> linux:namecentos-release</linux:name> </linux:rpminfo_object>
Could we perhaps make that an exported variable so we could just assign it in our tailoring file as opposed to faking it? Might keep shawn out of trouble with his bosses too.. :) I get the sense that oval really doesn't have a concept of derivative OSes.
On Fri, Aug 15, 2014 at 12:48 PM, Marcin Pohl marcinpohl@gmail.com wrote:
I have a similar problem on AWS' AMI. OpenSCAP used to run fine, and few weeks ago it just stopped working, all checks show up as 'not applicable.' Is there a way to force it to just recognize it as RHEL/CentOS 6?
Thanks, Marcin
On Fri, Aug 15, 2014 at 1:46 PM, James Ford james.t.ford@gmail.com wrote:
Shawn, thanks for the detailed explanation. Rather than faking the system into thinking it's running RHEL6, would it be possible to update the oval definitions to include CentOS as an applicable platform?
On Fri, Aug 15, 2014 at 1:10 PM, Shawn Wells shawn@redhat.com wrote:
On 8/14/14, 5:25 PM, Jeremiah Jahn wrote:
I'm using it for SL6. The problem is in openscap-cpe-oval.xml. The test for release is searching on RedHat only.
I've changed mine to the following: notice the (redhat|sl) on the second line. You should be able to change it to whatever the centos-release rpm says. I can't remember right now if SSG is where I got the original xml file, or if it's the one from open-scap. It's very possible that you'll have to make sure that you'll have to alter the ssg-rhel6-cpe-dictionary.xml to point to your altered cpe-oval file. I've attached them just incase, but it took some tweaking.
<rpminfo_state id="oval:org.open-scap.cpe.rhel:ste:6" version="1" xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#linux%22%3E <name operation="pattern match">^(redhat|sl)-release</name> <version operation="pattern match">^6[^\d]</version> </rpminfo_state>
To illustrate how CPE works, as part of Greg's question....
Step 1: In your OVAL check, you define which platforms the check is written for. This is done by the <affected> stanzas, such as:
<affected family="unix"> <platform>Red Hat Enterprise Linux 6</platform> </affected>
Step 2: When an SCAP interpreter parses each OVAL rule, it will parse the <affected> tag above. For each <platform> listed, it will find the associated <cpi-item> to find what <check> needs to be ran. This will tell the SCAP interpreter if the OVAL rule is applicable for the system being scanned.
For example, from SSG's CPE dictionary:
<cpe-item name="cpe:/o:redhat:enterprise_linux:6"> <title xml:lang="en-us">Red Hat Enterprise Linux 6</title> <!-- the check references an OVAL file that contains an
inventory definition --> <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5" href="filename">installed_OS_is_rhel6</check> </cpe-item>
In this case, if the <platform> tag matches the cpe-item/title, then the cpe-item/check will be ran. In the case of "Red Hat Enterprise Linux 6" the OVAL check "installed_OS_is_rhel6" will be ran.
The installed_OS_is_rhel6 OVAL check queries the system to see if the redhat-release-{server workstation}-6 RPM is installed, for example:
https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/6/input/che...
<linux:rpminfo_test check="all" check_existence="at_least_one_exists" comment="redhat-release-server is version 6" id="test_rhel_server" version="1"> <linux:object object_ref="obj_rhel_server" /> <linux:state state_ref="state_rhel_server" /> </linux:rpminfo_test> <linux:rpminfo_state id="state_rhel_server" version="1"> <linux:version operation="pattern match">^6.\d+$</linux:version> </linux:rpminfo_state> <linux:rpminfo_object id="obj_rhel_server" version="1"> linux:nameredhat-release-server</linux:name> </linux:rpminfo_object>
If the the check passes, the SCAP interpreter knows the particular OVAL rule is applicable to the system, executes the probes, and you get a pass/fail result. If the installed_OS_is_rhel6 check fails, the OVAL rule will be marked as "Not Applicable."
For users running derivative operating systems (CentOS, Scientific...) you can edit your CPE dictionary's regex like Jeremiah outlined. This will "fake" the system into thinking it's running RHEL6 and allow the check to be ran. -- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
-- Sincerely,
James
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
While you're on the right track with a workaround, there is an important clarification to how it all works.
Step 1: In your OVAL check, you define which platforms the check is written for. This is done by the <affected> stanzas, such as:
<affected family="unix"> <platform>Red Hat Enterprise Linux 6</platform> </affected>
Step 2: When an SCAP interpreter parses each OVAL rule, it will parse the <affected> tag above. For each <platform> listed, it will find the associated <cpi-item> to find what <check> needs to be ran. This will tell the SCAP interpreter if the OVAL rule is applicable for the system being scanned.
Actually the affected/platform/product tags in the OVAL content are meaningless to processing. According to the OVAL spec:
"Each OVAL Definition is written to evaluate a certain type of system(s). The family, platform(s), and product(s) of this target are described by the AffectedType whose main purpose is to provide hints for tools using OVAL Definitions. For instance, to help a reporting tool only use Windows definitions, or to preselect only Red Hat definitions to be evaluated. Note, the inclusion of a particular platform or product does not mean the definition is physically checking for the existence of the platform or product. For the actual test to be performed, the correct test must still be included in the definition's criteria section.
The AffectedType complex type details the specific system, application, subsystem, library, etc. for which a definition has been written. If a definition is not tied to a specific product, then this element should not be included. The absence of the platform or product element can be thought of as definition applying to all platforms or products. The inclusion of a particular platform or product does not mean the definition is physically checking for the existence of the platform or product. For the actual test to be performed, the correct test must still be included in the definition's criteria section. To increase the utility of this element, care should be taken when assigning and using strings for product names. The schema places no restrictions on the values that can be assigned, potentially leading to many different representations of the same value. For example, 'Internet Explorer' and 'IE' might be used to refer to the same product. The current convention is to fully spell out all terms, and avoid the use of abbreviations at all costs.
So while the intent is to identify the applicable platform/product, what is listed there need not have any bearing on whether or not the content is executed. An OVAL interpreter could try to leverage this data to avoid running inappropriate content, but it is perfectly legal to execute the RHEL6 OVAL content on a Windows box, for example.
It is actually only the platform tags in XCCDF that behave as you've described. The id_ref in the platform tag is looked up in the CPE Dictionary file, the corresponding definition in the CPE OVAL file is evaluated, if that returns true then the Benchmark/Group/Rule (wherever the platform tag is located) is deemed applicable.
Bottom line, the workaround is correct, but the OVAL content outside of the CPE OVAL content doesn't play a part in the issue unless the OVAL interpreter used makes it an issue.
Thanks everyone for contributing to this thread. It's been very helpful.
I have had a few draft replies, but let me try to keep things short.
Many of the contributions address altering the files in the source Scap-security-guide repo. It would be great to have an upstream resolution so those installing OpenSCAP and SSG can do so via RPM (or repo) and confidently work across Fedora, RedHat, and CentOS. (Separating CentOS seems might have some nuances to consider because often us users substitute CentOS for RedHat and we may want to see "RedHat" showing up in results.)
I am still interested in how to fix the issue with the files I have installed via RPMs. I'm a little weak still on the whole build thing to be honest. But more importantly, I *want* to be aligned with what is being distributed. I want to have GovReady install OpenSCAP and SSG and then use it. I'm reluctant to fork the source SSG.
So with that in mind, I got this working. I added a new centos6-cpe-dictionary.xml file and centos6-cpe-oval.xml file. The cpe dictionary can be referenced in oscap command line and it points to the correct centos6-cpe-oval.xml file that has a modified test for CentOS.
The changes that needed to be made seem to come down to changing `redhat-release-server` (and/or `redhat-release-workstation`) to `centos-release` and changing the pattern match on the version from `^6.\d+$
On Fri, Aug 15, 2014 at 3:39 PM, Shane Shaffer shane.shaffer@g2-inc.com wrote:
While you're on the right track with a workaround, there is an important clarification to how it all works.
Step 1: In your OVAL check, you define which platforms the check is written for. This is done by the <affected> stanzas, such as:
<affected family="unix"> <platform>Red Hat Enterprise Linux 6</platform> </affected>
Step 2: When an SCAP interpreter parses each OVAL rule, it will parse the <affected> tag above. For each <platform> listed, it will find the associated <cpi-item> to find what <check> needs to be ran. This will tell the SCAP interpreter if the OVAL rule is applicable for the system being scanned.
Actually the affected/platform/product tags in the OVAL content are meaningless to processing. According to the OVAL spec:
"Each OVAL Definition is written to evaluate a certain type of system(s). The family, platform(s), and product(s) of this target are described by the AffectedType whose main purpose is to provide hints for tools using OVAL Definitions. For instance, to help a reporting tool only use Windows definitions, or to preselect only Red Hat definitions to be evaluated. Note, the inclusion of a particular platform or product does not mean the definition is physically checking for the existence of the platform or product. For the actual test to be performed, the correct test must still be included in the definition's criteria section.
The AffectedType complex type details the specific system, application, subsystem, library, etc. for which a definition has been written. If a definition is not tied to a specific product, then this element should not be included. The absence of the platform or product element can be thought of as definition applying to all platforms or products. The inclusion of a particular platform or product does not mean the definition is physically checking for the existence of the platform or product. For the actual test to be performed, the correct test must still be included in the definition's criteria section. To increase the utility of this element, care should be taken when assigning and using strings for product names. The schema places no restrictions on the values that can be assigned, potentially leading to many different representations of the same value. For example, 'Internet Explorer' and 'IE' might be used to refer to the same product. The current convention is to fully spell out all terms, and avoid the use of abbreviations at all costs.
So while the intent is to identify the applicable platform/product, what is listed there need not have any bearing on whether or not the content is executed. An OVAL interpreter could try to leverage this data to avoid running inappropriate content, but it is perfectly legal to execute the RHEL6 OVAL content on a Windows box, for example.
It is actually only the platform tags in XCCDF that behave as you've described. The id_ref in the platform tag is looked up in the CPE Dictionary file, the corresponding definition in the CPE OVAL file is evaluated, if that returns true then the Benchmark/Group/Rule (wherever the platform tag is located) is deemed applicable.
Bottom line, the workaround is correct, but the OVAL content outside of the CPE OVAL content doesn't play a part in the issue unless the OVAL interpreter used makes it an issue.
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
(Sorry - hit sent accidentally)
Thanks everyone for contributing to this thread. It's been very helpful.
I have had a few draft replies, but let me try to keep things short.
Many of the contributions address altering the files in the source Scap-security-guide repo. It would be great to have an upstream resolution so those installing OpenSCAP and SSG can do so via RPM (or repo) and confidently work across Fedora, RedHat, and CentOS. (Separating CentOS seems might have some nuances to consider because often us users substitute CentOS for RedHat and we may want to see "RedHat" showing up in results.)
I am still interested in how to fix the issue with the files I have installed via RPMs. I'm a little weak still on the whole build thing to be honest. But more importantly, I *want* to be aligned with what is being distributed. I want to have GovReady install OpenSCAP and SSG and then use it. I'm reluctant to fork the source SSG.
So with that in mind, I got this working. I added a new centos6-cpe-dictionary.xml file and centos6-cpe-oval.xml file. The cpe dictionary can be referenced in oscap command line and it points to the correct centos6-cpe-oval.xml file that has a modified test for CentOS.
The changes that needed to be made seem to come down to changing `redhat-release-server` (and/or `redhat-release-workstation`) to `centos-release` and changing the pattern match on the version from `^6.\d+$` to `^6`.
Two file attached.
ssg-centos6-cpe-dictionary.xml:
``` <cpe-list xmlns="http://cpe.mitre.org/dictionary/2.0" xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://cpe.mitre.org/dictionary/2.0 http://cpe.mitre.org/files/cpe-dictionary_2.1.xsd"> <cpe-item name="cpe:/o:redhat:enterprise_linux:6"> <title xml:lang="en-us">Red Hat Enterprise Linux 6</title> <!-- the check references an OVAL file that contains an inventory definition --> <check system=" http://oval.mitre.org/XMLSchema/oval-definitions-5" href="ssg-centos6-cpe-oval.xml">oval:ssg:def:100</check> </cpe-item> </cpe-list> ```
ssg-centos6-cpe-dictionary.xml excerpts (emphasis added):
``` <definitions> <definition class="inventory" id="oval:ssg:def:100" version="1"> <metadata> <title>CentOS Linux 6</title> <affected family="unix"> <platform>CentOS Linux 6</platform> </affected> <reference ref_id="cpe:/o:redhat:enterprise_linux:6" source="CPE"/> <description>The operating system installed on the system is CentOS Linux 6</description> </metadata> <criteria> <criterion comment="Installed operating system is part of the unix family" test_ref="oval:ssg:tst:101"/> *<criterion comment="Installed operating system is CentOS 6" test_ref="oval:ssg:tst:110"/>* </criteria> </definition> </definitions> ```
``` <tests>
</ind:family_test> *<linux:rpminfo_test check="all" check_existence="at_least_one_exists" comment="centos-release is installed" id="oval:ssg:tst:110" version="1">* * <linux:object object_ref="oval:ssg:obj:108"/>* * <linux:state state_ref="oval:ssg:ste:109"/>* * </linux:rpminfo_test>* </tests> <objects> <ind:family_object id="oval:ssg:obj:104" version="1"/> <linux:rpminfo_object id="oval:ssg:obj:106" version="1"> linux:nameredhat-release-workstation</linux:name> </linux:rpminfo_object> *<linux:rpminfo_object id="oval:ssg:obj:108" version="1">* * linux:namecentos-release</linux:name>* * </linux:rpminfo_object>* </objects> <states> <ind:family_state id="oval:ssg:ste:105" version="1"> ind:familyunix</ind:family> </ind:family_state> *<linux:rpminfo_state id="oval:ssg:ste:109" version="1">* * <linux:version operation="pattern match">^6</linux:version>* * </linux:rpminfo_state>* </states> </oval_definitions> ```
Greg Elin http://govready.org - Making FISMA compliance easier for innovators
email: gregelin@gitmachines.com phone: 917-304-3488
On Fri, Aug 15, 2014 at 3:59 PM, Greg Elin gregelin@gitmachines.com wrote:
Thanks everyone for contributing to this thread. It's been very helpful.
I have had a few draft replies, but let me try to keep things short.
Many of the contributions address altering the files in the source Scap-security-guide repo. It would be great to have an upstream resolution so those installing OpenSCAP and SSG can do so via RPM (or repo) and confidently work across Fedora, RedHat, and CentOS. (Separating CentOS seems might have some nuances to consider because often us users substitute CentOS for RedHat and we may want to see "RedHat" showing up in results.)
I am still interested in how to fix the issue with the files I have installed via RPMs. I'm a little weak still on the whole build thing to be honest. But more importantly, I *want* to be aligned with what is being distributed. I want to have GovReady install OpenSCAP and SSG and then use it. I'm reluctant to fork the source SSG.
So with that in mind, I got this working. I added a new centos6-cpe-dictionary.xml file and centos6-cpe-oval.xml file. The cpe dictionary can be referenced in oscap command line and it points to the correct centos6-cpe-oval.xml file that has a modified test for CentOS.
The changes that needed to be made seem to come down to changing `redhat-release-server` (and/or `redhat-release-workstation`) to `centos-release` and changing the pattern match on the version from `^6.\d+$
On Fri, Aug 15, 2014 at 3:39 PM, Shane Shaffer shane.shaffer@g2-inc.com wrote:
While you're on the right track with a workaround, there is an important clarification to how it all works.
Step 1: In your OVAL check, you define which platforms the check is written for. This is done by the <affected> stanzas, such as:
<affected family="unix"> <platform>Red Hat Enterprise Linux 6</platform> </affected>
Step 2: When an SCAP interpreter parses each OVAL rule, it will parse the <affected> tag above. For each <platform> listed, it will find the associated <cpi-item> to find what <check> needs to be ran. This will tell the SCAP interpreter if the OVAL rule is applicable for the system being scanned.
Actually the affected/platform/product tags in the OVAL content are meaningless to processing. According to the OVAL spec:
"Each OVAL Definition is written to evaluate a certain type of system(s). The family, platform(s), and product(s) of this target are described by the AffectedType whose main purpose is to provide hints for tools using OVAL Definitions. For instance, to help a reporting tool only use Windows definitions, or to preselect only Red Hat definitions to be evaluated. Note, the inclusion of a particular platform or product does not mean the definition is physically checking for the existence of the platform or product. For the actual test to be performed, the correct test must still be included in the definition's criteria section.
The AffectedType complex type details the specific system, application, subsystem, library, etc. for which a definition has been written. If a definition is not tied to a specific product, then this element should not be included. The absence of the platform or product element can be thought of as definition applying to all platforms or products. The inclusion of a particular platform or product does not mean the definition is physically checking for the existence of the platform or product. For the actual test to be performed, the correct test must still be included in the definition's criteria section. To increase the utility of this element, care should be taken when assigning and using strings for product names. The schema places no restrictions on the values that can be assigned, potentially leading to many different representations of the same value. For example, 'Internet Explorer' and 'IE' might be used to refer to the same product. The current convention is to fully spell out all terms, and avoid the use of abbreviations at all costs.
So while the intent is to identify the applicable platform/product, what is listed there need not have any bearing on whether or not the content is executed. An OVAL interpreter could try to leverage this data to avoid running inappropriate content, but it is perfectly legal to execute the RHEL6 OVAL content on a Windows box, for example.
It is actually only the platform tags in XCCDF that behave as you've described. The id_ref in the platform tag is looked up in the CPE Dictionary file, the corresponding definition in the CPE OVAL file is evaluated, if that returns true then the Benchmark/Group/Rule (wherever the platform tag is located) is deemed applicable.
Bottom line, the workaround is correct, but the OVAL content outside of the CPE OVAL content doesn't play a part in the issue unless the OVAL interpreter used makes it an issue.
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
On 8/15/14, 3:59 PM, Greg Elin wrote:
Thanks everyone for contributing to this thread. It's been very helpful.
I have had a few draft replies, but let me try to keep things short.
Many of the contributions address altering the files in the source Scap-security-guide repo. It would be great to have an upstream resolution so those installing OpenSCAP and SSG can do so via RPM (or repo) and confidently work across Fedora, RedHat, and CentOS. (Separating CentOS seems might have some nuances to consider because often us users substitute CentOS for RedHat and we may want to see "RedHat" showing up in results.)
I am still interested in how to fix the issue with the files I have installed via RPMs. I'm a little weak still on the whole build thing to be honest. But more importantly, I *want* to be aligned with what is being distributed. I want to have GovReady install OpenSCAP and SSG and then use it. I'm reluctant to fork the source SSG.
So with that in mind, I got this working. I added a new centos6-cpe-dictionary.xml file and centos6-cpe-oval.xml file. The cpe dictionary can be referenced in oscap command line and it points to the correct centos6-cpe-oval.xml file that has a modified test for CentOS.
The changes that needed to be made seem to come down to changing `redhat-release-server` (and/or `redhat-release-workstation`) to `centos-release` and changing the pattern match on the version from `^6.\d+$
You're entirely correct that technical enablement is trivial. It comes to the issue of Common Criteria certification. The common criteria process validates software lifecycle practices, that security functionality performs as advertised, that a piece of software can be trusted for deployment on government systems.
A colleague of mine, Gunnar Hellekson, wrote a great common criteria primer: http://atechnologyjobisnoexcuse.com/2011/12/a-common-criteria-primer/
Read it -- really -- it'll give some background to the conversation.
As noted in the blog, US Gov policy mandates that software be common criteria certified. There's no exception. If software you want to use is not common criteria certified, you contractually obligate your vendor to certify under a relevant protection profile. There's no provision for something that isn't certified.
CentOS has never undergone common criteria, has no government certifications (e.g. FIPS), no support, no security patches, no CVE/IAVA mappings, and there no plans for these things. In studies of CentOS vs RHEL by IAD, some 1/3 of the core binaries are different. CentOS != RHEL. The two can not be used interchangeably in government environments.
And relating to the DoD/IC community: due to lack of certifications, the DoD CIO and DISA FSO have not signed off on CentOS. That's why there is no STIG for CentOS. This is why the CPE checks are enabled within SSG content. CentOS simply isn't an approved operating system.
As others have pointed out, DAAs can of course authorize waivers to do whatever they want. Many DAAs chose to violate the common criteria mandate, and unfortunately, there's no true repercussions for doing so. As DAA, they have the authority to accept risk.
To educate DAAs on the risks taken during CentOS deployments, NSA IAD performed a binary analysis of CentOS6 and RHEL6. They found ~1/3 of binary packages between the two distros are different, and because of so many changes, IAD stated that inferring and understanding what changed was infeasible. How is a DAA supposed to make an informed risk decision on the use of CentOS when there are so many changes that IAD finds proper analysis infeasible?
But policies are policies, not law. DAAs are certainly able to break policies, but by using unsupported and uncertified software, must be prepared to staff, fund, and develop on their own any missing gaps.
And besides, if one chooses to use a completely untrusted operating system, why even both to harden it?
<<takes deep breath>>
Enabling CentOS on the existing profiles (stig, usgcb, c2s, cs2) is counter intuitive, as they're formal government baselines that do require a common criteria certified OS as part of their requirement set. Perhaps establishing a new profile, e.g. "centos-generic," even if it just inherits the RHEL6 STIG and disables the platform checking, would be decent compromise. Rules that deal with certain things, like crypto, would still need to fail as CentOS doesn't have FIPS.... but it could be a start.
Interesting article and discussion.
Both that blog and www.niap-ccevs.org site seems to apply specifically to "national security systems". I get why the procurement requirements are more stringent in that world, but you seem to imply that these requirements are binding on every federal IT purchase. Why? I don't want any classified or even sensitive data on my systems, so why are the purchasing requirements the same?
I am also curious why 1/3 of the CentOS binaries are different.
On Fri, Aug 15, 2014 at 2:57 PM, Shawn Wells shawn@redhat.com wrote:
On 8/15/14, 3:59 PM, Greg Elin wrote:
Thanks everyone for contributing to this thread. It's been very helpful.
I have had a few draft replies, but let me try to keep things short.
Many of the contributions address altering the files in the source Scap-security-guide repo. It would be great to have an upstream
resolution
so those installing OpenSCAP and SSG can do so via RPM (or repo) and confidently work across Fedora, RedHat, and CentOS. (Separating CentOS seems might have some nuances to consider because often us users
substitute
CentOS for RedHat and we may want to see "RedHat" showing up in results.)
I am still interested in how to fix the issue with the files I have installed via RPMs. I'm a little weak still on the whole build thing to
be
honest. But more importantly, I *want* to be aligned with what is being distributed. I want to have GovReady install OpenSCAP and SSG and then
use
it. I'm reluctant to fork the source SSG.
So with that in mind, I got this working. I added a new centos6-cpe-dictionary.xml file and centos6-cpe-oval.xml file. The cpe dictionary can be referenced in oscap command line and it points to the correct centos6-cpe-oval.xml file that has a modified test for CentOS.
The changes that needed to be made seem to come down to changing `redhat-release-server` (and/or `redhat-release-workstation`) to `centos-release` and changing the pattern match on the version from `^6.\d+$
You're entirely correct that technical enablement is trivial. It comes to the issue of Common Criteria certification. The common criteria process validates software lifecycle practices, that security functionality performs as advertised, that a piece of software can be trusted for deployment on government systems.
A colleague of mine, Gunnar Hellekson, wrote a great common criteria primer: http://atechnologyjobisnoexcuse.com/2011/12/a-common-criteria-primer/
Read it -- really -- it'll give some background to the conversation.
As noted in the blog, US Gov policy mandates that software be common criteria certified. There's no exception. If software you want to use is not common criteria certified, you contractually obligate your vendor to certify under a relevant protection profile. There's no provision for something that isn't certified.
CentOS has never undergone common criteria, has no government certifications (e.g. FIPS), no support, no security patches, no CVE/IAVA mappings, and there no plans for these things. In studies of CentOS vs RHEL by IAD, some 1/3 of the core binaries are different. CentOS != RHEL. The two can not be used interchangeably in government environments.
And relating to the DoD/IC community: due to lack of certifications, the DoD CIO and DISA FSO have not signed off on CentOS. That's why there is no STIG for CentOS. This is why the CPE checks are enabled within SSG content. CentOS simply isn't an approved operating system.
As others have pointed out, DAAs can of course authorize waivers to do whatever they want. Many DAAs chose to violate the common criteria mandate, and unfortunately, there's no true repercussions for doing so. As DAA, they have the authority to accept risk.
To educate DAAs on the risks taken during CentOS deployments, NSA IAD performed a binary analysis of CentOS6 and RHEL6. They found ~1/3 of binary packages between the two distros are different, and because of so many changes, IAD stated that inferring and understanding what changed was infeasible. How is a DAA supposed to make an informed risk decision on the use of CentOS when there are so many changes that IAD finds proper analysis infeasible?
But policies are policies, not law. DAAs are certainly able to break policies, but by using unsupported and uncertified software, must be prepared to staff, fund, and develop on their own any missing gaps.
And besides, if one chooses to use a completely untrusted operating system, why even both to harden it?
<<takes deep breath>>
Enabling CentOS on the existing profiles (stig, usgcb, c2s, cs2) is counter intuitive, as they're formal government baselines that do require a common criteria certified OS as part of their requirement set. Perhaps establishing a new profile, e.g. "centos-generic," even if it just inherits the RHEL6 STIG and disables the platform checking, would be decent compromise. Rules that deal with certain things, like crypto, would still need to fail as CentOS doesn't have FIPS.... but it could be a start. -- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
On 8/15/14, 5:44 PM, Andrew Gilmore wrote:
Interesting article and discussion.
Both that blog and www.niap-ccevs.org site seems to apply specifically to "national security systems". I get why the procurement requirements are more stringent in that world, but you seem to imply that these requirements are binding on every federal IT purchase. Why? I don't want any classified or even sensitive data on my systems, so why are the purchasing requirements the same?
Just noticed the link in Gunnar's blog was dead. Here's the updated one: https://www.niap-ccevs.org/NIAP_Evolution/faqs/nstissp-11/
And here's the definition of "What is a National Security System?": https://www.niap-ccevs.org/NIAP_Evolution/faqs/nstissp-11/#Question_III_2
Ultimately, for both DoD/IC and civilian, boil down to the Federal Information Systems Management Act of 2002 (FISMA). This actually is a *law*, and you can get a copy here: http://www.gpo.gov/fdsys/pkg/STATUTE-116/pdf/STATUTE-116-Pg2899.pdf
Skip to PDF pg58, "$11331. Responsibilities for Federal information systems standards"
- 11331(a)(1) gives NIST the power to prescribe standards and guidelines pertaining to Federal information systems. This is generally referred to as FISMA compliance.
- 11331(a)(2) defers to the president to figure out what to do for "national security systems." That's what Presidential Decision Directive (PDD-63) is all about, which ultimately created the NSTISSP. History @ https://www.niap-ccevs.org/NIAP_Evolution/faqs/nstissp-11/#Question_I_1
- 11331(b) make following FISMA or NSTISSP mandatory
So then, on the civilian side, the Department of Commerce released Federal Information Processing Standards 200 (FIPS-200), which is the "Minimum Security Requirements for Federal Information and Information Systems." You can find a copy here: http://csrc.nist.gov/publications/fips/fips200/FIPS-200-final-march.pdf
An exert from Section 1:
The E-Government Act of 2002 (Public Law 107-347), passed by the one hundred and seventh Congress and signed into law by the President in December 2002, recognized the importance of information security to the economic and national security interests of the United States. Title III of the E-Government Act, entitled the Federal Information Security Management Act (FISMA) of 2002, tasked NIST with the responsibility of developing security standards and guidelines for the federal government including the development of: • Standards for categorizing information and information systems collected or maintained by or on behalf of each federal agency based on the objectives of providing appropriate levels of information security according to a range of risk levels; • Guidelines recommending the types of information and information systems to be included in each category; and • Minimum information security requirements for information and information systems in each
such category.
The document then spells out impact levels (Section 2), and tells you to go look at NIST 800-53 for the actual, specific controls to implement once you have an impact level decision (Section 4).
So, lets hop over to NIST 800-53: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf
Skip allllll the way to PDF pg 108, "Table D-2: Security Control Baselines," and you'll see the Low/Mod/High impact levels and what controls you have to meet at each one.
Relating to the CentOS discussion, the IA-7 controls are interesting. They state:
The information system implements mechanisms for authentication to a cryptographic module that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for such authentication
The "that meet requirements of applicable federal laws... policies.. standards" bit refers to FIPS 140-2 certification. Which CentOS doesn't have.
Another goodie, SA-4(6), "Acquisition Process | Use of Information Assurance Products", which reads:
The organization: (a) Employs only government off-the-shelf (GOTS) or commercial off-the-shelf (COTS) information assurance (IA) and IA-enabled information technology products that compose an NSA-approved solution to protect classified information when the networks used to transmit the information are at a lower classification level than the information being transmitted; and (b) Ensures that these products hav
And then SA-4(7), "Acquisition Process | NIAP-Approved Protection Profiles," which reads:
The organization: (a) Limits the use of commercially provided information assurance (IA) and IA-enabled information technology products to those products that have been successfully evaluated against a National Information Assurance partnership (NIAP)-approved Protection Profile for a specific technology type, if such a profile exists; and (b) Requires, if no NIAP-approved Protection Profile exists for a specific technology type but a commercially provided information technology product relies on cryptographic functionality to enforce its security policy, that the cryptographic module is FIPS-validated.
But again, agencies must elect to follow these controls and standards. DAAs can certainly waiver them -- and in the case of wherever CentOS is being deployed -- they have (you're not running CentOS without the knowledge of your CISO/DAA, right?).
I am also curious why 1/3 of the CentOS binaries are different.
From "How is CentOS different from Red Hat Enterprise Linux?"
http://community.redhat.com/centos-faq/#_centos
While CentOS is derived from the Red Hat Enterprise Linux codebase, CentOS and Red Hat Enterprise Linux are distinguished by divergent build environments, QA processes, and, in some editions, different kernels and other open source components. For this reason, the CentOS binaries are not the same as the Red Hat Enterprise Linux binaries.
....
Once in use, the operating systems often diverge further, as users selectively install patches to address bugs and security vulnerabilities to maintain their respective installs. In addition, the CentOS Project maintains code repositories of software that are not part of the Red Hat Enterprise Linux codebase. This includes feature changes selected by the CentOS Project. These are available as extra/additional packages and environments for CentOS users.
CentOS is a "Community Development Platform," not a RHEL clone. Elliminate "clone" from the vocabulary when talking about CentOS. CentOS has its own build system away from RHEL, and the RHEL guys don't share the build details with CentOS teams. CentOS does not do CVE verification. They simply rebuild and publish. And they figure out how to rebuild on their own.
It's the CentOS *user*, not the CentOS project, that is responsible for ensuring it doesn't break their software stack and actually fixes any vulnerabilities because the CentOS project doesn't do this testing.
Once of the CentOS guys posted details to this regard: http://lists.centos.org/pipermail/centos/2014-May/143094.html
What does this mean for CentOS users ... it means that YOU are responsible to test the there is no longer an issue in YOUR environment after you do the install. If you want a CERTIFIED fix that has been tested, that is what Red Hat provides in RHEL. The reason they charge a subscription price is because the do all this testing and they provide assurance that the issues are known, fixed, tested, and certified as mitigated.
<< deep breath again >>
CentOS isn't the devil, though. It provides a nice middleground between bleeding-edge Fedora and 10yr stable RHEL. When it comes to government systems though, I fail to see any place for CentOS.
And for those who argue "we don't need RHEL for just development!": - Even development systems must follow Information Assurance guidelines spoken about above. And ok, fine, internal environments at System Integrators are not specifically called out for these regulations... however many contracts do require integrators to follow the same standards as government systems;
- CentOS isn't RHEL. If you dev/test on CentOS, you'll need to completely retest on RHEL. Two different OS'
- If you throw out the economic argument ("it's just dev! i can't double my RHEL costs for dev!"), then I'll gladly volunteer to find out who your RHT Rep is... they'd love to work the economics out with you. And besides, most RHEL subscriptions come with unlimited VMs per hypervisor these days anyway. Doesn't care if it's dev/test/prod.
Great stuff!
On Fri, Aug 15, 2014 at 5:08 PM, Shawn Wells shawn@redhat.com wrote:
- 11331(b) make following FISMA or NSTISSP mandatory
Agreed
So, lets hop over to NIST 800-53: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf
Skip allllll the way to PDF pg 108, "Table D-2: Security Control Baselines," and you'll see the Low/Mod/High impact levels and what controls you have to meet at each one.
Ok, we're in territory I recognize here.
Relating to the CentOS discussion, the IA-7 controls are interesting. They state:
The information system implements mechanisms for authentication to a
cryptographic
module that meet the requirements of applicable federal laws, Executive
Orders, directives,
policies, regulations, standards, and guidance for such authentication
The "that meet requirements of applicable federal laws... policies.. standards" bit refers to FIPS 140-2 certification. Which CentOS doesn't have.
Ok, this one is applicable to all impact levels, and CentOS doesn't have the certifications. I got that.
Another goodie, SA-4(6), "Acquisition Process | Use of Information Assurance Products", which reads: ... And then SA-4(7), "Acquisition Process | NIAP-Approved Protection Profiles," which reads:
These two are only applicable for "enhanced assurance", and are not selected even at the "High" impact level. I'd assume that this is where the national security systems deviate from the FISMA-compliant, lower impact set.
But again, agencies must elect to follow these controls and standards. DAAs can certainly waiver them -- and in the case of wherever CentOS is being deployed -- they have (you're not running CentOS without the knowledge of your CISO/DAA, right?).
Nope, I'm running Red Hat. I've heard of others in my organization running and recommending CentOS, so this is very helpful. I don't hear much about the accreditation process for those systems. Is it just the FIPS certifications, or is there more involved with a "Medium" or "Low" impact system?
CentOS isn't the devil, though. It provides a nice middleground between bleeding-edge Fedora and 10yr stable RHEL. When it comes to government systems though, I fail to see any place for CentOS.
I've heard similar arguments from Oracle reps about Postgres. :-) And people still run both CentOS and Postgres cause they're "free" and good enough. I'm much fonder of Red Hat than Oracle though. I run Oracle cause I inherited it.
I do think that RHT is missing the boat here, although I have yet to investigate what's recently been happening in CentOS and on the Desktop. Gnome 3 has been disastrous, and just when a solid Desktop entry could have jumped into the void between WinXP and Win7. Sad.
And for those who argue "we don't need RHEL for just development!":
- Even development systems must follow Information Assurance guidelines
spoken about above. And ok, fine, internal environments at System Integrators are not specifically called out for these regulations... however many contracts do require integrators to follow the same standards as government systems;
- CentOS isn't RHEL. If you dev/test on CentOS, you'll need to
completely retest on RHEL. Two different OS'
I think RHT needs to carefully consider what the purpose/audience for CentOS is. I'm hearing about Ubuntu on the server more and more, and this is a feature they trumpet.
- If you throw out the economic argument ("it's just dev! i can't double
my RHEL costs for dev!"), then I'll gladly volunteer to find out who your RHT Rep is... they'd love to work the economics out with you. And besides, most RHEL subscriptions come with unlimited VMs per hypervisor these days anyway. Doesn't care if it's dev/test/prod.
My subscriptions are all 1 supported VM. Not that I'm using it, currently. I'm also not all that enamored of running databases in VMs, but I'm considering moving that direction.
Andrew
Shawn,
Really interesting points.
Can you also speak to Fedora vs RHEL and why Fedora is included?
I think a CentOs generic is a smart approach.
Greg
Greg Elin P: 917-304-3488 E: gregelin@gitmachines.com
Sent from my iPhone
On Aug 15, 2014, at 4:57 PM, Shawn Wells shawn@redhat.com wrote:
On 8/15/14, 3:59 PM, Greg Elin wrote: Thanks everyone for contributing to this thread. It's been very helpful.
I have had a few draft replies, but let me try to keep things short.
Many of the contributions address altering the files in the source Scap-security-guide repo. It would be great to have an upstream resolution so those installing OpenSCAP and SSG can do so via RPM (or repo) and confidently work across Fedora, RedHat, and CentOS. (Separating CentOS seems might have some nuances to consider because often us users substitute CentOS for RedHat and we may want to see "RedHat" showing up in results.)
I am still interested in how to fix the issue with the files I have installed via RPMs. I'm a little weak still on the whole build thing to be honest. But more importantly, I *want* to be aligned with what is being distributed. I want to have GovReady install OpenSCAP and SSG and then use it. I'm reluctant to fork the source SSG.
So with that in mind, I got this working. I added a new centos6-cpe-dictionary.xml file and centos6-cpe-oval.xml file. The cpe dictionary can be referenced in oscap command line and it points to the correct centos6-cpe-oval.xml file that has a modified test for CentOS.
The changes that needed to be made seem to come down to changing `redhat-release-server` (and/or `redhat-release-workstation`) to `centos-release` and changing the pattern match on the version from `^6.\d+$
You're entirely correct that technical enablement is trivial. It comes to the issue of Common Criteria certification. The common criteria process validates software lifecycle practices, that security functionality performs as advertised, that a piece of software can be trusted for deployment on government systems.
A colleague of mine, Gunnar Hellekson, wrote a great common criteria primer: http://atechnologyjobisnoexcuse.com/2011/12/a-common-criteria-primer/
Read it -- really -- it'll give some background to the conversation.
As noted in the blog, US Gov policy mandates that software be common criteria certified. There's no exception. If software you want to use is not common criteria certified, you contractually obligate your vendor to certify under a relevant protection profile. There's no provision for something that isn't certified.
CentOS has never undergone common criteria, has no government certifications (e.g. FIPS), no support, no security patches, no CVE/IAVA mappings, and there no plans for these things. In studies of CentOS vs RHEL by IAD, some 1/3 of the core binaries are different. CentOS != RHEL. The two can not be used interchangeably in government environments.
And relating to the DoD/IC community: due to lack of certifications, the DoD CIO and DISA FSO have not signed off on CentOS. That's why there is no STIG for CentOS. This is why the CPE checks are enabled within SSG content. CentOS simply isn't an approved operating system.
As others have pointed out, DAAs can of course authorize waivers to do whatever they want. Many DAAs chose to violate the common criteria mandate, and unfortunately, there's no true repercussions for doing so. As DAA, they have the authority to accept risk.
To educate DAAs on the risks taken during CentOS deployments, NSA IAD performed a binary analysis of CentOS6 and RHEL6. They found ~1/3 of binary packages between the two distros are different, and because of so many changes, IAD stated that inferring and understanding what changed was infeasible. How is a DAA supposed to make an informed risk decision on the use of CentOS when there are so many changes that IAD finds proper analysis infeasible?
But policies are policies, not law. DAAs are certainly able to break policies, but by using unsupported and uncertified software, must be prepared to staff, fund, and develop on their own any missing gaps.
And besides, if one chooses to use a completely untrusted operating system, why even both to harden it?
<<takes deep breath>>
Enabling CentOS on the existing profiles (stig, usgcb, c2s, cs2) is counter intuitive, as they're formal government baselines that do require a common criteria certified OS as part of their requirement set. Perhaps establishing a new profile, e.g. "centos-generic," even if it just inherits the RHEL6 STIG and disables the platform checking, would be decent compromise. Rules that deal with certain things, like crypto, would still need to fail as CentOS doesn't have FIPS.... but it could be a start. -- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
On 8/15/14, 6:30 PM, Greg Elin wrote:
Shawn,
Really interesting points.
Can you also speak to Fedora vs RHEL and why Fedora is included?
I think a CentOs generic is a smart approach.
We've been very careful to not claim any gov baseline compliance with the Fedora content. Currently there is a generic/common profile:
https://github.com/OpenSCAP/scap-security-guide/tree/master/Fedora/input/pro...
I understand the no government certification thing and not going to argue with it. But as someone who uses Scientific linux most of the time. I'd like to propose that we either add sl and cent or a generic rhel derivative, perhaps by simply using a tailoring var. In a perfect world I'd even suggest that RHEL is treated as a specific RHEL_derivitive, just like SL or Cent. But I can only imagine the pain that would cause. I think what would be nice is if we make some centos and sl generic profiles, and fix the platform check in the OVAL definition. In a way that the derivative producers wouldn't have to mess with, but a specific user/ admin could with a simple tailoring file.
The problem as I see it right now, is that there is a pretty big barrier to entry for admins of derivative systems. Which means that there won't be a lot of eyes on the guide except for the die hards, who also happen to have the time. And that doesn't seem like a good long term thing.
I also get the sense that some of this cent os stuff is changing a "little" bit with RH pulling cent in under it's wing, but they'd be foolish to get Cent certified in any official way. If you want true certification, you should probably pay.
just my 2 cents, -jj-
On Fri, Aug 15, 2014 at 6:09 PM, Shawn Wells shawn@redhat.com wrote:
On 8/15/14, 6:30 PM, Greg Elin wrote:
Shawn,
Really interesting points.
Can you also speak to Fedora vs RHEL and why Fedora is included?
I think a CentOs generic is a smart approach.
We've been very careful to not claim any gov baseline compliance with the Fedora content. Currently there is a generic/common profile:
https://github.com/OpenSCAP/scap-security-guide/tree/master/Fedora/input/pro...
SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
In addition to Jeremiah's comment, there are many commercial organizations outside of the government who are interested in following the government standards for secure baselines as a best practice. I think it would be a benefit to all to encourage the use of secure baselines against all platforms whose consumers are security conscious. In addition, you have the added benefit of capturing more end users, I know of many organizations who start off with freely available open source and then migrate to professional grade support at a later date, it is much easier to migrate from CentOS to say RH then it would be from Ubuntu or other distro to RH and by that time many organizations will stick with what they know and the skills of the current support personnel. That being said I understand that everyone has limited time and resources, but if there is a way to help downstream consumers implement secure baselines I think it would benefit all.
On Tue, Aug 19, 2014 at 9:51 AM, Jeremiah Jahn < jeremiah@goodinassociates.com> wrote:
I understand the no government certification thing and not going to argue with it. But as someone who uses Scientific linux most of the time. I'd like to propose that we either add sl and cent or a generic rhel derivative, perhaps by simply using a tailoring var. In a perfect world I'd even suggest that RHEL is treated as a specific RHEL_derivitive, just like SL or Cent. But I can only imagine the pain that would cause. I think what would be nice is if we make some centos and sl generic profiles, and fix the platform check in the OVAL definition. In a way that the derivative producers wouldn't have to mess with, but a specific user/ admin could with a simple tailoring file.
The problem as I see it right now, is that there is a pretty big barrier to entry for admins of derivative systems. Which means that there won't be a lot of eyes on the guide except for the die hards, who also happen to have the time. And that doesn't seem like a good long term thing.
I also get the sense that some of this cent os stuff is changing a "little" bit with RH pulling cent in under it's wing, but they'd be foolish to get Cent certified in any official way. If you want true certification, you should probably pay.
just my 2 cents, -jj-
On Fri, Aug 15, 2014 at 6:09 PM, Shawn Wells shawn@redhat.com wrote:
On 8/15/14, 6:30 PM, Greg Elin wrote:
Shawn,
Really interesting points.
Can you also speak to Fedora vs RHEL and why Fedora is included?
I think a CentOs generic is a smart approach.
We've been very careful to not claim any gov baseline compliance with the Fedora content. Currently there is a generic/common profile:
https://github.com/OpenSCAP/scap-security-guide/tree/master/Fedora/input/pro...
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
One major thing in Jeremiah's comment really stood out to me:
In a perfect world I'd even suggest that RHEL is treated as a
specific RHEL_derivitive, just like SL or Cent.
I'm not sure how it would make any sense to treat the original product (RHEL) exactly the same as the two major derivatives (CentOS and Scientific Linux). The notion of treating a thing as a derivative of itself just seems...odd. There's naturally going to be something of a barrier to entry when one uses something developed for one thing and expects it to flawlessly work for that thing's derivatives. RHT engineering and development have contributed significant time and resources to SSG to help ensure the guidance and content work perfectly with their product. They cannot (and reasonably wouldn't) attempt to guarantee the supportability and applicability of SSG for derivative offerings, as the CentOS and SL dev teams could - at any point - alter something from the upstream.
On Tue, Aug 19, 2014 at 9:51 AM, Jeremiah Jahn < jeremiah@goodinassociates.com> wrote:
I understand the no government certification thing and not going to argue with it. But as someone who uses Scientific linux most of the time. I'd like to propose that we either add sl and cent or a generic rhel derivative, perhaps by simply using a tailoring var. In a perfect world I'd even suggest that RHEL is treated as a specific RHEL_derivitive, just like SL or Cent. But I can only imagine the pain that would cause. I think what would be nice is if we make some centos and sl generic profiles, and fix the platform check in the OVAL definition. In a way that the derivative producers wouldn't have to mess with, but a specific user/ admin could with a simple tailoring file.
The problem as I see it right now, is that there is a pretty big barrier to entry for admins of derivative systems. Which means that there won't be a lot of eyes on the guide except for the die hards, who also happen to have the time. And that doesn't seem like a good long term thing.
I also get the sense that some of this cent os stuff is changing a "little" bit with RH pulling cent in under it's wing, but they'd be foolish to get Cent certified in any official way. If you want true certification, you should probably pay.
just my 2 cents, -jj-
On Fri, Aug 15, 2014 at 6:09 PM, Shawn Wells shawn@redhat.com wrote:
On 8/15/14, 6:30 PM, Greg Elin wrote:
Shawn,
Really interesting points.
Can you also speak to Fedora vs RHEL and why Fedora is included?
I think a CentOs generic is a smart approach.
We've been very careful to not claim any gov baseline compliance with the Fedora content. Currently there is a generic/common profile:
https://github.com/OpenSCAP/scap-security-guide/tree/master/Fedora/input/pro...
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
LOL. This was from a strictly coding point of view and I'm well aware that this would probably never happen. My general thinking in life is to put all of the commonalities in the parent, and the modifications in the child. This would let RHEL, Cent et al focus on the commonalities, while any differences between them would go in each special derivative. At the same time I realise it's next to impossible for RedHat to keep track whatever crazy things the Cent folks have decided to change. I'd fully expect RH to plop everything they do into the parent section, and their derivative to make no changes whatsoever. Right now, it seems we have the following unix->Linux->RHEL. I don't really see a lot of checks in Linux or Unix. So it would be nice to move as many checks up the tree to their highest level. RH and debian are LSB derivatives, and obviously many things derive even further from them. I'm not even sure where fedora fits in all of that. So please don't take that part of my comments too seriously, it was just food for thought.
On Fri, Aug 22, 2014 at 7:06 AM, David Smith dsmith@secure-innovations.net wrote:
One major thing in Jeremiah's comment really stood out to me:
In a perfect world I'd even suggest that RHEL is treated as a specific RHEL_derivitive, just like SL or Cent.
I'm not sure how it would make any sense to treat the original product (RHEL) exactly the same as the two major derivatives (CentOS and Scientific Linux). The notion of treating a thing as a derivative of itself just seems...odd. There's naturally going to be something of a barrier to entry when one uses something developed for one thing and expects it to flawlessly work for that thing's derivatives. RHT engineering and development have contributed significant time and resources to SSG to help ensure the guidance and content work perfectly with their product. They cannot (and reasonably wouldn't) attempt to guarantee the supportability and applicability of SSG for derivative offerings, as the CentOS and SL dev teams could - at any point - alter something from the upstream.
On Tue, Aug 19, 2014 at 9:51 AM, Jeremiah Jahn jeremiah@goodinassociates.com wrote:
I understand the no government certification thing and not going to argue with it. But as someone who uses Scientific linux most of the time. I'd like to propose that we either add sl and cent or a generic rhel derivative, perhaps by simply using a tailoring var. In a perfect world I'd even suggest that RHEL is treated as a specific RHEL_derivitive, just like SL or Cent. But I can only imagine the pain that would cause. I think what would be nice is if we make some centos and sl generic profiles, and fix the platform check in the OVAL definition. In a way that the derivative producers wouldn't have to mess with, but a specific user/ admin could with a simple tailoring file.
The problem as I see it right now, is that there is a pretty big barrier to entry for admins of derivative systems. Which means that there won't be a lot of eyes on the guide except for the die hards, who also happen to have the time. And that doesn't seem like a good long term thing.
I also get the sense that some of this cent os stuff is changing a "little" bit with RH pulling cent in under it's wing, but they'd be foolish to get Cent certified in any official way. If you want true certification, you should probably pay.
just my 2 cents, -jj-
On Fri, Aug 15, 2014 at 6:09 PM, Shawn Wells shawn@redhat.com wrote:
On 8/15/14, 6:30 PM, Greg Elin wrote:
Shawn,
Really interesting points.
Can you also speak to Fedora vs RHEL and why Fedora is included?
I think a CentOs generic is a smart approach.
We've been very careful to not claim any gov baseline compliance with the Fedora content. Currently there is a generic/common profile:
https://github.com/OpenSCAP/scap-security-guide/tree/master/Fedora/input/pro...
SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
On 8/15/14, 3:39 PM, Shane Shaffer wrote:
While you're on the right track with a workaround, there is an important clarification to how it all works.
Step 1: In your OVAL check, you define which platforms the check is written for. This is done by the <affected> stanzas, such as:
<affected family="unix"> <platform>Red Hat Enterprise Linux 6</platform> </affected>
Step 2: When an SCAP interpreter parses each OVAL rule, it will parse the <affected> tag above. For each <platform> listed, it will find the associated <cpi-item> to find what <check> needs to be ran. This will tell the SCAP interpreter if the OVAL rule is applicable for the system being scanned.
Actually the affected/platform/product tags in the OVAL content are meaningless to processing. According to the OVAL spec:
"Each OVAL Definition is written to evaluate a certain type of system(s). The family, platform(s), and product(s) of this target are described by the AffectedType whose main purpose is to provide hints for tools using OVAL Definitions. For instance, to help a reporting tool only use Windows definitions, or to preselect only Red Hat definitions to be evaluated. Note, the inclusion of a particular platform or product does not mean the definition is physically checking for the existence of the platform or product. For the actual test to be performed, the correct test must still be included in the definition's criteria section.
The AffectedType complex type details the specific system, application, subsystem, library, etc. for which a definition has been written. If a definition is not tied to a specific product, then this element should not be included. The absence of the platform or product element can be thought of as definition applying to all platforms or products. The inclusion of a particular platform or product does not mean the definition is physically checking for the existence of the platform or product. For the actual test to be performed, the correct test must still be included in the definition's criteria section. To increase the utility of this element, care should be taken when assigning and using strings for product names. The schema places no restrictions on the values that can be assigned, potentially leading to many different representations of the same value. For example, 'Internet Explorer' and 'IE' might be used to refer to the same product. The current convention is to fully spell out all terms, and avoid the use of abbreviations at all costs.
So while the intent is to identify the applicable platform/product, what is listed there need not have any bearing on whether or not the content is executed. An OVAL interpreter could try to leverage this data to avoid running inappropriate content, but it is perfectly legal to execute the RHEL6 OVAL content on a Windows box, for example.
It is actually only the platform tags in XCCDF that behave as you've described. The id_ref in the platform tag is looked up in the CPE Dictionary file, the corresponding definition in the CPE OVAL file is evaluated, if that returns true then the Benchmark/Group/Rule (wherever the platform tag is located) is deemed applicable.
Thanks for the response, but I'm missing how this differs from what I mentioned.
SSG OVAL rules call out a platform ("Red Hat Enterprise Linux 6", "Fedora 19"). That gets checked against the CPE dictionary which offers an OVAL rule to run, which will indicate if you're on the appropriate platform. Upon match the OVAL rule is ran, else "Not Applicable"
Bottom line, the workaround is correct, but the OVAL content outside of the CPE OVAL content doesn't play a part in the issue unless the OVAL interpreter used makes it an issue.
You said that the interpreter uses the platform tags in the OVAL content to determine applicability, but that doesn't happen - applicability determination via platform tags is an XCCDF function. The platform and product tags in the OVAL content are almost purely decorative, never evaluated (As the spec says, they're hints, an interpreter could use them, but doesn't have to. Most/all don't).
The flow is: 1) platform tag encountered in the XCCDF in a benchmark, group, or rule 2) platform id_ref is found in the CPE Dictionary 3) OVAL definition referenced from CPE Dictionary is found in CPE OVAL 4) XCCDF interpreter calls OVAL interpreter to evaluate that platform checking OVAL definition 5) OVAL interpreter returns result to XCCDF interpreter 6) If false, Not Applicable If true, the benchmark/group/rule is applicable --> eventually the meaty OVAL/OCIL gets evaluated, even if the platform tags in those OVAL definitions are completely inappropriate
Again, the suggested fix is valid, but the source of the problem is the platform tags in the XCCDF, not the platform tags in the OVAL.
On Fri, Aug 15, 2014 at 4:05 PM, Shawn Wells shawn@redhat.com wrote:
On 8/15/14, 3:39 PM, Shane Shaffer wrote:
While you're on the right track with a workaround, there is an important clarification to how it all works.
Step 1: In your OVAL check, you define which platforms the check is written for. This is done by the <affected> stanzas, such as:
<affected family="unix"> <platform>Red Hat Enterprise Linux 6</platform> </affected>
Step 2: When an SCAP interpreter parses each OVAL rule, it will parse the <affected> tag above. For each <platform> listed, it will find the associated <cpi-item> to find what <check> needs to be ran. This will tell the SCAP interpreter if the OVAL rule is applicable for the
system
being scanned.
Actually the affected/platform/product tags in the OVAL content are meaningless to processing. According to the OVAL spec:
"Each OVAL Definition is written to evaluate a certain type of system(s). The family, platform(s), and product(s) of this target are described by
the
AffectedType whose main purpose is to provide hints for tools using OVAL Definitions. For instance, to help a reporting tool only use Windows definitions, or to preselect only Red Hat definitions to be evaluated. Note, the inclusion of a particular platform or product does not mean the definition is physically checking for the existence of the platform or product. For the actual test to be performed, the correct test must still be included in the definition's criteria section.
The AffectedType complex type details the specific system, application, subsystem, library, etc. for which a definition has been written. If a definition is not tied to a specific product, then this element should
not
be included. The absence of the platform or product element can be
thought
of as definition applying to all platforms or products. The inclusion of
a
particular platform or product does not mean the definition is physically checking for the existence of the platform or product. For the actual
test
to be performed, the correct test must still be included in the definition's criteria section. To increase the utility of this element, care should be taken when assigning and using strings for product names. The schema places no restrictions on the values that can be assigned, potentially leading to many different representations of the same value. For example, 'Internet Explorer' and 'IE' might be used to refer to the same product. The current convention is to fully spell out all terms, and avoid the use of abbreviations at all costs.
So while the intent is to identify the applicable platform/product, what
is
listed there need not have any bearing on whether or not the content is executed. An OVAL interpreter could try to leverage this data to avoid running inappropriate content, but it is perfectly legal to execute the RHEL6 OVAL content on a Windows box, for example.
It is actually only the platform tags in XCCDF that behave as you've described. The id_ref in the platform tag is looked up in the CPE Dictionary file, the corresponding definition in the CPE OVAL file is evaluated, if that returns true then the Benchmark/Group/Rule (wherever
the
platform tag is located) is deemed applicable.
Thanks for the response, but I'm missing how this differs from what I mentioned.
SSG OVAL rules call out a platform ("Red Hat Enterprise Linux 6", "Fedora 19"). That gets checked against the CPE dictionary which offers an OVAL rule to run, which will indicate if you're on the appropriate platform. Upon match the OVAL rule is ran, else "Not Applicable"
Bottom line, the workaround is correct, but the OVAL content outside of
the
CPE OVAL content doesn't play a part in the issue unless the OVAL interpreter used makes it an issue.
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
On 08/17/2014 09:29 PM, Shane Shaffer wrote:
Again, the suggested fix is valid, but the source of the problem is the platform tags in the XCCDF, not the platform tags in the OVAL.
That is correct.
It is also possible to remove the XCCDF <platform> element(s) entirely and simply assign the benchmark to be evaluated on an arbitrary target.
Those who have Scientific Linux for which (AFAIK) no CPEs exist can employ such a technique (or, as previously mentioned, make the related CPE OVAL check more catholic).
Ah, this is because you are using the prebuilt release package which has slightly different checks than what is on the trunk.
Try the attached file in place of you existing one.
The prebuilt package looks for redhat-release-workstation and redhat-release-server packages.
CentOS does not offer these similar packages. So instead I modified both of those to indicate centos-release, which is a valid package. Versioning should match up as is.
That is all that is needed.
I would not go any further as to create new checks inside the prebuilt package as this may mess up the numbering schema for all the checks created when the SSG package is built.
However, a check could easily be added in the source location I previously mentioned to also accept CentOS 6 as a valid target. Or a new CentOS6 check could be added as described and referenced in the CPE dictionary:
scap-security-guide\RHEL\6\input\checks\platform\rhel6-cpe-dictionary.xml
Best regards,
Trey Henefield, CISSP Senior IAVA Engineer
Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA
Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.com
From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Rui Pedro Bernardino Sent: Wednesday, June 18, 2014 7:21 AM To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
It requires an extra hack because ‘version’ on CentOS won’t match the specified pattern; here is how I did it to keep it compatible with RHEL: 1. Add an extra criterion: <criteria operator="OR"> <criterion comment="Red Hat Enterprise Linux 6 Workstation is installed" test_ref="test_rhel_workstation" /> <criterion comment="Red Hat Enterprise Linux 6 Server is installed" test_ref="test_rhel_server" /> <criterion comment="CentOS 6 is installed" test_ref="test_centos" /> </criteria> 2. Add an extra test: <linux:rpminfo_test check="all" check_existence="at_least_one_exists" comment="centos-release is version 6" id="test_centos" version="1"> <linux:object object_ref="obj_centos" /> <linux:state state_ref="state_centos" /> </linux:rpminfo_test> <linux:rpminfo_state id="state_centos" version="1"> <linux:version operation="pattern match">^6</linux:version> </linux:rpminfo_state> <linux:rpminfo_object id="obj_centos" version="1"> linux:namecentos-release</linux:name> </linux:rpminfo_object>
Another weirder issue on the original SSG check: I don’t think this check works on ‘pure’ RHEL6 either but the platform still matches for some reason I do not understand.
When I use ‘—oval-results’, the CPE result file (ssg-rhel6-cpe-oval.xml.result.xml), the test_rhel_* tests all fail for the same reason, i.e: lin-sys:version6Server</lin-sys:version> Won’t match: <lin-def:version operation="pattern match">^6.\d+$</lin-def:version>
Thus resulting in ‘false’ for test_rhel_server: <test test_id="oval:ssg:tst:103" version="1" check="all" result="false"> <tested_item item_id="1046111" result="false"/> </test>
and consequently for installed_OS_is_rhel6: <definition definition_id="oval:ssg:def:100" result="false" version="1">
But the definition still works ok, although it doesn’t on CentOS… What am I getting wrong were?
Thanks!
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Trey Henefield Sent: quarta-feira, 18 de Junho de 2014 12:31 To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
The check for Red Hat 6 is pulled from:
scap-security-guide\RHEL\6\input\checks\installed_OS_is_rhel6.xml
Simply change the two references to 'redhat-release' to state 'centos-release' instead. Then rebuild.
That should do it.
Best regards,
Trey Henefield, CISSP Senior IAVA Engineer
Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA
Trey.Henefield@ultra-ats.commailto:Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.comhttp://www.ultra-ats.com
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Pettorino, Jeffrey D CTR USAF USAFA USAFA/DFAN Sent: Tuesday, June 17, 2014 4:01 PM To: 'scap-security-guide@lists.fedorahosted.org' Subject: Anyone using rhel6 ssg for centos6?
I have been trying to get oscap working on my CentOS6.5 network core, without luck.
Everything comes back with "Result notapplicable".
I am pretty new to SCAP and XCCDF, but am a long-time user of Nessus and Security Center (prior to ACAS program by DISA).
Does anyone have suggestions where I can find some in depth guidance to adjust the rhel6 configs to CentOS?
-- Jeff
v/r, Jeffrey D. Pettorino, GCIH, CISSP Systems Engineer High Performance Computing Research Center United States Air Force Academy Jeffrey.Pettorino.ctr@USAFA.edumailto:Jeffrey.Pettorino.ctr@USAFA.edu 719/333-9391 ---- The use of the Unix philosophy just for UNIX was a great waste. Fortunately, Linux came along. - Bellevue Linux User Group member, 2005
Disclaimer The information contained in this communication from trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com sent at 2014-06-18 07:30:57 is private and may be legally privileged or export controlled. It is intended solely for use by scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.
I’m also building from the GIT version.
Anyway, using your file: # cat /etc/redhat-release CentOS release 6.2 (Final) # oscap oval eval --results ssg-rhel6-cpe-oval.results.xml ssg-rhel6-cpe-oval.xml Definition oval:ssg:def:100: false Evaluation done.
When I edit the file and replace <linux:version operation="pattern match">^6.\d+$</linux:version> by <linux:version operation="pattern match">^6</linux:version>
And re-run: # oscap oval eval --results ssg-rhel6-cpe-oval.results.xml ssg-rhel6-cpe-oval.xml Definition oval:ssg:def:100: true Evaluation done.
Also have a look at the end of “ssg-rhel6-cpe-oval.results.xml”. “lin-sys:version” is “6” not “6.2”.
SSG’s platform check doesn’t work on Red Hat either; using scap-security-guid/RHEL/6/dist/content: # cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.5 (Santiago) # oscap oval eval ssg-rhel6-cpe-oval.xml Definition oval:ssg:def:100: false Evaluation done.
And it will work if I edit the “pattern match” as on CentOS.
I think the platform CPE get defined through OpenSCAP’s CPE OVAL, not SSG’s. Just try move /usr/share/openscap/cpe/openscap-cpe-dict.xml to something else and try to run a xccdf eval.
Or am I messing things up?
Best regards
From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Trey Henefield Sent: quarta-feira, 18 de Junho de 2014 15:04 To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
Ah, this is because you are using the prebuilt release package which has slightly different checks than what is on the trunk.
Try the attached file in place of you existing one.
The prebuilt package looks for redhat-release-workstation and redhat-release-server packages.
CentOS does not offer these similar packages. So instead I modified both of those to indicate centos-release, which is a valid package. Versioning should match up as is.
That is all that is needed.
I would not go any further as to create new checks inside the prebuilt package as this may mess up the numbering schema for all the checks created when the SSG package is built.
However, a check could easily be added in the source location I previously mentioned to also accept CentOS 6 as a valid target. Or a new CentOS6 check could be added as described and referenced in the CPE dictionary:
scap-security-guide\RHEL\6\input\checks\platform\rhel6-cpe-dictionary.xml
Best regards,
Trey Henefield, CISSP Senior IAVA Engineer
Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA
Trey.Henefield@ultra-ats.commailto:Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.comhttp://www.ultra-ats.com
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Rui Pedro Bernardino Sent: Wednesday, June 18, 2014 7:21 AM To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
It requires an extra hack because ‘version’ on CentOS won’t match the specified pattern; here is how I did it to keep it compatible with RHEL: 1. Add an extra criterion: <criteria operator="OR"> <criterion comment="Red Hat Enterprise Linux 6 Workstation is installed" test_ref="test_rhel_workstation" /> <criterion comment="Red Hat Enterprise Linux 6 Server is installed" test_ref="test_rhel_server" /> <criterion comment="CentOS 6 is installed" test_ref="test_centos" /> </criteria> 2. Add an extra test: <linux:rpminfo_test check="all" check_existence="at_least_one_exists" comment="centos-release is version 6" id="test_centos" version="1"> <linux:object object_ref="obj_centos" /> <linux:state state_ref="state_centos" /> </linux:rpminfo_test> <linux:rpminfo_state id="state_centos" version="1"> <linux:version operation="pattern match">^6</linux:version> </linux:rpminfo_state> <linux:rpminfo_object id="obj_centos" version="1"> linux:namecentos-release</linux:name> </linux:rpminfo_object>
Another weirder issue on the original SSG check: I don’t think this check works on ‘pure’ RHEL6 either but the platform still matches for some reason I do not understand.
When I use ‘—oval-results’, the CPE result file (ssg-rhel6-cpe-oval.xml.result.xml), the test_rhel_* tests all fail for the same reason, i.e: lin-sys:version6Server</lin-sys:version> Won’t match: <lin-def:version operation="pattern match">^6.\d+$</lin-def:version>
Thus resulting in ‘false’ for test_rhel_server: <test test_id="oval:ssg:tst:103" version="1" check="all" result="false"> <tested_item item_id="1046111" result="false"/> </test>
and consequently for installed_OS_is_rhel6: <definition definition_id="oval:ssg:def:100" result="false" version="1">
But the definition still works ok, although it doesn’t on CentOS… What am I getting wrong were?
Thanks!
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Trey Henefield Sent: quarta-feira, 18 de Junho de 2014 12:31 To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
The check for Red Hat 6 is pulled from:
scap-security-guide\RHEL\6\input\checks\installed_OS_is_rhel6.xml
Simply change the two references to 'redhat-release' to state 'centos-release' instead. Then rebuild.
That should do it.
Best regards,
Trey Henefield, CISSP Senior IAVA Engineer
Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA
Trey.Henefield@ultra-ats.commailto:Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.comhttp://www.ultra-ats.com
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Pettorino, Jeffrey D CTR USAF USAFA USAFA/DFAN Sent: Tuesday, June 17, 2014 4:01 PM To: 'scap-security-guide@lists.fedorahosted.org' Subject: Anyone using rhel6 ssg for centos6?
I have been trying to get oscap working on my CentOS6.5 network core, without luck.
Everything comes back with "Result notapplicable".
I am pretty new to SCAP and XCCDF, but am a long-time user of Nessus and Security Center (prior to ACAS program by DISA).
Does anyone have suggestions where I can find some in depth guidance to adjust the rhel6 configs to CentOS?
-- Jeff
v/r, Jeffrey D. Pettorino, GCIH, CISSP Systems Engineer High Performance Computing Research Center United States Air Force Academy Jeffrey.Pettorino.ctr@USAFA.edumailto:Jeffrey.Pettorino.ctr@USAFA.edu 719/333-9391 ---- The use of the Unix philosophy just for UNIX was a great waste. Fortunately, Linux came along. - Bellevue Linux User Group member, 2005
Disclaimer The information contained in this communication from trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com sent at 2014-06-18 07:30:57 is private and may be legally privileged or export controlled. It is intended solely for use by scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.
Yes, I don’t have CentOS 6 installed so I couldn’t verify, but from looking at the package on their site, it appeared as if the version indicated would work.
I am not sure about how the openscap software itself resolves CPE entries, or if it does at all. But from creating other SSGs, it has been my experience that you could pretty much define any CPE name. The key is in the cpe-oval check it is attached to by the cpe-dictionary.
The previous change I did will remove support for Red Hat.
Here is an updated file that should allow being used for both Red Hat 6 and CentOS 6.
Best regards,
Trey Henefield, CISSP Senior IAVA Engineer
Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA
Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.com
From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Rui Pedro Bernardino Sent: Wednesday, June 18, 2014 9:39 AM To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
I’m also building from the GIT version.
Anyway, using your file: # cat /etc/redhat-release CentOS release 6.2 (Final) # oscap oval eval --results ssg-rhel6-cpe-oval.results.xml ssg-rhel6-cpe-oval.xml Definition oval:ssg:def:100: false Evaluation done.
When I edit the file and replace <linux:version operation="pattern match">^6.\d+$</linux:version> by <linux:version operation="pattern match">^6</linux:version>
And re-run: # oscap oval eval --results ssg-rhel6-cpe-oval.results.xml ssg-rhel6-cpe-oval.xml Definition oval:ssg:def:100: true Evaluation done.
Also have a look at the end of “ssg-rhel6-cpe-oval.results.xml”. “lin-sys:version” is “6” not “6.2”.
SSG’s platform check doesn’t work on Red Hat either; using scap-security-guid/RHEL/6/dist/content: # cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.5 (Santiago) # oscap oval eval ssg-rhel6-cpe-oval.xml Definition oval:ssg:def:100: false Evaluation done.
And it will work if I edit the “pattern match” as on CentOS.
I think the platform CPE get defined through OpenSCAP’s CPE OVAL, not SSG’s. Just try move /usr/share/openscap/cpe/openscap-cpe-dict.xml to something else and try to run a xccdf eval.
Or am I messing things up?
Best regards
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Trey Henefield Sent: quarta-feira, 18 de Junho de 2014 15:04 To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
Ah, this is because you are using the prebuilt release package which has slightly different checks than what is on the trunk.
Try the attached file in place of you existing one.
The prebuilt package looks for redhat-release-workstation and redhat-release-server packages.
CentOS does not offer these similar packages. So instead I modified both of those to indicate centos-release, which is a valid package. Versioning should match up as is.
That is all that is needed.
I would not go any further as to create new checks inside the prebuilt package as this may mess up the numbering schema for all the checks created when the SSG package is built.
However, a check could easily be added in the source location I previously mentioned to also accept CentOS 6 as a valid target. Or a new CentOS6 check could be added as described and referenced in the CPE dictionary:
scap-security-guide\RHEL\6\input\checks\platform\rhel6-cpe-dictionary.xml
Best regards,
Trey Henefield, CISSP Senior IAVA Engineer
Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA
Trey.Henefield@ultra-ats.commailto:Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.comhttp://www.ultra-ats.com
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Rui Pedro Bernardino Sent: Wednesday, June 18, 2014 7:21 AM To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
It requires an extra hack because ‘version’ on CentOS won’t match the specified pattern; here is how I did it to keep it compatible with RHEL: 1. Add an extra criterion: <criteria operator="OR"> <criterion comment="Red Hat Enterprise Linux 6 Workstation is installed" test_ref="test_rhel_workstation" /> <criterion comment="Red Hat Enterprise Linux 6 Server is installed" test_ref="test_rhel_server" /> <criterion comment="CentOS 6 is installed" test_ref="test_centos" /> </criteria> 2. Add an extra test: <linux:rpminfo_test check="all" check_existence="at_least_one_exists" comment="centos-release is version 6" id="test_centos" version="1"> <linux:object object_ref="obj_centos" /> <linux:state state_ref="state_centos" /> </linux:rpminfo_test> <linux:rpminfo_state id="state_centos" version="1"> <linux:version operation="pattern match">^6</linux:version> </linux:rpminfo_state> <linux:rpminfo_object id="obj_centos" version="1"> linux:namecentos-release</linux:name> </linux:rpminfo_object>
Another weirder issue on the original SSG check: I don’t think this check works on ‘pure’ RHEL6 either but the platform still matches for some reason I do not understand.
When I use ‘—oval-results’, the CPE result file (ssg-rhel6-cpe-oval.xml.result.xml), the test_rhel_* tests all fail for the same reason, i.e: lin-sys:version6Server</lin-sys:version> Won’t match: <lin-def:version operation="pattern match">^6.\d+$</lin-def:version>
Thus resulting in ‘false’ for test_rhel_server: <test test_id="oval:ssg:tst:103" version="1" check="all" result="false"> <tested_item item_id="1046111" result="false"/> </test>
and consequently for installed_OS_is_rhel6: <definition definition_id="oval:ssg:def:100" result="false" version="1">
But the definition still works ok, although it doesn’t on CentOS… What am I getting wrong were?
Thanks!
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Trey Henefield Sent: quarta-feira, 18 de Junho de 2014 12:31 To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
The check for Red Hat 6 is pulled from:
scap-security-guide\RHEL\6\input\checks\installed_OS_is_rhel6.xml
Simply change the two references to 'redhat-release' to state 'centos-release' instead. Then rebuild.
That should do it.
Best regards,
Trey Henefield, CISSP Senior IAVA Engineer
Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA
Trey.Henefield@ultra-ats.commailto:Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.comhttp://www.ultra-ats.com
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Pettorino, Jeffrey D CTR USAF USAFA USAFA/DFAN Sent: Tuesday, June 17, 2014 4:01 PM To: 'scap-security-guide@lists.fedorahosted.org' Subject: Anyone using rhel6 ssg for centos6?
I have been trying to get oscap working on my CentOS6.5 network core, without luck.
Everything comes back with "Result notapplicable".
I am pretty new to SCAP and XCCDF, but am a long-time user of Nessus and Security Center (prior to ACAS program by DISA).
Does anyone have suggestions where I can find some in depth guidance to adjust the rhel6 configs to CentOS?
-- Jeff
v/r, Jeffrey D. Pettorino, GCIH, CISSP Systems Engineer High Performance Computing Research Center United States Air Force Academy Jeffrey.Pettorino.ctr@USAFA.edumailto:Jeffrey.Pettorino.ctr@USAFA.edu 719/333-9391 ---- The use of the Unix philosophy just for UNIX was a great waste. Fortunately, Linux came along. - Bellevue Linux User Group member, 2005
Disclaimer The information contained in this communication from trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com sent at 2014-06-18 07:30:57 is private and may be legally privileged or export controlled. It is intended solely for use by scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.
My point with your initial CentOS suggestion is that it should work, but it doesn’t because SSG RHEL’s CPEs are broken.
This version works perfectly on CentOS but gets an error on RHEL: <system_data> <lin-sys:rpminfo_item id="1069901" status="error"> lin-sys:nameredhat-release-(?:workstation|server)</lin-sys:name> </lin-sys:rpminfo_item> </system_data>
Can you use REs in the rpminfo object name?
From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Trey Henefield Sent: quarta-feira, 18 de Junho de 2014 15:59 To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
Yes, I don’t have CentOS 6 installed so I couldn’t verify, but from looking at the package on their site, it appeared as if the version indicated would work.
I am not sure about how the openscap software itself resolves CPE entries, or if it does at all. But from creating other SSGs, it has been my experience that you could pretty much define any CPE name. The key is in the cpe-oval check it is attached to by the cpe-dictionary.
The previous change I did will remove support for Red Hat.
Here is an updated file that should allow being used for both Red Hat 6 and CentOS 6.
Best regards,
Trey Henefield, CISSP Senior IAVA Engineer
Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA
Trey.Henefield@ultra-ats.commailto:Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.comhttp://www.ultra-ats.com
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Rui Pedro Bernardino Sent: Wednesday, June 18, 2014 9:39 AM To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
I’m also building from the GIT version.
Anyway, using your file: # cat /etc/redhat-release CentOS release 6.2 (Final) # oscap oval eval --results ssg-rhel6-cpe-oval.results.xml ssg-rhel6-cpe-oval.xml Definition oval:ssg:def:100: false Evaluation done.
When I edit the file and replace <linux:version operation="pattern match">^6.\d+$</linux:version> by <linux:version operation="pattern match">^6</linux:version>
And re-run: # oscap oval eval --results ssg-rhel6-cpe-oval.results.xml ssg-rhel6-cpe-oval.xml Definition oval:ssg:def:100: true Evaluation done.
Also have a look at the end of “ssg-rhel6-cpe-oval.results.xml”. “lin-sys:version” is “6” not “6.2”.
SSG’s platform check doesn’t work on Red Hat either; using scap-security-guid/RHEL/6/dist/content: # cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.5 (Santiago) # oscap oval eval ssg-rhel6-cpe-oval.xml Definition oval:ssg:def:100: false Evaluation done.
And it will work if I edit the “pattern match” as on CentOS.
I think the platform CPE get defined through OpenSCAP’s CPE OVAL, not SSG’s. Just try move /usr/share/openscap/cpe/openscap-cpe-dict.xml to something else and try to run a xccdf eval.
Or am I messing things up?
Best regards
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Trey Henefield Sent: quarta-feira, 18 de Junho de 2014 15:04 To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
Ah, this is because you are using the prebuilt release package which has slightly different checks than what is on the trunk.
Try the attached file in place of you existing one.
The prebuilt package looks for redhat-release-workstation and redhat-release-server packages.
CentOS does not offer these similar packages. So instead I modified both of those to indicate centos-release, which is a valid package. Versioning should match up as is.
That is all that is needed.
I would not go any further as to create new checks inside the prebuilt package as this may mess up the numbering schema for all the checks created when the SSG package is built.
However, a check could easily be added in the source location I previously mentioned to also accept CentOS 6 as a valid target. Or a new CentOS6 check could be added as described and referenced in the CPE dictionary:
scap-security-guide\RHEL\6\input\checks\platform\rhel6-cpe-dictionary.xml
Best regards,
Trey Henefield, CISSP Senior IAVA Engineer
Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA
Trey.Henefield@ultra-ats.commailto:Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.comhttp://www.ultra-ats.com
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Rui Pedro Bernardino Sent: Wednesday, June 18, 2014 7:21 AM To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
It requires an extra hack because ‘version’ on CentOS won’t match the specified pattern; here is how I did it to keep it compatible with RHEL: 1. Add an extra criterion: <criteria operator="OR"> <criterion comment="Red Hat Enterprise Linux 6 Workstation is installed" test_ref="test_rhel_workstation" /> <criterion comment="Red Hat Enterprise Linux 6 Server is installed" test_ref="test_rhel_server" /> <criterion comment="CentOS 6 is installed" test_ref="test_centos" /> </criteria> 2. Add an extra test: <linux:rpminfo_test check="all" check_existence="at_least_one_exists" comment="centos-release is version 6" id="test_centos" version="1"> <linux:object object_ref="obj_centos" /> <linux:state state_ref="state_centos" /> </linux:rpminfo_test> <linux:rpminfo_state id="state_centos" version="1"> <linux:version operation="pattern match">^6</linux:version> </linux:rpminfo_state> <linux:rpminfo_object id="obj_centos" version="1"> linux:namecentos-release</linux:name> </linux:rpminfo_object>
Another weirder issue on the original SSG check: I don’t think this check works on ‘pure’ RHEL6 either but the platform still matches for some reason I do not understand.
When I use ‘—oval-results’, the CPE result file (ssg-rhel6-cpe-oval.xml.result.xml), the test_rhel_* tests all fail for the same reason, i.e: lin-sys:version6Server</lin-sys:version> Won’t match: <lin-def:version operation="pattern match">^6.\d+$</lin-def:version>
Thus resulting in ‘false’ for test_rhel_server: <test test_id="oval:ssg:tst:103" version="1" check="all" result="false"> <tested_item item_id="1046111" result="false"/> </test>
and consequently for installed_OS_is_rhel6: <definition definition_id="oval:ssg:def:100" result="false" version="1">
But the definition still works ok, although it doesn’t on CentOS… What am I getting wrong were?
Thanks!
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Trey Henefield Sent: quarta-feira, 18 de Junho de 2014 12:31 To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
The check for Red Hat 6 is pulled from:
scap-security-guide\RHEL\6\input\checks\installed_OS_is_rhel6.xml
Simply change the two references to 'redhat-release' to state 'centos-release' instead. Then rebuild.
That should do it.
Best regards,
Trey Henefield, CISSP Senior IAVA Engineer
Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA
Trey.Henefield@ultra-ats.commailto:Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.comhttp://www.ultra-ats.com
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Pettorino, Jeffrey D CTR USAF USAFA USAFA/DFAN Sent: Tuesday, June 17, 2014 4:01 PM To: 'scap-security-guide@lists.fedorahosted.org' Subject: Anyone using rhel6 ssg for centos6?
I have been trying to get oscap working on my CentOS6.5 network core, without luck.
Everything comes back with "Result notapplicable".
I am pretty new to SCAP and XCCDF, but am a long-time user of Nessus and Security Center (prior to ACAS program by DISA).
Does anyone have suggestions where I can find some in depth guidance to adjust the rhel6 configs to CentOS?
-- Jeff
v/r, Jeffrey D. Pettorino, GCIH, CISSP Systems Engineer High Performance Computing Research Center United States Air Force Academy Jeffrey.Pettorino.ctr@USAFA.edumailto:Jeffrey.Pettorino.ctr@USAFA.edu 719/333-9391 ---- The use of the Unix philosophy just for UNIX was a great waste. Fortunately, Linux came along. - Bellevue Linux User Group member, 2005
Disclaimer The information contained in this communication from trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com sent at 2014-06-18 07:30:57 is private and may be legally privileged or export controlled. It is intended solely for use by scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.
You are correct sir. It does support Res, but apparently it is picky when evaluating them in the way it was defined.
Here is one more change that I have verified does ensure it gets detected on RHEL 6. CentOS 6 support should still be intact.
Best regards,
Trey Henefield, CISSP Senior IAVA Engineer
Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA
Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.com
From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Rui Pedro Bernardino Sent: Wednesday, June 18, 2014 10:33 AM To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
My point with your initial CentOS suggestion is that it should work, but it doesn’t because SSG RHEL’s CPEs are broken.
This version works perfectly on CentOS but gets an error on RHEL: <system_data> <lin-sys:rpminfo_item id="1069901" status="error"> lin-sys:nameredhat-release-(?:workstation|server)</lin-sys:name> </lin-sys:rpminfo_item> </system_data>
Can you use REs in the rpminfo object name?
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Trey Henefield Sent: quarta-feira, 18 de Junho de 2014 15:59 To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
Yes, I don’t have CentOS 6 installed so I couldn’t verify, but from looking at the package on their site, it appeared as if the version indicated would work.
I am not sure about how the openscap software itself resolves CPE entries, or if it does at all. But from creating other SSGs, it has been my experience that you could pretty much define any CPE name. The key is in the cpe-oval check it is attached to by the cpe-dictionary.
The previous change I did will remove support for Red Hat.
Here is an updated file that should allow being used for both Red Hat 6 and CentOS 6.
Best regards,
Trey Henefield, CISSP Senior IAVA Engineer
Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA
Trey.Henefield@ultra-ats.commailto:Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.comhttp://www.ultra-ats.com
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Rui Pedro Bernardino Sent: Wednesday, June 18, 2014 9:39 AM To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
I’m also building from the GIT version.
Anyway, using your file: # cat /etc/redhat-release CentOS release 6.2 (Final) # oscap oval eval --results ssg-rhel6-cpe-oval.results.xml ssg-rhel6-cpe-oval.xml Definition oval:ssg:def:100: false Evaluation done.
When I edit the file and replace <linux:version operation="pattern match">^6.\d+$</linux:version> by <linux:version operation="pattern match">^6</linux:version>
And re-run: # oscap oval eval --results ssg-rhel6-cpe-oval.results.xml ssg-rhel6-cpe-oval.xml Definition oval:ssg:def:100: true Evaluation done.
Also have a look at the end of “ssg-rhel6-cpe-oval.results.xml”. “lin-sys:version” is “6” not “6.2”.
SSG’s platform check doesn’t work on Red Hat either; using scap-security-guid/RHEL/6/dist/content: # cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.5 (Santiago) # oscap oval eval ssg-rhel6-cpe-oval.xml Definition oval:ssg:def:100: false Evaluation done.
And it will work if I edit the “pattern match” as on CentOS.
I think the platform CPE get defined through OpenSCAP’s CPE OVAL, not SSG’s. Just try move /usr/share/openscap/cpe/openscap-cpe-dict.xml to something else and try to run a xccdf eval.
Or am I messing things up?
Best regards
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Trey Henefield Sent: quarta-feira, 18 de Junho de 2014 15:04 To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
Ah, this is because you are using the prebuilt release package which has slightly different checks than what is on the trunk.
Try the attached file in place of you existing one.
The prebuilt package looks for redhat-release-workstation and redhat-release-server packages.
CentOS does not offer these similar packages. So instead I modified both of those to indicate centos-release, which is a valid package. Versioning should match up as is.
That is all that is needed.
I would not go any further as to create new checks inside the prebuilt package as this may mess up the numbering schema for all the checks created when the SSG package is built.
However, a check could easily be added in the source location I previously mentioned to also accept CentOS 6 as a valid target. Or a new CentOS6 check could be added as described and referenced in the CPE dictionary:
scap-security-guide\RHEL\6\input\checks\platform\rhel6-cpe-dictionary.xml
Best regards,
Trey Henefield, CISSP Senior IAVA Engineer
Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA
Trey.Henefield@ultra-ats.commailto:Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.comhttp://www.ultra-ats.com
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Rui Pedro Bernardino Sent: Wednesday, June 18, 2014 7:21 AM To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
It requires an extra hack because ‘version’ on CentOS won’t match the specified pattern; here is how I did it to keep it compatible with RHEL: 1. Add an extra criterion: <criteria operator="OR"> <criterion comment="Red Hat Enterprise Linux 6 Workstation is installed" test_ref="test_rhel_workstation" /> <criterion comment="Red Hat Enterprise Linux 6 Server is installed" test_ref="test_rhel_server" /> <criterion comment="CentOS 6 is installed" test_ref="test_centos" /> </criteria> 2. Add an extra test: <linux:rpminfo_test check="all" check_existence="at_least_one_exists" comment="centos-release is version 6" id="test_centos" version="1"> <linux:object object_ref="obj_centos" /> <linux:state state_ref="state_centos" /> </linux:rpminfo_test> <linux:rpminfo_state id="state_centos" version="1"> <linux:version operation="pattern match">^6</linux:version> </linux:rpminfo_state> <linux:rpminfo_object id="obj_centos" version="1"> linux:namecentos-release</linux:name> </linux:rpminfo_object>
Another weirder issue on the original SSG check: I don’t think this check works on ‘pure’ RHEL6 either but the platform still matches for some reason I do not understand.
When I use ‘—oval-results’, the CPE result file (ssg-rhel6-cpe-oval.xml.result.xml), the test_rhel_* tests all fail for the same reason, i.e: lin-sys:version6Server</lin-sys:version> Won’t match: <lin-def:version operation="pattern match">^6.\d+$</lin-def:version>
Thus resulting in ‘false’ for test_rhel_server: <test test_id="oval:ssg:tst:103" version="1" check="all" result="false"> <tested_item item_id="1046111" result="false"/> </test>
and consequently for installed_OS_is_rhel6: <definition definition_id="oval:ssg:def:100" result="false" version="1">
But the definition still works ok, although it doesn’t on CentOS… What am I getting wrong were?
Thanks!
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Trey Henefield Sent: quarta-feira, 18 de Junho de 2014 12:31 To: SCAP Security Guide Subject: RE: Anyone using rhel6 ssg for centos6?
The check for Red Hat 6 is pulled from:
scap-security-guide\RHEL\6\input\checks\installed_OS_is_rhel6.xml
Simply change the two references to 'redhat-release' to state 'centos-release' instead. Then rebuild.
That should do it.
Best regards,
Trey Henefield, CISSP Senior IAVA Engineer
Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA
Trey.Henefield@ultra-ats.commailto:Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.comhttp://www.ultra-ats.com
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Pettorino, Jeffrey D CTR USAF USAFA USAFA/DFAN Sent: Tuesday, June 17, 2014 4:01 PM To: 'scap-security-guide@lists.fedorahosted.org' Subject: Anyone using rhel6 ssg for centos6?
I have been trying to get oscap working on my CentOS6.5 network core, without luck.
Everything comes back with "Result notapplicable".
I am pretty new to SCAP and XCCDF, but am a long-time user of Nessus and Security Center (prior to ACAS program by DISA).
Does anyone have suggestions where I can find some in depth guidance to adjust the rhel6 configs to CentOS?
-- Jeff
v/r, Jeffrey D. Pettorino, GCIH, CISSP Systems Engineer High Performance Computing Research Center United States Air Force Academy Jeffrey.Pettorino.ctr@USAFA.edumailto:Jeffrey.Pettorino.ctr@USAFA.edu 719/333-9391 ---- The use of the Unix philosophy just for UNIX was a great waste. Fortunately, Linux came along. - Bellevue Linux User Group member, 2005
Disclaimer The information contained in this communication from trey.henefield@ultra-ats.commailto:trey.henefield@ultra-ats.com sent at 2014-06-18 07:30:57 is private and may be legally privileged or export controlled. It is intended solely for use by scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.
Thanks you everyone!
I was previously receiving the list in digest form (good for lurking, bad for interaction). I checked the archives and saw some similar queries and discussions just a few days before I joined, last month...
I appreciate the prompt replies and guidance. I will share anything significant I come up with.
As for a few things I saw in previous threads: We use CentOS at the US Air Force Academy specifically on the ResearchNet, the HPC network for the Aeronautics Department, supporting real world (wind tunnel and fluid tunnel) and computer based modeling and simulation, and for connecting out to the bigger HPC.MIL labs and networks. Physics (Meteorology) and Astrophysics also use our systems and network and systems.
The justification for CentOS over RHEL is simply funding. We have firm *NIX requirements and no budget for licensing. We used to have a variety of UNIX flavors and variants, but we are going through accreditation for ATO so "approved software only" is the driver. CentOS, with its upstream provider of RHEL, is more likely to get a waiver approval than any of the non-NIAP/CC/approved operating systems.
Cheers! -- Jeff
v/r, Jeffrey D. Pettorino, GCIH, CISSP Systems Engineer High Performance Computing Research Center United States Air Force Academy Jeffrey.Pettorino.ctr@USAFA.edu 719/333-9391 ---- The use of the Unix philosophy just for UNIX was a great waste. Fortunately, Linux came along. - Bellevue Linux User Group member, 2005
scap-security-guide@lists.fedorahosted.org