Hello! I'm still learning my way around the directory tree and the build system and have a couple of questions. For historical reasons, we typically use CentOS on our servers, and I see that, instead of having its own product tree, CentOS is considered a derivative of RHEL. I suppose the reasons for that are pretty obvious, though it does create a bit of a problem when trying to do something specific to CentOS. One question I have about the way things are set up now, though, is that, although the XCCDF for RHEL7 defines 12 profiles, the XCCDF for CentOS only defines 2. I've grep'ed my way around the build system trying to figure out where the logic for that is, but haven't had any luck. Could someone point me to the right place?
What we want to do, ultimately, is define several new profiles that would be applied to CentOS within our organization, depending on the risk level of the system. The baseline for this would be close to the RHEL7 CUI profile, with a few obvious exceptions. Given the special status of CentOS as a derivative of RHEL, do you have any suggestions for a good way to do that? I'm guessing we'd have to define the profiles in rhel7/profiles, but then use some logic somewhere (nice and vague...) to apply them to CentOS so they end up in the CentOS XCCDF and DS, but rather than trial-and-error I thought I would just ask.
Along the way we'll probably write some OVAL content and rules to handle local situations and would be happy to contribute those if they would be useful.
Thanks!
Hi Tim,
The SIMP project automated running the SSG against test nodes using Beaker from Puppet to tie into our CI/CD process.
This is what had to happen to ensure that all derivative profiles contain all content for testing purposes.
https://github.com/simp/rubygem-simp-beaker-helpers/blob/master/lib/simp/bea...
Trevor
On Thu, Aug 1, 2019 at 9:43 AM Tim Burress taj@fedoraproject.org wrote:
Hello! I'm still learning my way around the directory tree and the build system and have a couple of questions. For historical reasons, we typically use CentOS on our servers, and I see that, instead of having its own product tree, CentOS is considered a derivative of RHEL. I suppose the reasons for that are pretty obvious, though it does create a bit of a problem when trying to do something specific to CentOS. One question I have about the way things are set up now, though, is that, although the XCCDF for RHEL7 defines 12 profiles, the XCCDF for CentOS only defines 2. I've grep'ed my way around the build system trying to figure out where the logic for that is, but haven't had any luck. Could someone point me to the right place?
What we want to do, ultimately, is define several new profiles that would be applied to CentOS within our organization, depending on the risk level of the system. The baseline for this would be close to the RHEL7 CUI profile, with a few obvious exceptions. Given the special status of CentOS as a derivative of RHEL, do you have any suggestions for a good way to do that? I'm guessing we'd have to define the profiles in rhel7/profiles, but then use some logic somewhere (nice and vague...) to apply them to CentOS so they end up in the CentOS XCCDF and DS, but rather than trial-and-error I thought I would just ask.
Along the way we'll probably write some OVAL content and rules to handle local situations and would be happy to contribute those if they would be useful.
Thanks! _______________________________________________ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
Thanks for that! I can't help wondering if people have considered separating CentOS and SL so that they can be treated individually without a lot of workarounds? Given that the rules and the checks are already centralized in linux_os (I think), it seems like there wouldn't be too much duplication, though I the nice thing about the derivatives is that a change in RHEL automatically gets propagated to the derivatives.
Alternatively, I wonder why it was decided to remove profiles like OSPP from CentOS? Of course, no CentOS system could meet all of those criteria (like the need for commercial support), but it seems like that's a user decision, and it's much easier to de-select one rule than to hack the logic that pulls profiles out.
Just some early morning thoughts, though!
Tim
I think that the decision was made to eliminate any 'official' government-style mappings in the builds that they simply cannot meet.
I agree that it should really be a flag that you can flip to turn them back on but I understand disabling them by default.
On Sat, Aug 3, 2019 at 6:04 AM Tim Burress taj@fedoraproject.org wrote:
Thanks for that! I can't help wondering if people have considered separating CentOS and SL so that they can be treated individually without a lot of workarounds? Given that the rules and the checks are already centralized in linux_os (I think), it seems like there wouldn't be too much duplication, though I the nice thing about the derivatives is that a change in RHEL automatically gets propagated to the derivatives.
Alternatively, I wonder why it was decided to remove profiles like OSPP from CentOS? Of course, no CentOS system could meet all of those criteria (like the need for commercial support), but it seems like that's a user decision, and it's much easier to de-select one rule than to hack the logic that pulls profiles out.
Just some early morning thoughts, though!
Tim _______________________________________________ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
Actually it is more than that. RHEL certifications including profiles that go through certification do not apply to CentOS and actually do not flow down from RHEL to CentOS. CentOS fails to meet certification requirements in the areas of cryptography and now in secure software supply chain which both OSPP and CUI have and will have requirements for. The Scientific Linux project is (unfortunately) no longer moving forward SL7 will be the last major release.
On Sat, Aug 3, 2019 at 4:59 AM Tim Burress taj@fedoraproject.org wrote:
Thanks for that! I can't help wondering if people have considered separating CentOS and SL so that they can be treated individually without a lot of workarounds? Given that the rules and the checks are already centralized in linux_os (I think), it seems like there wouldn't be too much duplication, though I the nice thing about the derivatives is that a change in RHEL automatically gets propagated to the derivatives.
Alternatively, I wonder why it was decided to remove profiles like OSPP from CentOS? Of course, no CentOS system could meet all of those criteria (like the need for commercial support), but it seems like that's a user decision, and it's much easier to de-select one rule than to hack the logic that pulls profiles out.
Just some early morning thoughts, though!
Tim _______________________________________________ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
Hi Tim,
The list of profiles that get included in CentOS XCCDFs is defined by variable "standard_profiles" in ssg/constants.py on line 57. If you want to include any RHEL Profile into CentOS XCCDF add its ID to this variable.
The magic that creates CentOS XCCDF is in build-scripts/enable_derivatives.py and ssg/build_derivatives.py. Basically, it takes the complete RHEL XCCDF and removes some things.
If you want to create a new profile, put it into profiles directory, eg. rhel7/profiles.
We currently don't have any way to define that the profile is CentOS only. That means your new profile will also appear in RHEL XCCDF and Scientific Linux XCCDF. We will probably need to develop some logic for that.
Alternatively, CentOS could be transformed to a separate product. This has been done for Oracle Linux. The drawback of creating a separate product is that it requires to duplicate a lot of things (profiles, CPE dictionaries,) and also to add the product ID into "prodtype" field in all rules and OVALs.
Regards
On Thu, Aug 1, 2019 at 3:43 PM Tim Burress taj@fedoraproject.org wrote:
Hello! I'm still learning my way around the directory tree and the build system and have a couple of questions. For historical reasons, we typically use CentOS on our servers, and I see that, instead of having its own product tree, CentOS is considered a derivative of RHEL. I suppose the reasons for that are pretty obvious, though it does create a bit of a problem when trying to do something specific to CentOS. One question I have about the way things are set up now, though, is that, although the XCCDF for RHEL7 defines 12 profiles, the XCCDF for CentOS only defines 2. I've grep'ed my way around the build system trying to figure out where the logic for that is, but haven't had any luck. Could someone point me to the right place?
What we want to do, ultimately, is define several new profiles that would be applied to CentOS within our organization, depending on the risk level of the system. The baseline for this would be close to the RHEL7 CUI profile, with a few obvious exceptions. Given the special status of CentOS as a derivative of RHEL, do you have any suggestions for a good way to do that? I'm guessing we'd have to define the profiles in rhel7/profiles, but then use some logic somewhere (nice and vague...) to apply them to CentOS so they end up in the CentOS XCCDF and DS, but rather than trial-and-error I thought I would just ask.
Along the way we'll probably write some OVAL content and rules to handle local situations and would be happy to contribute those if they would be useful.
Thanks! _______________________________________________ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
Personally, I would like it if I could just flip a switch and tell it to build *all* profiles for the 'RedHat family'.
Primarily, I use this for testing and just kicking around new ideas via Vagrant since getting ahold of "real" RedHat is still not viable in public Travis CI via Vagrant.
I can do everything else, but not that.
Trevor
On Mon, Aug 5, 2019 at 4:28 AM Jan Cerny jcerny@redhat.com wrote:
Hi Tim,
The list of profiles that get included in CentOS XCCDFs is defined by variable "standard_profiles" in ssg/constants.py on line 57. If you want to include any RHEL Profile into CentOS XCCDF add its ID to this variable.
The magic that creates CentOS XCCDF is in build-scripts/enable_derivatives.py and ssg/build_derivatives.py. Basically, it takes the complete RHEL XCCDF and removes some things.
If you want to create a new profile, put it into profiles directory, eg. rhel7/profiles.
We currently don't have any way to define that the profile is CentOS only. That means your new profile will also appear in RHEL XCCDF and Scientific Linux XCCDF. We will probably need to develop some logic for that.
Alternatively, CentOS could be transformed to a separate product. This has been done for Oracle Linux. The drawback of creating a separate product is that it requires to duplicate a lot of things (profiles, CPE dictionaries,) and also to add the product ID into "prodtype" field in all rules and OVALs.
Regards
On Thu, Aug 1, 2019 at 3:43 PM Tim Burress taj@fedoraproject.org wrote:
Hello! I'm still learning my way around the directory tree and the build system
and have a couple of questions. For historical reasons, we typically use CentOS on our servers, and I see that, instead of having its own product tree, CentOS is considered a derivative of RHEL. I suppose the reasons for that are pretty obvious, though it does create a bit of a problem when trying to do something specific to CentOS. One question I have about the way things are set up now, though, is that, although the XCCDF for RHEL7 defines 12 profiles, the XCCDF for CentOS only defines 2. I've grep'ed my way around the build system trying to figure out where the logic for that is, but haven't had any luck. Could someone point me to the right place?
What we want to do, ultimately, is define several new profiles that
would be applied to CentOS within our organization, depending on the risk level of the system. The baseline for this would be close to the RHEL7 CUI profile, with a few obvious exceptions. Given the special status of CentOS as a derivative of RHEL, do you have any suggestions for a good way to do that? I'm guessing we'd have to define the profiles in rhel7/profiles, but then use some logic somewhere (nice and vague...) to apply them to CentOS so they end up in the CentOS XCCDF and DS, but rather than trial-and-error I thought I would just ask.
Along the way we'll probably write some OVAL content and rules to handle
local situations and would be happy to contribute those if they would be useful.
Thanks! _______________________________________________ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
-- Jan Černý Security Technologies | Red Hat, Inc. _______________________________________________ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
On 8/5/19 10:12 AM, Trevor Vaughan wrote:
Personally, I would like it if I could just flip a switch and tell it to build *all* profiles for the 'RedHat family'.
Primarily, I use this for testing and just kicking around new ideas via Vagrant since getting ahold of "real" RedHat is still not viable in public Travis CI via Vagrant.
With RHEL being free for development [0], the release of RHEL Universal Base Image [1] how is that still the case?
There's really zero excuse for continued use of CentOS, especially for Government systems.
I can do everything else, but not that.
[0] https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-subscri...
[1] https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image
Someone throw me an example of using it in Travis CI, under Docker, with access to repo updates and another example of using it via Vagrant in GitLab.com and I'm totally in.
I gave up trying to figure out a way to do it without putting my developer key in places where it doesn't look like I can put my developer key. Now, If I'm allowed to put my developer key in a Git repo and let it fly to the four winds without getting in trouble, that's really easy! Otherwise, someone needs to hop on one of the 80 places that RedHat has technical blogs and clue me in.
Alternatively, giving FOSS projects free runners in a Red Hat cloud that has access to repo updates would work.
Heck, AppVeyor even lets me test on Windows easily (as does Vagrant in many cases) but trying to test on RHEL in a public CI system is more work than it's worth.
In terms of the flow down, I'm not using this for validation on any sort of real system and am making no claims that it means anything. What I'm doing is using what the rest of the FOSS world uses to develop and doing something that lets me know if there are going to be absolutely catastrophic effects when I test on RHEL without needing to figure out how to get developer keys working in GitLab and/or Travis.
Trevor
On Mon, Aug 5, 2019 at 1:34 PM Shawn Wells shawn@redhat.com wrote:
On 8/5/19 10:12 AM, Trevor Vaughan wrote:
Personally, I would like it if I could just flip a switch and tell it to build *all* profiles for the 'RedHat family'.
Primarily, I use this for testing and just kicking around new ideas via Vagrant since getting ahold of "real" RedHat is still not viable in public Travis CI via Vagrant.
With RHEL being free for development [0], the release of RHEL Universal Base Image [1] how is that still the case?
There's really zero excuse for continued use of CentOS, especially for Government systems.
I can do everything else, but not that.
[0]
https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-subscri...
[1] https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image _______________________________________________ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
To sort of backup Trevor, I wasn't aware of the download link that Shawn had in his email. I work in the Govt/Mil space and we apply DISA STIG for RHEL to CentOS and Scientific Linux. Doing so satisfies the ISSM's. My govt. customer doesn't want to buy RHEL, he's not supporting a 24/7 operation that has any real uptime demands, but he has govt customers who run RHEL. That said, having access to a RHEL ISO image that I can install, but then not update or add any packages to w/o a subscription is pretty useless, even for testing purposes. We self-host Gitlab Enterprise and I attempt (poorly) to provide reference artifacts of compliance reports that are required for us produce in for operations out of my CI pipelines also. The stuff I produce is used by other IT groups beyond my own, so having the ability to provide these compliance reporting artifacts for RHEL would be very useful.
Further, since reading Shawn's email, I downloaded the RHEL 8 ISO, installed in a VirtualBox VM to tinker with. I can't even easily install vbox tools to keep the VM from trapping my mouse. I also can't easily add packages or check for an update with out a subscription hassle. Sure, maybe I can spend an a couple hours figuring out how to get the tools installed with out a subscription...but again it's a hassle and why go through that when CentOS is an easy button? Heck, with CentOS, its likely that I don't even need to craft my own system, I can just go grab one someone else built with Vagrant or Docker.
I guess since I'm ranting a bit... Container testing provides limited use with things like STIG compliance, since you need "real" systems with kernel params, systemd, disk partitions, and such to get a full picture. There are so many functional gaps between being STIG compliant and having a system that actually works for whatever it's purpose might be. Having a means to test things seems pretty important for all of us in this arena.
Just two examples... 1) RH Satellite / Foreman on a system with RHEL-07-021024 applied doesn't work - https://access.redhat.com/solutions/3993801. It can be made to work by adding "-Djava.io.tmpdir=/some/other/temporary/directory" to the JAVA_ARGS variable in /etc/sysconfig/puppetserver. 2) Having selinux contain users to staff_u (per RHEL-07-020020) and attempting to burn a DVD from Gnome with Brasero fails miserably. In order to even discover the whole reason why, you have unmask the selinux hidden denials. Can I automate a test that validates this functionality?... probably not, but why even bother trying on RHEL with the hassle with subscriptions?
--Sean
On Mon, Aug 5, 2019 at 6:29 PM Trevor Vaughan tvaughan@onyxpoint.com wrote:
Someone throw me an example of using it in Travis CI, under Docker, with access to repo updates and another example of using it via Vagrant in GitLab.com and I'm totally in.
I gave up trying to figure out a way to do it without putting my developer key in places where it doesn't look like I can put my developer key. Now, If I'm allowed to put my developer key in a Git repo and let it fly to the four winds without getting in trouble, that's really easy! Otherwise, someone needs to hop on one of the 80 places that RedHat has technical blogs and clue me in.
Alternatively, giving FOSS projects free runners in a Red Hat cloud that has access to repo updates would work.
Heck, AppVeyor even lets me test on Windows easily (as does Vagrant in many cases) but trying to test on RHEL in a public CI system is more work than it's worth.
In terms of the flow down, I'm not using this for validation on any sort of real system and am making no claims that it means anything. What I'm doing is using what the rest of the FOSS world uses to develop and doing something that lets me know if there are going to be absolutely catastrophic effects when I test on RHEL without needing to figure out how to get developer keys working in GitLab and/or Travis.
Trevor
On Mon, Aug 5, 2019 at 1:34 PM Shawn Wells shawn@redhat.com wrote:
On 8/5/19 10:12 AM, Trevor Vaughan wrote:
Personally, I would like it if I could just flip a switch and tell it to build *all* profiles for the 'RedHat family'.
Primarily, I use this for testing and just kicking around new ideas via Vagrant since getting ahold of "real" RedHat is still not viable in public Travis CI via Vagrant.
With RHEL being free for development [0], the release of RHEL Universal Base Image [1] how is that still the case?
There's really zero excuse for continued use of CentOS, especially for Government systems.
I can do everything else, but not that.
[0]
https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-subscri...
[1] https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image _______________________________________________ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
Well, I may have my answer thanks to GitLab: https://gitlab.com/gitlab-org/gitlab-ce/issues/13784
Going to start experimenting and see how it goes. Will probably have to find some method to deadlock since I doubt Dev subscriptions allow dozens of subscriptions to fire off at once.
On Tue, Aug 6, 2019 at 11:37 AM Sean smalder73@gmail.com wrote:
To sort of backup Trevor, I wasn't aware of the download link that Shawn had in his email. I work in the Govt/Mil space and we apply DISA STIG for RHEL to CentOS and Scientific Linux. Doing so satisfies the ISSM's. My govt. customer doesn't want to buy RHEL, he's not supporting a 24/7 operation that has any real uptime demands, but he has govt customers who run RHEL. That said, having access to a RHEL ISO image that I can install, but then not update or add any packages to w/o a subscription is pretty useless, even for testing purposes. We self-host Gitlab Enterprise and I attempt (poorly) to provide reference artifacts of compliance reports that are required for us produce in for operations out of my CI pipelines also. The stuff I produce is used by other IT groups beyond my own, so having the ability to provide these compliance reporting artifacts for RHEL would be very useful.
Further, since reading Shawn's email, I downloaded the RHEL 8 ISO, installed in a VirtualBox VM to tinker with. I can't even easily install vbox tools to keep the VM from trapping my mouse. I also can't easily add packages or check for an update with out a subscription hassle. Sure, maybe I can spend an a couple hours figuring out how to get the tools installed with out a subscription...but again it's a hassle and why go through that when CentOS is an easy button? Heck, with CentOS, its likely that I don't even need to craft my own system, I can just go grab one someone else built with Vagrant or Docker.
I guess since I'm ranting a bit... Container testing provides limited use with things like STIG compliance, since you need "real" systems with kernel params, systemd, disk partitions, and such to get a full picture. There are so many functional gaps between being STIG compliant and having a system that actually works for whatever it's purpose might be. Having a means to test things seems pretty important for all of us in this arena.
Just two examples...
- RH Satellite / Foreman on a system with RHEL-07-021024 applied doesn't
work - https://access.redhat.com/solutions/3993801. It can be made to work by adding "-Djava.io.tmpdir=/some/other/temporary/directory" to the JAVA_ARGS variable in /etc/sysconfig/puppetserver. 2) Having selinux contain users to staff_u (per RHEL-07-020020) and attempting to burn a DVD from Gnome with Brasero fails miserably. In order to even discover the whole reason why, you have unmask the selinux hidden denials. Can I automate a test that validates this functionality?... probably not, but why even bother trying on RHEL with the hassle with subscriptions?
--Sean
On Mon, Aug 5, 2019 at 6:29 PM Trevor Vaughan tvaughan@onyxpoint.com wrote:
Someone throw me an example of using it in Travis CI, under Docker, with access to repo updates and another example of using it via Vagrant in GitLab.com and I'm totally in.
I gave up trying to figure out a way to do it without putting my developer key in places where it doesn't look like I can put my developer key. Now, If I'm allowed to put my developer key in a Git repo and let it fly to the four winds without getting in trouble, that's really easy! Otherwise, someone needs to hop on one of the 80 places that RedHat has technical blogs and clue me in.
Alternatively, giving FOSS projects free runners in a Red Hat cloud that has access to repo updates would work.
Heck, AppVeyor even lets me test on Windows easily (as does Vagrant in many cases) but trying to test on RHEL in a public CI system is more work than it's worth.
In terms of the flow down, I'm not using this for validation on any sort of real system and am making no claims that it means anything. What I'm doing is using what the rest of the FOSS world uses to develop and doing something that lets me know if there are going to be absolutely catastrophic effects when I test on RHEL without needing to figure out how to get developer keys working in GitLab and/or Travis.
Trevor
On Mon, Aug 5, 2019 at 1:34 PM Shawn Wells shawn@redhat.com wrote:
On 8/5/19 10:12 AM, Trevor Vaughan wrote:
Personally, I would like it if I could just flip a switch and tell it to build *all* profiles for the 'RedHat family'.
Primarily, I use this for testing and just kicking around new ideas via Vagrant since getting ahold of "real" RedHat is still not viable in public Travis CI via Vagrant.
With RHEL being free for development [0], the release of RHEL Universal Base Image [1] how is that still the case?
There's really zero excuse for continued use of CentOS, especially for Government systems.
I can do everything else, but not that.
[0]
https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-subscri...
[1] https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image _______________________________________________ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
My mind does still boggle a bit that you have to pass the username and password at the command line to subscription-manager.
On Wed, Aug 7, 2019 at 2:39 PM Trevor Vaughan tvaughan@onyxpoint.com wrote:
Well, I may have my answer thanks to GitLab: https://gitlab.com/gitlab-org/gitlab-ce/issues/13784
Going to start experimenting and see how it goes. Will probably have to find some method to deadlock since I doubt Dev subscriptions allow dozens of subscriptions to fire off at once.
On Tue, Aug 6, 2019 at 11:37 AM Sean smalder73@gmail.com wrote:
To sort of backup Trevor, I wasn't aware of the download link that Shawn had in his email. I work in the Govt/Mil space and we apply DISA STIG for RHEL to CentOS and Scientific Linux. Doing so satisfies the ISSM's. My govt. customer doesn't want to buy RHEL, he's not supporting a 24/7 operation that has any real uptime demands, but he has govt customers who run RHEL. That said, having access to a RHEL ISO image that I can install, but then not update or add any packages to w/o a subscription is pretty useless, even for testing purposes. We self-host Gitlab Enterprise and I attempt (poorly) to provide reference artifacts of compliance reports that are required for us produce in for operations out of my CI pipelines also. The stuff I produce is used by other IT groups beyond my own, so having the ability to provide these compliance reporting artifacts for RHEL would be very useful.
Further, since reading Shawn's email, I downloaded the RHEL 8 ISO, installed in a VirtualBox VM to tinker with. I can't even easily install vbox tools to keep the VM from trapping my mouse. I also can't easily add packages or check for an update with out a subscription hassle. Sure, maybe I can spend an a couple hours figuring out how to get the tools installed with out a subscription...but again it's a hassle and why go through that when CentOS is an easy button? Heck, with CentOS, its likely that I don't even need to craft my own system, I can just go grab one someone else built with Vagrant or Docker.
I guess since I'm ranting a bit... Container testing provides limited use with things like STIG compliance, since you need "real" systems with kernel params, systemd, disk partitions, and such to get a full picture. There are so many functional gaps between being STIG compliant and having a system that actually works for whatever it's purpose might be. Having a means to test things seems pretty important for all of us in this arena.
Just two examples...
- RH Satellite / Foreman on a system with RHEL-07-021024 applied doesn't
work - https://access.redhat.com/solutions/3993801. It can be made to work by adding "-Djava.io.tmpdir=/some/other/temporary/directory" to the JAVA_ARGS variable in /etc/sysconfig/puppetserver. 2) Having selinux contain users to staff_u (per RHEL-07-020020) and attempting to burn a DVD from Gnome with Brasero fails miserably. In order to even discover the whole reason why, you have unmask the selinux hidden denials. Can I automate a test that validates this functionality?... probably not, but why even bother trying on RHEL with the hassle with subscriptions?
--Sean
On Mon, Aug 5, 2019 at 6:29 PM Trevor Vaughan tvaughan@onyxpoint.com wrote:
Someone throw me an example of using it in Travis CI, under Docker, with access to repo updates and another example of using it via Vagrant in GitLab.com and I'm totally in.
I gave up trying to figure out a way to do it without putting my developer key in places where it doesn't look like I can put my developer key. Now, If I'm allowed to put my developer key in a Git repo and let it fly to the four winds without getting in trouble, that's really easy! Otherwise, someone needs to hop on one of the 80 places that RedHat has technical blogs and clue me in.
Alternatively, giving FOSS projects free runners in a Red Hat cloud that has access to repo updates would work.
Heck, AppVeyor even lets me test on Windows easily (as does Vagrant in many cases) but trying to test on RHEL in a public CI system is more work than it's worth.
In terms of the flow down, I'm not using this for validation on any sort of real system and am making no claims that it means anything. What I'm doing is using what the rest of the FOSS world uses to develop and doing something that lets me know if there are going to be absolutely catastrophic effects when I test on RHEL without needing to figure out how to get developer keys working in GitLab and/or Travis.
Trevor
On Mon, Aug 5, 2019 at 1:34 PM Shawn Wells shawn@redhat.com wrote:
On 8/5/19 10:12 AM, Trevor Vaughan wrote:
Personally, I would like it if I could just flip a switch and tell it to build *all* profiles for the 'RedHat family'.
Primarily, I use this for testing and just kicking around new ideas via Vagrant since getting ahold of "real" RedHat is still not viable in public Travis CI via Vagrant.
With RHEL being free for development [0], the release of RHEL Universal Base Image [1] how is that still the case?
There's really zero excuse for continued use of CentOS, especially for Government systems.
I can do everything else, but not that.
[0]
https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-subscri...
[1] https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image _______________________________________________ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ 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 --
There's really zero excuse for continued use of CentOS, especially for Government systems.
Honestly we would probably use RHEL for our servers if we could afford it, simply because it would be one less thing to worry about, but for a small company that nevertheless has lots of servers, the cost, or at least what we were quoted, was prohibitive. Actually even using CentOS required a cultural adjustment. Before that we built the OS ourselves from source code.
I'd like to bump this. I get wanting to not build them by default. It's still valid and useful content though and I think makes sense to have available as an advanced off-by-default developer-enabled feature. So I did just that: https://github.com/ComplianceAsCode/content/pull/4923 . Consequently the PR was promptly closed within about 20m by one of the maintainers with nothing more than a "Nope, not gonna do that", which, tbh, seemed like a fairly hostile way to interact with contributors. No discussion or explanation, just a sprinkling of nist references that don't actually have to do with the specific issue. The content generation used the enable_derivatives script which already peppers the XCCDF with applicable warnings.
---------- Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc. (518) 881-1183
On Fri, Aug 9, 2019 at 12:34 AM Tim Burress taj@fedoraproject.org wrote:
There's really zero excuse for continued use of CentOS, especially for Government systems.
Honestly we would probably use RHEL for our servers if we could afford it, simply because it would be one less thing to worry about, but for a small company that nevertheless has lots of servers, the cost, or at least what we were quoted, was prohibitive. Actually even using CentOS required a cultural adjustment. Before that we built the OS ourselves from source code. _______________________________________________ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
Thanks for the pointer to 'standard_profiles'. That plus adding a line to CMakeLists.txt seems to have done the trick, so I've been able to add a new profile to RHEL7 and can now check it versus CentOS 7, exactly as everybody described. Given that, it seems like breaking CentOS out of RHEL7 might, as has been pointed out, result in more duplication than it's worth. It was just hard to get started.
FWIW we don't use the profiles in order to qualify for a particular "official" seal of approval, but just as a way to develop, measure, and in some cases enforce consistent security configuration guidelines across all the systems that we maintain. So what I did was start with the RHEL7 OSPP profile, then add (and occasionally delete) rules as needed. Right now the big challenge is trying to understand the mindset needed to craft OVAL content. It's certainly not like any programming language I've ever used!
We've also just started using Gitlab so am very happy to see that people are integrating SCAP tests into their CI pipelines. No doubt I'll be back with questions about that once our developers get more familiar with Gitlab.
Thanks!
scap-security-guide@lists.fedorahosted.org
-
Chuck Atkins -
Gabe Alford -
Jan Cerny -
Sean -
Shawn Wells -
Tim Burress -
Trevor Vaughan