I just noticed that all the EL derivatives in the current SSG no longer get any of the government security profiles, only pci-dss and standard. What happend to all of te other profiles available for RHEL7?
- Chuck
On 12/28/18 11:06 AM, Chuck Atkins wrote:
I just noticed that all the EL derivatives in the current SSG no longer get any of the government security profiles, only pci-dss and standard. What happend to all of te other profiles available for RHEL7?
The ones for RHEL are still there, as are Ubuntu and OEL :)
Derivatives (e.g. CentOS) don't have STIGs or other formal US Gov config baselines. Shipping baselines with formal names (e.g. STIG or NIST National Checklist) for the derivatives was slightly misleading, and some users thought derivatives held formal approvals (e.g. a CentOS STIG published by DISA).
Other baselines, such as PCI-DSS, are generic and don't represent a formal/"regulatory managed" baseline akin to DoD STIGs.
That said, baselines for derivatives are still needed by some in the community. Could be an opportunity for someone to create a "FISMA" or "NIST 800-53" style baseline since those are open standards.
Could there be an opt-in compile option?
Something like --yes-i-know-this-isnt-official-but-im-using-this-for-testing-centos-plz
Right now, I use these as a quick test to make sure that nothing silly broke using free resources with CentOS VMs. I certainly understand that this does not guarantee RHEL compatibility, etc... but it does let me know if something insane happened and I can then go see if it's a CentOS mess up or something that broken in either the SSG or RHEL.
Trevor
On Fri, Dec 28, 2018 at 2:22 PM Shawn Wells shawn@redhat.com wrote:
On 12/28/18 11:06 AM, Chuck Atkins wrote:
I just noticed that all the EL derivatives in the current SSG no longer get any of the government security profiles, only pci-dss and standard. What happend to all of te other profiles available for RHEL7?
The ones for RHEL are still there, as are Ubuntu and OEL :)
Derivatives (e.g. CentOS) don't have STIGs or other formal US Gov config baselines. Shipping baselines with formal names (e.g. STIG or NIST National Checklist) for the derivatives was slightly misleading, and some users thought derivatives held formal approvals (e.g. a CentOS STIG published by DISA).
Other baselines, such as PCI-DSS, are generic and don't represent a formal/"regulatory managed" baseline akin to DoD STIGs.
That said, baselines for derivatives are still needed by some in the community. Could be an opportunity for someone to create a "FISMA" or "NIST 800-53" style baseline since those are open standards.
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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
On Fri, Dec 28, 2018, at 2:31 PM, Trevor Vaughan wrote:
Could there be an opt-in compile option?
Something like --yes-i-know-this-isnt-official-but-im-using-this-for-testing-centos-plz
Right now, I use these as a quick test to make sure that nothing silly broke using free resources with CentOS VMs. I certainly understand that this does not guarantee RHEL compatibility, etc... but it does let me know if something insane happened and I can then go see if it's a CentOS mess up or something that broken in either the SSG or RHEL.
+1, I've needed this, too.
Trevor
On Fri, Dec 28, 2018 at 2:22 PM Shawn Wells shawn@redhat.com wrote:
On 12/28/18 11:06 AM, Chuck Atkins wrote:
I just noticed that all the EL derivatives in the current SSG no longer get any of the government security profiles, only pci-dss and standard. What happend to all of te other profiles available for RHEL7?
The ones for RHEL are still there, as are Ubuntu and OEL :)
Derivatives (e.g. CentOS) don't have STIGs or other formal US Gov config baselines. Shipping baselines with formal names (e.g. STIG or NIST National Checklist) for the derivatives was slightly misleading, and some users thought derivatives held formal approvals (e.g. a CentOS STIG published by DISA).
Other baselines, such as PCI-DSS, are generic and don't represent a formal/"regulatory managed" baseline akin to DoD STIGs.
That said, baselines for derivatives are still needed by some in the community. Could be an opportunity for someone to create a "FISMA" or "NIST 800-53" style baseline since those are open standards.
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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information -- _______________________________________________ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
Ugh..yeah, all of my compliance CI tests just broke!
Well, I'll give this a bit and if it doesn't pan out resurrect my RHEL => CentOS conversion script.
Alternatively, RHEL could post a Vagrant image with an active trial license already hooked up to valid repos....alas, the holidays have already passed. It is currently, non trivial to get working in a CI environment.
Trevor
On Fri, Dec 28, 2018 at 3:01 PM James Cassell fedoraproject@cyberpear.com wrote:
On Fri, Dec 28, 2018, at 2:31 PM, Trevor Vaughan wrote:
Could there be an opt-in compile option?
Something like --yes-i-know-this-isnt-official-but-im-using-this-for-testing-centos-plz
Right now, I use these as a quick test to make sure that nothing silly broke using free resources with CentOS VMs. I certainly understand that this does not guarantee RHEL compatibility, etc... but it does let me
know
if something insane happened and I can then go see if it's a CentOS mess
up
or something that broken in either the SSG or RHEL.
+1, I've needed this, too.
Trevor
On Fri, Dec 28, 2018 at 2:22 PM Shawn Wells shawn@redhat.com wrote:
On 12/28/18 11:06 AM, Chuck Atkins wrote:
I just noticed that all the EL derivatives in the current SSG no longer get any of the government security profiles, only pci-dss and standard. What happend to all of te other profiles available for
RHEL7?
The ones for RHEL are still there, as are Ubuntu and OEL :)
Derivatives (e.g. CentOS) don't have STIGs or other formal US Gov
config
baselines. Shipping baselines with formal names (e.g. STIG or NIST National Checklist) for the derivatives was slightly misleading, and some users thought derivatives held formal approvals (e.g. a CentOS
STIG
published by DISA).
Other baselines, such as PCI-DSS, are generic and don't represent a formal/"regulatory managed" baseline akin to DoD STIGs.
That said, baselines for derivatives are still needed by some in the community. Could be an opportunity for someone to create a "FISMA" or "NIST 800-53" style baseline since those are open standards.
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://getfedora.org/code-of-conduct.html List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information -- _______________________________________________ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor... _______________________________________________ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
On 12/28/18 3:07 PM, Trevor Vaughan wrote:
Ugh..yeah, all of my compliance CI tests just broke!
Well, I'll give this a bit and if it doesn't pan out resurrect my RHEL => CentOS conversion script.
Alternatively, RHEL could post a Vagrant image with an active trial license already hooked up to valid repos....alas, the holidays have already passed. It is currently, non trivial to get working in a CI environment.
Why use CentOS when RHEL developer subs are free?
https://developers.redhat.com/products/rhel/download/
https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-subscri...
Because it's a flaming pain in the rear to get working in a publicly accessible CI system without exposing secrets or cloning the entire RHEL infrastructure.
On Fri, Dec 28, 2018 at 3:16 PM Shawn Wells shawn@redhat.com wrote:
On 12/28/18 3:07 PM, Trevor Vaughan wrote:
Ugh..yeah, all of my compliance CI tests just broke!
Well, I'll give this a bit and if it doesn't pan out resurrect my RHEL => CentOS conversion script.
Alternatively, RHEL could post a Vagrant image with an active trial license already hooked up to valid repos....alas, the holidays have already passed. It is currently, non trivial to get working in a CI environment.
Why use CentOS when RHEL developer subs are free?
https://developers.redhat.com/products/rhel/download/
https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-subscri... _______________________________________________ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
Basically, looking at https://gitlab.com/simp/pupmod-simp-auditd/pipelines/39410693, that last bubble on the right is a publicly donated runner for my lovely FOSS project.
I haven't a clue how to make that work with a RHEL subscription without embedding my credentials into someone else's computer ( I love the cloud and all but no thanks ).
Trevor
On Fri, Dec 28, 2018 at 5:12 PM Trevor Vaughan tvaughan@onyxpoint.com wrote:
Because it's a flaming pain in the rear to get working in a publicly accessible CI system without exposing secrets or cloning the entire RHEL infrastructure.
On Fri, Dec 28, 2018 at 3:16 PM Shawn Wells shawn@redhat.com wrote:
On 12/28/18 3:07 PM, Trevor Vaughan wrote:
Ugh..yeah, all of my compliance CI tests just broke!
Well, I'll give this a bit and if it doesn't pan out resurrect my RHEL => CentOS conversion script.
Alternatively, RHEL could post a Vagrant image with an active trial license already hooked up to valid repos....alas, the holidays have already passed. It is currently, non trivial to get working in a CI environment.
Why use CentOS when RHEL developer subs are free?
https://developers.redhat.com/products/rhel/download/
https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-subscri... _______________________________________________ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
Sorry to be bombing the list, but I keep thinking of additional things.
So, CentOS has https://app.vagrantup.com/centos/boxes/7 which they keep up to date and which makes it easy for me to 'vagrant up' my way into testing.
RHEL has a hodgepodge of options: https://app.vagrantup.com/boxes/search?utf8=%E2%9C%93&sort=downloads&... but nothing actually viable and which would require a subscription registration to be able to download packages and actually enable testing. (Honestly, a three hour subscription would be just fine for every case that I can think of).
OEL also has a hodgepodge of options but, once you download it, you can just connect to their repos and get on with life for CI testing (this isn't ideal since you don't really know what has changed but again, it's probably "close enough" to make sure something works).
Trevor
On Fri, Dec 28, 2018 at 5:14 PM Trevor Vaughan tvaughan@onyxpoint.com wrote:
Basically, looking at https://gitlab.com/simp/pupmod-simp-auditd/pipelines/39410693, that last bubble on the right is a publicly donated runner for my lovely FOSS project.
I haven't a clue how to make that work with a RHEL subscription without embedding my credentials into someone else's computer ( I love the cloud and all but no thanks ).
Trevor
On Fri, Dec 28, 2018 at 5:12 PM Trevor Vaughan tvaughan@onyxpoint.com wrote:
Because it's a flaming pain in the rear to get working in a publicly accessible CI system without exposing secrets or cloning the entire RHEL infrastructure.
On Fri, Dec 28, 2018 at 3:16 PM Shawn Wells shawn@redhat.com wrote:
On 12/28/18 3:07 PM, Trevor Vaughan wrote:
Ugh..yeah, all of my compliance CI tests just broke!
Well, I'll give this a bit and if it doesn't pan out resurrect my RHEL => CentOS conversion script.
Alternatively, RHEL could post a Vagrant image with an active trial license already hooked up to valid repos....alas, the holidays have already passed. It is currently, non trivial to get working in a CI environment.
Why use CentOS when RHEL developer subs are free?
https://developers.redhat.com/products/rhel/download/
https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-subscri... _______________________________________________ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
Trevor, Last I checked, the "subscription" is really just an x.509 client certificate that allows the target to "log in" to the web server. Once the HTTPS session is open, the honor system is about the only thing to keep you from pulling everything down with reposync. You might be able to hijack that mechanism and insert a legitimate certificate onto the runner without exposing the credentials to get the certificate.
Charlie Todd Ball Aerosoace
On Dec 28, 2018, at 5:35 PM, Trevor Vaughan <tvaughan@onyxpoint.commailto:tvaughan@onyxpoint.com> wrote:
Sorry to be bombing the list, but I keep thinking of additional things.
So, CentOS has https://app.vagrantup.com/centos/boxes/7https://urldefense.proofpoint.com/v2/url?u=https-3A__app.vagrantup.com_centos_boxes_7&d=DwMFaQ&c=jF7FvYH6t0RX1HrEjVCgHQ&r=EtM8rzsgMR2aFrLOrhF8eg&m=ozoMpdaapmJ96Jkgw9k-xxUyNsu2I7NiKXQMpv-aIqg&s=xmhqUV_A80BzdSRcRpEaWLZgEIQCUHiMYSpV2cdkKwE&e= which they keep up to date and which makes it easy for me to 'vagrant up' my way into testing.
RHEL has a hodgepodge of options: https://app.vagrantup.com/boxes/search?utf8=%E2%9C%93&sort=downloads&...https://urldefense.proofpoint.com/v2/url?u=https-3A__app.vagrantup.com_boxes_search-3Futf8-3D-25E2-259C-2593-26sort-3Ddownloads-26provider-3D-26q-3Drhel&d=DwMFaQ&c=jF7FvYH6t0RX1HrEjVCgHQ&r=EtM8rzsgMR2aFrLOrhF8eg&m=ozoMpdaapmJ96Jkgw9k-xxUyNsu2I7NiKXQMpv-aIqg&s=mAkhmFovZEbDJliamVk__NZ1t2NaozKg5fvFABzsnmQ&e= but nothing actually viable and which would require a subscription registration to be able to download packages and actually enable testing. (Honestly, a three hour subscription would be just fine for every case that I can think of).
OEL also has a hodgepodge of options but, once you download it, you can just connect to their repos and get on with life for CI testing (this isn't ideal since you don't really know what has changed but again, it's probably "close enough" to make sure something works).
Trevor
On Fri, Dec 28, 2018 at 5:14 PM Trevor Vaughan <tvaughan@onyxpoint.commailto:tvaughan@onyxpoint.com> wrote: Basically, looking at https://gitlab.com/simp/pupmod-simp-auditd/pipelines/39410693https://urldefense.proofpoint.com/v2/url?u=https-3A__gitlab.com_simp_pupmod-2Dsimp-2Dauditd_pipelines_39410693&d=DwMFaQ&c=jF7FvYH6t0RX1HrEjVCgHQ&r=EtM8rzsgMR2aFrLOrhF8eg&m=ozoMpdaapmJ96Jkgw9k-xxUyNsu2I7NiKXQMpv-aIqg&s=VUlmYqXuFL3d5dqjgbcojDdtvwlBKoDPeKnwysFhf2k&e=, that last bubble on the right is a publicly donated runner for my lovely FOSS project.
I haven't a clue how to make that work with a RHEL subscription without embedding my credentials into someone else's computer ( I love the cloud and all but no thanks ).
Trevor
On Fri, Dec 28, 2018 at 5:12 PM Trevor Vaughan <tvaughan@onyxpoint.commailto:tvaughan@onyxpoint.com> wrote: Because it's a flaming pain in the rear to get working in a publicly accessible CI system without exposing secrets or cloning the entire RHEL infrastructure.
On Fri, Dec 28, 2018 at 3:16 PM Shawn Wells <shawn@redhat.commailto:shawn@redhat.com> wrote:
On 12/28/18 3:07 PM, Trevor Vaughan wrote:
Ugh..yeah, all of my compliance CI tests just broke!
Well, I'll give this a bit and if it doesn't pan out resurrect my RHEL => CentOS conversion script.
Alternatively, RHEL could post a Vagrant image with an active trial license already hooked up to valid repos....alas, the holidays have already passed. It is currently, non trivial to get working in a CI environment.
Why use CentOS when RHEL developer subs are free?
https://developers.redhat.com/products/rhel/download/https://urldefense.proofpoint.com/v2/url?u=https-3A__developers.redhat.com_products_rhel_download_&d=DwMFaQ&c=jF7FvYH6t0RX1HrEjVCgHQ&r=EtM8rzsgMR2aFrLOrhF8eg&m=ozoMpdaapmJ96Jkgw9k-xxUyNsu2I7NiKXQMpv-aIqg&s=0HJu2gOh-dQYJE6okgEb3huObbSKXfJ0tMeAvceyVAE&e=
https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-subscri...https://urldefense.proofpoint.com/v2/url?u=https-3A__developers.redhat.com_blog_2016_03_31_no-2Dcost-2Drhel-2Ddeveloper-2Dsubscription-2Dnow-2Davailable_&d=DwMFaQ&c=jF7FvYH6t0RX1HrEjVCgHQ&r=EtM8rzsgMR2aFrLOrhF8eg&m=ozoMpdaapmJ96Jkgw9k-xxUyNsu2I7NiKXQMpv-aIqg&s=EeRtAOAHJU_8phUSMpPB2vgo-GkX9qqoYgqz0iD-Ogw&e= _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.orgmailto:scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.htmlhttps://urldefense.proofpoint.com/v2/url?u=https-3A__getfedora.org_code-2Dof-2Dconduct.html&d=DwMFaQ&c=jF7FvYH6t0RX1HrEjVCgHQ&r=EtM8rzsgMR2aFrLOrhF8eg&m=ozoMpdaapmJ96Jkgw9k-xxUyNsu2I7NiKXQMpv-aIqg&s=6NTNGQJ8u6D3b_XL9ZCa7X-YxO3_SY078OTPLo4fRNg&e= List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelineshttps://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines&d=DwMFaQ&c=jF7FvYH6t0RX1HrEjVCgHQ&r=EtM8rzsgMR2aFrLOrhF8eg&m=ozoMpdaapmJ96Jkgw9k-xxUyNsu2I7NiKXQMpv-aIqg&s=BECq1Kcki84nhd0CNMjrPGmoQyKSHD6rcjqucECnlK0&e= List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_archives_list_scap-2Dsecurity-2Dguide-40lists.fedorahosted.org&d=DwMFaQ&c=jF7FvYH6t0RX1HrEjVCgHQ&r=EtM8rzsgMR2aFrLOrhF8eg&m=ozoMpdaapmJ96Jkgw9k-xxUyNsu2I7NiKXQMpv-aIqg&s=8Vk8llN2hy7VOAHVhqMVvATB7O90HEE9nqoDUYScxNI&e=
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information -- _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.orgmailto:scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://urldefense.proofpoint.com/v2/url?u=https-3A__getfedora.org_code-2Dof... List Guidelines: https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_... List Archives: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_...
This message and any enclosures are intended only for the addressee. Please notify the sender by email if you are not the intended recipient. If you are not the intended recipient, you may not use, copy, disclose, or distribute this message or its contents or enclosures to any other person and any such actions may be unlawful. Ball reserves the right to monitor and review all messages and enclosures sent to or from this email address.
Why use CentOS when RHEL developer subs are free?
For our environment where we have a small deployment of only 2-4 machines, CentOS is much easier to manage off-line on an air-gaped network. Mirroring the CentOS repos is pretty easy to do with reposync and monthly drops to a web server on the red network. The CentOS workstations can then just point to the yum repos on said webserver and everything works like it's supposed to. Trying to do this with RHEL-proper is frustrating at best. A satellite server is way overkill for a deployment like this and setting up the clients for a "normal" yum repo requires removing and uninstalling all of the subscription / rhn packages. There's also the simplicity of only have 2 system repos to worry about to get everything available in CentOS (Base + Updates) vs dealing with the dozens of channels needed in a RHEL subscription to get the same set of available packages. I certainly get the value in all of the various options for managing large enterprise deployments but CentOS is just much simpler to deal with for us in a small deployment and software-developer-centric environment. We end up using both RHEL and CentOS for different use cases but need to apply the same security framework and settings to both.
With regards to allowed security configurations, as a contractor we've never had issues with DSS and CentOS being allowed so long as we apply all the appropriate RHEL rules and can appropriately justify where we diverge. The only ones I've run into that end up not applicable across the two have been FIPS related, which we have to disable anyways to accommodate third party unsigned kernel modules for the Nvidia driver. The STIGs after all are just a guideline and place to start from so you can adapt it to your own environment with appropriate tailoring and justification, not a fixed "it has to be this way". Most of the government entities we work with (DoD and DoE) use RHEL for their infrastructure servers and end-user workstations but CentOS for their projects and developer environments. Many of the DoE labs we work with even use CentOS on their large scale HPC deployments (LANL, Sandia, LLNL, etc.) while others use RHEL proper.
- Chuck
Hi Chuck,
So, I agree with you all the way up to FIPS. Unfortunately, the tracing that we've done on the FIPS 140-2 requirement through various ties to policy and FISMA *appears* to be unavailable except by the President of the US, by named position. Now, it's possible that this tracing is incorrect but I have yet to find anyone that could find another *documented* interpretation that overrides the Congressional mandate as handed down to NIST and inherited through the 800-53 and CNSS 1253.
That said, FIPS only applies for the "protection of sensitive information". If you don't have any sensitive information (i.e. 100% test and eval environment with independent credentials that have no access to any other system) then fire away.
Also, this mandate only applies to organizations directly under the Executive and Legislative branches of Government. The Judicial branch can do what it likes.
Sorry for the slight rant, this is one of those particular items that just drives me nuts in terms of laws (not policies) that people like to try and ignore when it gets inconvenient.
In terms of packages, I completely agree with Charlie that it's really simple to just grab all of the packages through various means so the RHN is really just making legitimate use more difficult for systems like yours and rapid CI testing systems. We specifically do not use one of the many ways of circumventing the process so that we don't run afoul of any licensing rules or restrictions.
Trevor
On Sun, Dec 30, 2018 at 12:35 PM Chuck Atkins chuck.atkins@kitware.com wrote:
Why use CentOS when RHEL developer subs are free?
For our environment where we have a small deployment of only 2-4 machines, CentOS is much easier to manage off-line on an air-gaped network. Mirroring the CentOS repos is pretty easy to do with reposync and monthly drops to a web server on the red network. The CentOS workstations can then just point to the yum repos on said webserver and everything works like it's supposed to. Trying to do this with RHEL-proper is frustrating at best. A satellite server is way overkill for a deployment like this and setting up the clients for a "normal" yum repo requires removing and uninstalling all of the subscription / rhn packages. There's also the simplicity of only have 2 system repos to worry about to get everything available in CentOS (Base + Updates) vs dealing with the dozens of channels needed in a RHEL subscription to get the same set of available packages. I certainly get the value in all of the various options for managing large enterprise deployments but CentOS is just much simpler to deal with for us in a small deployment and software-developer-centric environment. We end up using both RHEL and CentOS for different use cases but need to apply the same security framework and settings to both.
With regards to allowed security configurations, as a contractor we've never had issues with DSS and CentOS being allowed so long as we apply all the appropriate RHEL rules and can appropriately justify where we diverge. The only ones I've run into that end up not applicable across the two have been FIPS related, which we have to disable anyways to accommodate third party unsigned kernel modules for the Nvidia driver. The STIGs after all are just a guideline and place to start from so you can adapt it to your own environment with appropriate tailoring and justification, not a fixed "it has to be this way". Most of the government entities we work with (DoD and DoE) use RHEL for their infrastructure servers and end-user workstations but CentOS for their projects and developer environments. Many of the DoE labs we work with even use CentOS on their large scale HPC deployments (LANL, Sandia, LLNL, etc.) while others use RHEL proper.
- Chuck
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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
Ugh...that should have been *unwaiveable* instead of _unavailable_.
On Sun, Dec 30, 2018 at 6:04 PM Trevor Vaughan tvaughan@onyxpoint.com wrote:
Hi Chuck,
So, I agree with you all the way up to FIPS. Unfortunately, the tracing that we've done on the FIPS 140-2 requirement through various ties to policy and FISMA *appears* to be unavailable except by the President of the US, by named position. Now, it's possible that this tracing is incorrect but I have yet to find anyone that could find another *documented* interpretation that overrides the Congressional mandate as handed down to NIST and inherited through the 800-53 and CNSS 1253.
That said, FIPS only applies for the "protection of sensitive information". If you don't have any sensitive information (i.e. 100% test and eval environment with independent credentials that have no access to any other system) then fire away.
Also, this mandate only applies to organizations directly under the Executive and Legislative branches of Government. The Judicial branch can do what it likes.
Sorry for the slight rant, this is one of those particular items that just drives me nuts in terms of laws (not policies) that people like to try and ignore when it gets inconvenient.
In terms of packages, I completely agree with Charlie that it's really simple to just grab all of the packages through various means so the RHN is really just making legitimate use more difficult for systems like yours and rapid CI testing systems. We specifically do not use one of the many ways of circumventing the process so that we don't run afoul of any licensing rules or restrictions.
Trevor
On Sun, Dec 30, 2018 at 12:35 PM Chuck Atkins chuck.atkins@kitware.com wrote:
Why use CentOS when RHEL developer subs are free?
For our environment where we have a small deployment of only 2-4 machines, CentOS is much easier to manage off-line on an air-gaped network. Mirroring the CentOS repos is pretty easy to do with reposync and monthly drops to a web server on the red network. The CentOS workstations can then just point to the yum repos on said webserver and everything works like it's supposed to. Trying to do this with RHEL-proper is frustrating at best. A satellite server is way overkill for a deployment like this and setting up the clients for a "normal" yum repo requires removing and uninstalling all of the subscription / rhn packages. There's also the simplicity of only have 2 system repos to worry about to get everything available in CentOS (Base + Updates) vs dealing with the dozens of channels needed in a RHEL subscription to get the same set of available packages. I certainly get the value in all of the various options for managing large enterprise deployments but CentOS is just much simpler to deal with for us in a small deployment and software-developer-centric environment. We end up using both RHEL and CentOS for different use cases but need to apply the same security framework and settings to both.
With regards to allowed security configurations, as a contractor we've never had issues with DSS and CentOS being allowed so long as we apply all the appropriate RHEL rules and can appropriately justify where we diverge. The only ones I've run into that end up not applicable across the two have been FIPS related, which we have to disable anyways to accommodate third party unsigned kernel modules for the Nvidia driver. The STIGs after all are just a guideline and place to start from so you can adapt it to your own environment with appropriate tailoring and justification, not a fixed "it has to be this way". Most of the government entities we work with (DoD and DoE) use RHEL for their infrastructure servers and end-user workstations but CentOS for their projects and developer environments. Many of the DoE labs we work with even use CentOS on their large scale HPC deployments (LANL, Sandia, LLNL, etc.) while others use RHEL proper.
- Chuck
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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
Trevor, Tracing whether a reposync method is still license compliant, it’s still pretty easy. I have an agreement with my software manager where I take one of my licenses on RHN, or whatever we call it now, and give it the name of my system. The “host name” means nothing and can be something like “SHORTID-ACAS” or “SHORTID-CI1.” That allows you both to quickly asses whether a license is still in use during annual reviews. Red Hat is hardly in a position to complain since you bought, but don’t appear to have allocated, a license. Small numbers of systems are easy to manage like that. I’m fully compliant with licenses.
Charlie Todd
On Dec 30, 2018, at 6:05 PM, Trevor Vaughan <tvaughan@onyxpoint.commailto:tvaughan@onyxpoint.com> wrote:
Hi Chuck,
So, I agree with you all the way up to FIPS. Unfortunately, the tracing that we've done on the FIPS 140-2 requirement through various ties to policy and FISMA *appears* to be unavailable except by the President of the US, by named position. Now, it's possible that this tracing is incorrect but I have yet to find anyone that could find another *documented* interpretation that overrides the Congressional mandate as handed down to NIST and inherited through the 800-53 and CNSS 1253.
That said, FIPS only applies for the "protection of sensitive information". If you don't have any sensitive information (i.e. 100% test and eval environment with independent credentials that have no access to any other system) then fire away.
Also, this mandate only applies to organizations directly under the Executive and Legislative branches of Government. The Judicial branch can do what it likes.
Sorry for the slight rant, this is one of those particular items that just drives me nuts in terms of laws (not policies) that people like to try and ignore when it gets inconvenient.
In terms of packages, I completely agree with Charlie that it's really simple to just grab all of the packages through various means so the RHN is really just making legitimate use more difficult for systems like yours and rapid CI testing systems. We specifically do not use one of the many ways of circumventing the process so that we don't run afoul of any licensing rules or restrictions.
Trevor
On Sun, Dec 30, 2018 at 12:35 PM Chuck Atkins <chuck.atkins@kitware.commailto:chuck.atkins@kitware.com> wrote: Why use CentOS when RHEL developer subs are free?
For our environment where we have a small deployment of only 2-4 machines, CentOS is much easier to manage off-line on an air-gaped network. Mirroring the CentOS repos is pretty easy to do with reposync and monthly drops to a web server on the red network. The CentOS workstations can then just point to the yum repos on said webserver and everything works like it's supposed to. Trying to do this with RHEL-proper is frustrating at best. A satellite server is way overkill for a deployment like this and setting up the clients for a "normal" yum repo requires removing and uninstalling all of the subscription / rhn packages. There's also the simplicity of only have 2 system repos to worry about to get everything available in CentOS (Base + Updates) vs dealing with the dozens of channels needed in a RHEL subscription to get the same set of available packages. I certainly get the value in all of the various options for managing large enterprise deployments but CentOS is just much simpler to deal with for us in a small deployment and software-developer-centric environment. We end up using both RHEL and CentOS for different use cases but need to apply the same security framework and settings to both.
With regards to allowed security configurations, as a contractor we've never had issues with DSS and CentOS being allowed so long as we apply all the appropriate RHEL rules and can appropriately justify where we diverge. The only ones I've run into that end up not applicable across the two have been FIPS related, which we have to disable anyways to accommodate third party unsigned kernel modules for the Nvidia driver. The STIGs after all are just a guideline and place to start from so you can adapt it to your own environment with appropriate tailoring and justification, not a fixed "it has to be this way". Most of the government entities we work with (DoD and DoE) use RHEL for their infrastructure servers and end-user workstations but CentOS for their projects and developer environments. Many of the DoE labs we work with even use CentOS on their large scale HPC deployments (LANL, Sandia, LLNL, etc.) while others use RHEL proper.
- Chuck _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.orgmailto:scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.htmlhttps://urldefense.proofpoint.com/v2/url?u=https-3A__getfedora.org_code-2Dof-2Dconduct.html&d=DwMFaQ&c=jF7FvYH6t0RX1HrEjVCgHQ&r=EtM8rzsgMR2aFrLOrhF8eg&m=sQs4XyImh9erUQ4-3gVBECOLv_9BeTPvlxzzWuInd3o&s=grq8wVI8qu4vuVkjbtdbBZDkL9nifqdlW66A27wGGtY&e= List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelineshttps://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines&d=DwMFaQ&c=jF7FvYH6t0RX1HrEjVCgHQ&r=EtM8rzsgMR2aFrLOrhF8eg&m=sQs4XyImh9erUQ4-3gVBECOLv_9BeTPvlxzzWuInd3o&s=mCt-uqGPj8LaH_qjzjWqV50xzNXZ_vz1Ivy9YgfsSFg&e= List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_archives_list_scap-2Dsecurity-2Dguide-40lists.fedorahosted.org&d=DwMFaQ&c=jF7FvYH6t0RX1HrEjVCgHQ&r=EtM8rzsgMR2aFrLOrhF8eg&m=sQs4XyImh9erUQ4-3gVBECOLv_9BeTPvlxzzWuInd3o&s=Dfi5VXGHhI6O8AuhY8aBnk5pQ1a5hdLShV-ssH3XtDs&e=
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information -- _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.orgmailto:scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://urldefense.proofpoint.com/v2/url?u=https-3A__getfedora.org_code-2Dof... List Guidelines: https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_... List Archives: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_...
This message and any enclosures are intended only for the addressee. Please notify the sender by email if you are not the intended recipient. If you are not the intended recipient, you may not use, copy, disclose, or distribute this message or its contents or enclosures to any other person and any such actions may be unlawful. Ball reserves the right to monitor and review all messages and enclosures sent to or from this email address.
Charlie,
I understand that mechanism but my specific issue is running this in public spaces (GitLab.org runners). I don't have a great way to not go plastering around my ability to pull from the official repos that is suitable for FOSS-level CI testing.
Frankly, my instances last for an hour at maximum and could be running in one of many (including donated to the project) locations.
These aren't production, these are development but I don't want to give anyone the ability to abuse the account in my name via any given mechanism.
Trevor
On Sun, Dec 30, 2018 at 7:59 PM Todd, Charles CTODD@ball.com wrote:
Trevor, Tracing whether a reposync method is still license compliant, it’s still pretty easy. I have an agreement with my software manager where I take one of my licenses on RHN, or whatever we call it now, and give it the name of my system. The “host name” means nothing and can be something like “SHORTID-ACAS” or “SHORTID-CI1.” That allows you both to quickly asses whether a license is still in use during annual reviews. Red Hat is hardly in a position to complain since you bought, but don’t appear to have allocated, a license. Small numbers of systems are easy to manage like that. I’m fully compliant with licenses.
Charlie Todd
On Dec 30, 2018, at 6:05 PM, Trevor Vaughan tvaughan@onyxpoint.com wrote:
Hi Chuck,
So, I agree with you all the way up to FIPS. Unfortunately, the tracing that we've done on the FIPS 140-2 requirement through various ties to policy and FISMA *appears* to be unavailable except by the President of the US, by named position. Now, it's possible that this tracing is incorrect but I have yet to find anyone that could find another *documented* interpretation that overrides the Congressional mandate as handed down to NIST and inherited through the 800-53 and CNSS 1253.
That said, FIPS only applies for the "protection of sensitive information". If you don't have any sensitive information (i.e. 100% test and eval environment with independent credentials that have no access to any other system) then fire away.
Also, this mandate only applies to organizations directly under the Executive and Legislative branches of Government. The Judicial branch can do what it likes.
Sorry for the slight rant, this is one of those particular items that just drives me nuts in terms of laws (not policies) that people like to try and ignore when it gets inconvenient.
In terms of packages, I completely agree with Charlie that it's really simple to just grab all of the packages through various means so the RHN is really just making legitimate use more difficult for systems like yours and rapid CI testing systems. We specifically do not use one of the many ways of circumventing the process so that we don't run afoul of any licensing rules or restrictions.
Trevor
On Sun, Dec 30, 2018 at 12:35 PM Chuck Atkins chuck.atkins@kitware.com wrote:
Why use CentOS when RHEL developer subs are free?
For our environment where we have a small deployment of only 2-4 machines, CentOS is much easier to manage off-line on an air-gaped network. Mirroring the CentOS repos is pretty easy to do with reposync and monthly drops to a web server on the red network. The CentOS workstations can then just point to the yum repos on said webserver and everything works like it's supposed to. Trying to do this with RHEL-proper is frustrating at best. A satellite server is way overkill for a deployment like this and setting up the clients for a "normal" yum repo requires removing and uninstalling all of the subscription / rhn packages. There's also the simplicity of only have 2 system repos to worry about to get everything available in CentOS (Base + Updates) vs dealing with the dozens of channels needed in a RHEL subscription to get the same set of available packages. I certainly get the value in all of the various options for managing large enterprise deployments but CentOS is just much simpler to deal with for us in a small deployment and software-developer-centric environment. We end up using both RHEL and CentOS for different use cases but need to apply the same security framework and settings to both.
With regards to allowed security configurations, as a contractor we've never had issues with DSS and CentOS being allowed so long as we apply all the appropriate RHEL rules and can appropriately justify where we diverge. The only ones I've run into that end up not applicable across the two have been FIPS related, which we have to disable anyways to accommodate third party unsigned kernel modules for the Nvidia driver. The STIGs after all are just a guideline and place to start from so you can adapt it to your own environment with appropriate tailoring and justification, not a fixed "it has to be this way". Most of the government entities we work with (DoD and DoE) use RHEL for their infrastructure servers and end-user workstations but CentOS for their projects and developer environments. Many of the DoE labs we work with even use CentOS on their large scale HPC deployments (LANL, Sandia, LLNL, etc.) while others use RHEL proper.
- Chuck
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://getfedora.org/code-of-conduct.html https://urldefense.proofpoint.com/v2/url?u=https-3A__getfedora.org_code-2Dof-2Dconduct.html&d=DwMFaQ&c=jF7FvYH6t0RX1HrEjVCgHQ&r=EtM8rzsgMR2aFrLOrhF8eg&m=sQs4XyImh9erUQ4-3gVBECOLv_9BeTPvlxzzWuInd3o&s=grq8wVI8qu4vuVkjbtdbBZDkL9nifqdlW66A27wGGtY&e= List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines&d=DwMFaQ&c=jF7FvYH6t0RX1HrEjVCgHQ&r=EtM8rzsgMR2aFrLOrhF8eg&m=sQs4XyImh9erUQ4-3gVBECOLv_9BeTPvlxzzWuInd3o&s=mCt-uqGPj8LaH_qjzjWqV50xzNXZ_vz1Ivy9YgfsSFg&e= List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor... https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_archives_list_scap-2Dsecurity-2Dguide-40lists.fedorahosted.org&d=DwMFaQ&c=jF7FvYH6t0RX1HrEjVCgHQ&r=EtM8rzsgMR2aFrLOrhF8eg&m=sQs4XyImh9erUQ4-3gVBECOLv_9BeTPvlxzzWuInd3o&s=Dfi5VXGHhI6O8AuhY8aBnk5pQ1a5hdLShV-ssH3XtDs&e=
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
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://urldefense.proofpoint.com/v2/url?u=https-3A__getfedora.org_code-2Dof... List Guidelines: https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_... List Archives: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_...
This message and any enclosures are intended only for the addressee. Please notify the sender by email if you are not the intended recipient. If you are not the intended recipient, you may not use, copy, disclose, or distribute this message or its contents or enclosures to any other person and any such actions may be unlawful. Ball reserves the right to monitor and review all messages and enclosures sent to or from this email address. _______________________________________________ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
Trying to do this with RHEL-proper is frustrating at best
Technically, you should be able to create a local RHEL mirror using a large hard drive, a fat pipe, an unprivileged user, and your “RHEL-repo-access-pem”.
From: Trevor Vaughan [mailto:tvaughan@onyxpoint.com] Sent: Sunday, December 30, 2018 6:05 PM To: SCAP Security Guide scap-security-guide@lists.fedorahosted.org Subject: Re: Gov profiles gone from EL derivatives?
Hi Chuck,
So, I agree with you all the way up to FIPS. Unfortunately, the tracing that we've done on the FIPS 140-2 requirement through various ties to policy and FISMA *appears* to be unavailable except by the President of the US, by named position. Now, it's possible that this tracing is incorrect but I have yet to find anyone that could find another *documented* interpretation that overrides the Congressional mandate as handed down to NIST and inherited through the 800-53 and CNSS 1253.
That said, FIPS only applies for the "protection of sensitive information". If you don't have any sensitive information (i.e. 100% test and eval environment with independent credentials that have no access to any other system) then fire away.
Also, this mandate only applies to organizations directly under the Executive and Legislative branches of Government. The Judicial branch can do what it likes.
Sorry for the slight rant, this is one of those particular items that just drives me nuts in terms of laws (not policies) that people like to try and ignore when it gets inconvenient.
In terms of packages, I completely agree with Charlie that it's really simple to just grab all of the packages through various means so the RHN is really just making legitimate use more difficult for systems like yours and rapid CI testing systems. We specifically do not use one of the many ways of circumventing the process so that we don't run afoul of any licensing rules or restrictions.
Trevor
On Sun, Dec 30, 2018 at 12:35 PM Chuck Atkins <chuck.atkins@kitware.commailto:chuck.atkins@kitware.com> wrote: Why use CentOS when RHEL developer subs are free?
For our environment where we have a small deployment of only 2-4 machines, CentOS is much easier to manage off-line on an air-gaped network. Mirroring the CentOS repos is pretty easy to do with reposync and monthly drops to a web server on the red network. The CentOS workstations can then just point to the yum repos on said webserver and everything works like it's supposed to. Trying to do this with RHEL-proper is frustrating at best. A satellite server is way overkill for a deployment like this and setting up the clients for a "normal" yum repo requires removing and uninstalling all of the subscription / rhn packages. There's also the simplicity of only have 2 system repos to worry about to get everything available in CentOS (Base + Updates) vs dealing with the dozens of channels needed in a RHEL subscription to get the same set of available packages. I certainly get the value in all of the various options for managing large enterprise deployments but CentOS is just much simpler to deal with for us in a small deployment and software-developer-centric environment. We end up using both RHEL and CentOS for different use cases but need to apply the same security framework and settings to both.
With regards to allowed security configurations, as a contractor we've never had issues with DSS and CentOS being allowed so long as we apply all the appropriate RHEL rules and can appropriately justify where we diverge. The only ones I've run into that end up not applicable across the two have been FIPS related, which we have to disable anyways to accommodate third party unsigned kernel modules for the Nvidia driver. The STIGs after all are just a guideline and place to start from so you can adapt it to your own environment with appropriate tailoring and justification, not a fixed "it has to be this way". Most of the government entities we work with (DoD and DoE) use RHEL for their infrastructure servers and end-user workstations but CentOS for their projects and developer environments. Many of the DoE labs we work with even use CentOS on their large scale HPC deployments (LANL, Sandia, LLNL, etc.) while others use RHEL proper.
- Chuck _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.orgmailto:scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information -- THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.
scap-security-guide@lists.fedorahosted.org