Agreed
From: Trevor Vaughan [mailto:tvaughan@onyxpoint.com]
Sent: Wednesday, January 2, 2019 10:02 AM
To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org>
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
<Brent.Kimberley@durham.ca<mailto:Brent.Kimberley@durham.ca>> 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:tvaughan@onyxpoint.com<mailto:tvaughan@onyxpoint.com>]
Sent: Sunday, December 30, 2018 6:05 PM
To: SCAP Security Guide
<scap-security-guide@lists.fedorahosted.org<mailto: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.com<mailto: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<mailto:scap-security-guide@lists.fedorahosted.org>
To unsubscribe send an email to
scap-security-guide-leave@lists.fedorahosted.org<mailto: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.fe...
--
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 --
scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>
To unsubscribe send an email to
scap-security-guide-leave@lists.fedorahosted.org<mailto: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.fe...
--
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.