Hello,
Security Content for el7 and el8 systems are not the same, for example, there is support for crypto-policies in el8, and method to enable FIPS mode is different for each.
And currently "rhv4 https://github.com/ComplianceAsCode/content/tree/master/rhv4" product is focused on el7, and it is expected to be supported for quite some time. Question: How can we better support el8 based hosts?
One way is to "split" rhv4 product into two, creating one product for el7 based hosts and another for el8 based hosts. At the moment, the contents for RHV and RHEL are very similar, but as content for RHV improves there may be the need for RHV specific content. This approach would allow freedom for RHV content to grow and become specific as needed, while sharing content with their respective base enterprise linuxes.
Thoughts?
On 12/16/19 9:53 AM, Watson Sato wrote:
Hello,
Security Content for el7 and el8 systems are not the same, for example, there is support for crypto-policies in el8, and method to enable FIPS mode is different for each.
And currently "rhv4 https://github.com/ComplianceAsCode/content/tree/master/rhv4" product is focused on el7, and it is expected to be supported for quite some time. Question: How can we better support el8 based hosts?
One way is to "split" rhv4 product into two, creating one product for el7 based hosts and another for el8 based hosts. At the moment, the contents for RHV and RHEL are very similar, but as content for RHV improves there may be the need for RHV specific content. This approach would allow freedom for RHV content to grow and become specific as needed, while sharing content with their respective base enterprise linuxes.
Thoughts?
Thanks for starting this conversation.
Why not draw a line in the sand and say the content is for a specific version of RHV and newer? For example RHV 4.3+.
Alternatively, many the rules are operating system aware. If a RHEL7-focused check is enabled in the RHV profile, and the underlying host is RHEL 8-based, will the evaluation results showup as "notapplicable" with proper CPE usage?
On Wed, Dec 18, 2019 at 4:40 AM Shawn Wells shawn@redhat.com wrote:
On 12/16/19 9:53 AM, Watson Sato wrote:
Hello,
Security Content for el7 and el8 systems are not the same, for example, there is support for crypto-policies in el8, and method to enable FIPS mode is different for each.
And currently "rhv4 https://github.com/ComplianceAsCode/content/tree/master/rhv4" product is focused on el7, and it is expected to be supported for quite some time. Question: How can we better support el8 based hosts?
One way is to "split" rhv4 product into two, creating one product for el7 based hosts and another for el8 based hosts. At the moment, the contents for RHV and RHEL are very similar, but as content for RHV improves there may be the need for RHV specific content. This approach would allow freedom for RHV content to grow and become specific as needed, while sharing content with their respective base enterprise linuxes.
Thoughts?
Thanks for starting this conversation.
Why not draw a line in the sand and say the content is for a specific version of RHV and newer? For example RHV 4.3+.
Actually, that is an interesting idea. As far as I know versions up to RHV-4.3 have been using content from ssg-rhel7-ds.xml, as it contains RHV related profiles. A specific RHV4 "product" for el7 may not be needed at all.
Alternatively, many the rules are operating system aware. If a RHEL7-focused check is enabled in the RHV profile, and the underlying host is RHEL 8-based, will the evaluation results showup as "notapplicable" with proper CPE usage?
Well, yes. But we don't label the rules with CPE for product specific versions. There is 'prodtype' used to label the rules, but it is used to decide whether to include the rule in the DS. It is not used in any way for Rule applicability with CPE.
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
...
Alternatively, many the rules are operating system aware. If a RHEL7-focused check is enabled in the RHV profile, and the underlying host is RHEL 8-based, will the evaluation results showup as "notapplicable" with proper CPE usage?
Well, yes. But we don't label the rules with CPE for product specific versions. There is 'prodtype' used to label the rules, but it is used to decide whether to include the rule in the DS. It is not used in any way for Rule applicability with CPE.
I would just add that proper support of CPE Applicability Language within the project's build system is required to handle this in a scalable manner. At this moment, a large amount of rules in the project uses various workarounds to achieve this behavior. Implementation of CPE AL is a necessary condition for the project's growth, and it is a feature with one of the highest priorities in our tech debt reduction wishlist, and we see this as a confirmation of our earlier conclusions.
Considering the amount of content that needs to be updated for new releases of STIG and replacement of authconfig, updates to pam checks, etc. I would consider this a very low priority at this time.
On Wed, Dec 18, 2019 at 9:18 AM Matěj Týč matyc@redhat.com wrote:
...
Alternatively, many the rules are operating system aware. If a
RHEL7-focused check is enabled in the RHV profile, and the underlying host is RHEL 8-based, will the evaluation results showup as "notapplicable" with proper CPE usage?
Well, yes. But we don't label the rules with CPE for product specific versions. There is 'prodtype' used to label the rules, but it is used to decide whether to include the rule in the DS. It is not used in any way for Rule applicability with CPE.
I would just add that proper support of CPE Applicability Language within the project's build system is required to handle this in a scalable manner. At this moment, a large amount of rules in the project uses various workarounds to achieve this behavior. Implementation of CPE AL is a necessary condition for the project's growth, and it is a feature with one of the highest priorities in our tech debt reduction wishlist, and we see this as a confirmation of our earlier conclusions. _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
Hello all!
On Wed, Dec 18, 2019 at 1:40 PM Watson Sato wsato@redhat.com wrote:
On Wed, Dec 18, 2019 at 4:40 AM Shawn Wells shawn@redhat.com wrote:
Thanks for starting this conversation.
Why not draw a line in the sand and say the content is for a specific version of RHV and newer? For example RHV 4.3+.
Actually, that is an interesting idea. As far as I know versions up to RHV-4.3 have been using content from ssg-rhel7-ds.xml, as it contains RHV related profiles. A specific RHV4 "product" for el7 may not be needed at all.
Following up on this, I have started a PR moving RHV to be el8 based: https://github.com/ComplianceAsCode/content/pull/5352
Part of the PR consists of making applicable the relevant rules, and making not-applicable unnecessary rules, and also updating the profile's rule selection based on their applicability. During this process I noticed that RHV4 "rhvh-stig" profile was identical to RHEL7 "rhelh-stig" profile, and RHV4 "rhvh-vpp" is identical to RHEL7 "rhelh-vpp". So I wondered whether Profiles for RHV4 on el8 should also be aligned with RHEL8 "rhelh-stig"and "rhelh-vpp".
To me it makes sense, and I did so in the PR. But I'd like to hear your thoughts on this matter.
scap-security-guide@lists.fedorahosted.org