From Mark.A.Salowitz at uscg.mil Mon Feb 8 20:09:25 2016 Content-Type: multipart/mixed; boundary="===============5003248278848496449==" MIME-Version: 1.0 From: Salowitz, Mark A CTR To: scap-security-guide at lists.fedorahosted.org Subject: RE: [Non-DoD Source] Re: RHEL 7 Draft STIG release Date: Mon, 08 Feb 2016 20:09:08 +0000 Message-ID: In-Reply-To: DM2PR09MB06507F8CD0976743B203C167A2D50@DM2PR09MB0650.namprd09.prod.outlook.com --===============5003248278848496449== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 pos= ted 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: = Ensure No Daemons are Unconfined by SELinux = = Daemons for which the SELinux policy does not contain rules will inherit th= e = context of the parent process. Because daemons are launched during = startup and descend from the init process, they inherit the in= itrc_t context. =
=
= To check for unconfined daemons, run the following command: =
$ sudo ps -eZ | egrep "initrc" | egrep -vw "tr|ps|egrep|bash|awk" | tr=
 ':' ' ' | awk '{ print $NF }'
= It should produce no output in a well-configured system. =
= = Daemons which run with the initrc_t context may cause AVC denials, = or allow privileges that the daemon does not require. = = = = =
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 extensive= ly with a vendor to ensure this possibility gets covered and the lack of in= clusion 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(a)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 c= ommunity and maker of the software, don't know about RHEL7 security configu= ration 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" 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=3D"utf-8" Community Participants, Earlier this week a post was made to this forum/thread that made disparagin= g comments regarding DISA=E2=80=99s leadership over the STIG development pr= ocess and our contractor=E2=80=99s support in this effort. I want to shar= e 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 Fedo= ra=E2=80=99s Rules of Conduct: =E2=80=9CBe respectful. Not all of us will = agree all the time, but disagreement is no excuse for poor behavior and poo= r manners. We might all experience some frustration now and then, but we ca= nnot 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.=E2=80=9D 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 recommendatio= ns from Red Hat and communities such as this, and it=E2=80=99s welcomed. = I would simply ask that everyone please be respectful. If there are concer= ns outside of the technical area associated with this, please drop me a lin= e and we can discuss. My email address is roger.s.greenwell.civ(a)mail.mil. Respectfully, Roger Greenwell Chief, Cybersecurity =E2=80=93 DISA -- SCAP Security Guide mailing list scap-security-guide(a)lists.fedorahosted.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__lists.fedorahosted.o= rg_admin_lists_scap-2Dsecurity-2Dguide-40lists.fedorahosted.org&d=3DBQIGaQ&= c=3D0NKfg44GVknAU-XkWXjNxQ&r=3DiohgjlRx8rzsacNUP-p6Uoa5Wl3Ea1utSdxGRRALEQk&= m=3DcMConZG7TG2qygZK4mSOK_-MKdChPcE_InKzKH8IPWo&s=3DJuxqE8zJJVpXS5V4tEIS6T9= kmn6u4Mi2-8oIulrxC98&e=3D = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_OpenSCAP_= scap-2Dsecurity-2Dguide_&d=3DBQIGaQ&c=3D0NKfg44GVknAU-XkWXjNxQ&r=3DiohgjlRx= 8rzsacNUP-p6Uoa5Wl3Ea1utSdxGRRALEQk&m=3DcMConZG7TG2qygZK4mSOK_-MKdChPcE_InK= zKH8IPWo&s=3DOx2ixv8Cb3zNIF9H6VyEP4PaazyN9pOWOTNLLOXEoCw&e=3D=20 --===============5003248278848496449==--