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(a)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(a)fedoraproject.org>
Subject: RE: [Non-DoD Source] Re: RHEL 7 Draft STIG release
To: scap-security-guide(a)lists.fedorahosted.org
Message-ID:
<20160205024703.21572.23440(a)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(a)mail.mil.
Respectfully,
Roger Greenwell
Chief, Cybersecurity – DISA
--
SCAP Security Guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.o...
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenSCAP_...