Heh...well, if I'm making Frakenrepos I'm probably not all that worried about adding additional GPG keys :-P
On Wed, Jan 2, 2019 at 11:07 AM Brent Kimberley <[email protected]> wrote: > It was more of an issue prior to the repo_gpgcheck flag - repository > metadata signing. > > Nevertheless, there is always the full-lifecycle argument. > > > > *From:* Brent Kimberley > *Sent:* Wednesday, January 2, 2019 10:11 AM > *To:* SCAP Security Guide <[email protected]> > *Subject:* RE: Gov profiles gone from EL derivatives? > > > > Agreed > > > > *From:* Trevor Vaughan [mailto:[email protected] > <[email protected]>] > *Sent:* Wednesday, January 2, 2019 10:02 AM > *To:* SCAP Security Guide <[email protected]> > *Subject:* Re: Gov profiles gone from EL derivatives? > > > > Brent, > > > > You're missing my use case. I don't necessarily own the entire testing > infrastructure where tests are occurring. We do as much as possible in > public so that people have an understanding on what's going on under the > hood. > > > > Technically, there are a lot of ways to do this but none of them are > really great and may (or may not) violate the Red Hat licensing agreement > based on package redistribution. > > > > I mean, technically, I can just point a RHEL system at the OEL or CentOS > repos and be done with it, but it doesn't make for a very "correct" test. > > > > Fundamentally, the system is just behind the times for automated > infrastructure testing requirements if you want FOSS participation. > > > > Trevor > > > > On Wed, Jan 2, 2019 at 9:26 AM Brent Kimberley <[email protected]> > wrote: > > >>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:[email protected]] > *Sent:* Sunday, December 30, 2018 6:05 PM > *To:* SCAP Security Guide <[email protected]> > *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 <[email protected]> > 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 -- > [email protected] > To unsubscribe send an email to > [email protected] > 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/[email protected] > > > > > -- > > 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 mailing list -- > [email protected] > To unsubscribe send an email to > [email protected] > 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/[email protected] > > > > -- > > 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 mailing list -- > [email protected] > To unsubscribe send an email to > [email protected] > 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/[email protected] > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
