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(a)lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave(a)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.fe...

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(a)redhat.com&gt; 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(a)lists.fedorahosted.org > > To unsubscribe send an email to > > scap-security-guide-leave(a)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.fe... > > > > > -- > 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(a)lists.fedorahosted.org > To unsubscribe send an email to scap-security-guide- > leave(a)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.fe... _______________________________________________ scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave(a)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.fe...

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-subs... _______________________________________________ scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave(a)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.fe...

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(a)onyxpoint.com&gt; 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(a)redhat.com&gt; 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-subs... >> _______________________________________________ >> scap-security-guide mailing list -- >> scap-security-guide(a)lists.fedorahosted.org >> To unsubscribe send an email to >> scap-security-guide-leave(a)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.fe... >> > > > -- > 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 --

Why use CentOS when RHEL developer subs are free?

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(a)kitware.com&gt; 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(a)lists.fedorahosted.org > To unsubscribe send an email to > scap-security-guide-leave(a)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.fe... > -- 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(a)onyxpoint.com&gt; 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(a)kitware.com&gt; 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(a)lists.fedorahosted.org > To unsubscribe send an email to > scap-security-guide-leave(a)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-2... > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > <https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wi... > List Archives: > https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fe... > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.o... > -- 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(a)lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org Fedora Code of Conduct: https://urldefense.proofpoint.com/v2/url?u=https-3A__getfedora.org_code-2... List Guidelines: https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wi... List Archives: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.o... 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(a)lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave(a)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.fe...