Putting the so called personal attacks aside, I think what most of us want to know is what does the support vendor in question know that we, the SSG community and maker of the software, don't know about RHEL7 security configuration that warrants the additional checks being put into the draft.
Regards, Wei Chen
________________________________________
----------------------------------------------------------------------
Date: Fri, 05 Feb 2016 02:47:03 -0000 From: "Roger Greenwell" greenwer@fedoraproject.org Subject: RE: [Non-DoD Source] Re: RHEL 7 Draft STIG release To: scap-security-guide@lists.fedorahosted.org Message-ID: 20160205024703.21572.23440@mailman01.phx2.fedoraproject.org Content-Type: text/plain; charset="utf-8"
Community Participants,
Earlier this week a post was made to this forum/thread that made disparaging comments regarding DISA’s leadership over the STIG development process and our contractor’s support in this effort. I want to share with this group that DISA government leadership is fully in charge of our actions/decisions and our contract staff is there to provide support to us.
Having just signed into this forum tonight, I noted the following from Fedora’s Rules of Conduct: “Be respectful. Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It's important to remember that a community where people feel uncomfortable or threatened is not a productive one.” To the author of this, WELL SAID!!!!
Shawn Wells, in his post, noted that DISA has been a cooperative partner in the STIG process. DISA greatly values the contributions and recommendations from Red Hat and communities such as this, and it’s welcomed. I would simply ask that everyone please be respectful. If there are concerns outside of the technical area associated with this, please drop me a line and we can discuss. My email address is roger.s.greenwell.civ@mail.mil.
Respectfully, Roger Greenwell Chief, Cybersecurity – DISA
Good afternoon,
I normally lurk and would ordinarily try to stay out of these discussions, but there's a discrepancy between the SSG version and the Draft version posted on DISA's with respect to SELinux policy.
I'd like to pose this question, if I may, as I am currently working with a vendor on this precise issue. The SSG draft had a control as shown below:
<Rule id="selinux_confinement_of_daemons" severity="medium"> <title>Ensure No Daemons are Unconfined by SELinux</title> <description> Daemons for which the SELinux policy does not contain rules will inherit the context of the parent process. Because daemons are launched during startup and descend from the <tt>init</tt> process, they inherit the <tt>initrc_t</tt> context. <br/> <br/> To check for unconfined daemons, run the following command: <pre>$ sudo ps -eZ | egrep "initrc" | egrep -vw "tr|ps|egrep|bash|awk" | tr ':' ' ' | awk '{ print $NF }'</pre> It should produce no output in a well-configured system. </description> <rationale> Daemons which run with the <tt>initrc_t</tt> context may cause AVC denials, or allow privileges that the daemon does not require. </rationale> <oval id="selinux_confinement_of_daemons" /> <ref nist="AC-6,AU-9,CM-7" /> <ident cce="27288-0" /> </Rule>
Is this rule intended to be in the Release version of the DISA RHEL7 STIG? I hate to kick a hornet's nest here, but I've been working rather extensively with a vendor to ensure this possibility gets covered and the lack of inclusion in the Draft STIG may undermine those efforts.
Thanks in advance,
Mark Salowitz Linux SA, USCG OSC Martinsburg
-----Original Message----- From: Wei N Chen (CENSUS/OIS FED) [mailto:wei.n.chen@census.gov] Sent: Monday, February 08, 2016 2:52 PM To: scap-security-guide@lists.fedorahosted.org Subject: RE: [Non-DoD Source] Re: RHEL 7 Draft STIG release
Putting the so called personal attacks aside, I think what most of us want to know is what does the support vendor in question know that we, the SSG community and maker of the software, don't know about RHEL7 security configuration that warrants the additional checks being put into the draft.
Regards, Wei Chen
________________________________________
----------------------------------------------------------------------
Date: Fri, 05 Feb 2016 02:47:03 -0000 From: "Roger Greenwell" greenwer@fedoraproject.org Subject: RE: [Non-DoD Source] Re: RHEL 7 Draft STIG release To: scap-security-guide@lists.fedorahosted.org Message-ID: 20160205024703.21572.23440@mailman01.phx2.fedoraproject.org Content-Type: text/plain; charset="utf-8"
Community Participants,
Earlier this week a post was made to this forum/thread that made disparaging comments regarding DISA’s leadership over the STIG development process and our contractor’s support in this effort. I want to share with this group that DISA government leadership is fully in charge of our actions/decisions and our contract staff is there to provide support to us.
Having just signed into this forum tonight, I noted the following from Fedora’s Rules of Conduct: “Be respectful. Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It's important to remember that a community where people feel uncomfortable or threatened is not a productive one.” To the author of this, WELL SAID!!!!
Shawn Wells, in his post, noted that DISA has been a cooperative partner in the STIG process. DISA greatly values the contributions and recommendations from Red Hat and communities such as this, and it’s welcomed. I would simply ask that everyone please be respectful. If there are concerns outside of the technical area associated with this, please drop me a line and we can discuss. My email address is roger.s.greenwell.civ@mail.mil.
Respectfully, Roger Greenwell Chief, Cybersecurity – DISA -- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_... https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenSCAP_sca...
No concerns outside of the technical area...but curious why "additional" requirements would be categorized as "mysteriously appearing" in addition to the SSG community inputs? Are the additional STIG rules an expansion based on CNSSI-1253 recommendations? Do additional STIG rules address areas where physical checks/audits are required where remediation is difficult to automate?
Will RHEL-7 Benchmark more closely resemble current SSG community contributions?
scap-security-guide@lists.fedorahosted.org