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 
<[email protected]<mailto:[email protected]>> 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 
<[email protected]<mailto:[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]<mailto:[email protected]>
To unsubscribe send an email to 
[email protected]<mailto:[email protected]>
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/[email protected]<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 -- 
[email protected]<mailto:[email protected]>
To unsubscribe send an email to 
[email protected]<mailto:[email protected]>
Fedora Code of Conduct: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__getfedora.org_code-2Dof-2Dconduct.html&d=DwIGaQ&c=jF7FvYH6t0RX1HrEjVCgHQ&r=EtM8rzsgMR2aFrLOrhF8eg&m=sQs4XyImh9erUQ4-3gVBECOLv_9BeTPvlxzzWuInd3o&s=grq8wVI8qu4vuVkjbtdbBZDkL9nifqdlW66A27wGGtY&e=
List Guidelines: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines&d=DwIGaQ&c=jF7FvYH6t0RX1HrEjVCgHQ&r=EtM8rzsgMR2aFrLOrhF8eg&m=sQs4XyImh9erUQ4-3gVBECOLv_9BeTPvlxzzWuInd3o&s=mCt-uqGPj8LaH_qjzjWqV50xzNXZ_vz1Ivy9YgfsSFg&e=
List Archives: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_archives_list_scap-2Dsecurity-2Dguide-40lists.fedorahosted.org&d=DwIGaQ&c=jF7FvYH6t0RX1HrEjVCgHQ&r=EtM8rzsgMR2aFrLOrhF8eg&m=sQs4XyImh9erUQ4-3gVBECOLv_9BeTPvlxzzWuInd3o&s=Dfi5VXGHhI6O8AuhY8aBnk5pQ1a5hdLShV-ssH3XtDs&e=

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 -- [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]

Reply via email to