On Thu, Nov 16, 2017 at 10:21 AM, Olivier BONHOMME <obonhomme(a)nerim.net>
On Thu, Nov 16, 2017 at 09:59:02AM -0700, Gabe Alford wrote:
> This is expected behaviour. A separate CentOS STIG has to be created and
> exist for a
> stig_overlay.xml to be created and exist.CentOS *does not* meet STIG
> equirements nor do Red Hat certificationstransfer or follow down to the
> derivatives. The
> CentOS project also echos this statement at
> For this reason, all RHEL identifiers have been stripped out of the
> derivative profiles.
> You should not have to check coverage of the CentOS profile as the CentOS
> is almost an exact copy of the RHEL profile just with some changes to
> on CentOS.
I understand your point and the fact that CentOS profile is a copy of the
profile but with a different CPE. But actually, for now I'm not looking
certification and I'm fully aware that CentOS goal is not to provide
In my mind actually, it sounds more like applying the RHEL profile on a
just for having a status against STIG but not a certification at all. It's
in order to have a general idea of how my CentOS is secured (or not)
You shouldn't have to apply the RHEL content to a CentOS machine at all.
The profiles in ssg-centos7-xccdf.xml are the exact same as what is in
ssg-rhel7-xccdf.xml. So, a new rule gets added to the STIG profile in
then that same rule will get added to ssg-centos7-xccdf.xml when the
I know for example that FIPS rule will always fail and I'm okay
for most of others rules, I expect the same behaviour between an RHEL and a
CentOS. For example, rules about paritionning are applicable in the same
CentOS or RHEL.
That's why my action plan was, how is the CentOS guide against STIG in
see if I have rules to write by myself in order to have a relevant OpenSCAP
profile (and of course contribute to the SSG project :)).
Correct me if i'm wrong but i don't think it's in the project roadmap to
dedicated SSG profile for CentOS which is standalone and not a derivative
the RHEL one.
That is correct. Same thing with ScientificLinux.
> Also, some RHEL checks/rules in the STIG are duplicates of others, or
> are no longer valid for
> the latest release. Any of duplicated/outdated checks/rules have been
> remove/updated (as much
> as feasibly possible) for the latest release. So if there are missing
> identifiers, it is usually
> because of duplication or new content that has yet to be added.
Does that mean that actually, the SSG team considers there is a full
against RHEL STIG V1.2 ?
> scap-security-guide mailing list -- scap-security-guide(a)lists.fedo
> To unsubscribe send an email to scap-security-guide-leave@list
scap-security-guide mailing list -- scap-security-guide(a)lists.fedo
To unsubscribe send an email to scap-security-guide-leave@list