On Thu, Nov 16, 2017 at 10:21 AM, Olivier BONHOMME <[email protected]> wrote:
> On Thu, Nov 16, 2017 at 09:59:02AM -0700, Gabe Alford wrote: > Hello Gabe, > > > 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 > > compliance > > equirements nor do Red Hat certificationstransfer or follow down to the > > derivatives. The > > CentOS project also echos this statement at > > https://wiki.centos.org/FAQ/General#head-4b2dd1ea6dcc1243d6e > 3886dc3e5d1ebb252c194 > > 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 > > profile > > is almost an exact copy of the RHEL profile just with some changes to > work > > on CentOS. > > I understand your point and the fact that CentOS profile is a copy of the > RHEL > profile but with a different CPE. But actually, for now I'm not looking > for a > certification and I'm fully aware that CentOS goal is not to provide > certified > things. > > In my mind actually, it sounds more like applying the RHEL profile on a > CentOS > just for having a status against STIG but not a certification at all. It's > just > in order to have a general idea of how my CentOS is secured (or not) > against a > known guide. > 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 ssg-rhel7-xccdf.xml then that same rule will get added to ssg-centos7-xccdf.xml when the content is built. > I know for example that FIPS rule will always fail and I'm okay with that > but > 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 > way on > CentOS or RHEL. > > That's why my action plan was, how is the CentOS guide against STIG in > order to > 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 > have a > dedicated SSG profile for CentOS which is standalone and not a derivative > from > the RHEL one. > That is correct. Same thing with ScientificLinux. > > > > > Also, some RHEL checks/rules in the STIG are duplicates of others, or > they > > 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 > RHEL > > 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 > coverage > against RHEL STIG V1.2 ? > > Regards, > Olivier Bonhomme > > > _______________________________________________ > > scap-security-guide mailing list -- [email protected] > rahosted.org > > To unsubscribe send an email to scap-security-guide-leave@list > s.fedorahosted.org > _______________________________________________ > scap-security-guide mailing list -- [email protected] > rahosted.org > To unsubscribe send an email to scap-security-guide-leave@list > s.fedorahosted.org >
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected]
