I'm going to go with 'it depends'. I've had very different results with permissive domain vs permissive global vs enforcing when trying to figure out what's actually killing my application.

Also, I'm doing all of this in a test environment and determining if it's SELinux, FIPS, or something else, quickly is important so some heavy handed approaches are low risk and high reward.

In production, I would absolutely recommend the approach that you linked. But you should know that the service you're deploying already works with SELinux enabled far before production.

Trevor

On Apr 8, 2016 9:52 AM, "Steve Grubb" <sgrubb@redhat.com> wrote:
On Friday, April 08, 2016 09:42:52 AM Trevor Vaughan wrote:
> I'm 100% on board with requiring SELinux to be enabled in targeted mode
> moving forward.
>
> The SIMP (https://github.com/NationalSecurityAgency/SIMP) stack runs with
> both SELinux targetd mode enabled and FIPS mode enabled in all of our tests
> and in our default installation. We identify where there are issues and we
> write custom policies as necessary to make our applications function
> properly.
>
> I don't know that I would restrict network connections by default (we
> don't....yet) but it's certainly something to strive toward. As is all
> outbound connections blocked by IPTables by default. (If my phone can do
> it, it shouldn't be a giant hurdle)
>
> The SELinux ecosystem has improved to the point where it is usable and
> maintainable by most administrators. That said, there does need to be the
> understanding that the process for moving forward if SELinux does not work
> should be:
>
> 1) Set SELinux to permissive on that system (never disable it or your
> contexts will be a mess when you try to enable it later)

Shouldn't the recipe be to put the application that is not working into a
permissive domain?

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Permissive_Domains.html

RHEL7 also supports permissive domains.

Then if you still have problems, put the whole machine into permissive mode.

-Steve

> 2) Create an action plan to create the proper policy for your application
> 3) Create the application policy
> 4) Implement the application policy
> 5) Re-enable SELinux in targeted mode
>
> Any broken policy, shipped by a vendor, should be seen as a high priority
> incident for that vendor and a patch should be shipped publicly as quickly
> as feasible.
>
> The SELinux community seems to have also gotten to the point where there is
> some realization that some policy is better than no policy. So that's a big
> win overall. You may end up with a weaker policy surrounding your
> application than you would like but that's 100% better than disabling
> SELinux across the system for one application.
>
> Thanks,
>
> Trevor
>
> On Mon, Mar 21, 2016 at 12:12 PM, Shawn Wells <shawn@redhat.com> wrote:
> > On 3/21/16 10:44 AM, Šimon Lukašík wrote:
> >
> > On 03/16/2016 07:26 PM, Mackanick, Jason W CIV DISA RE (US) wrote:
> >
> > I am here with Shawn Wells today and we would like your help in developing
> > the requirements for a possible inclusion of  SELinux requirements to be
> > included in the RHEL7 STIG.  As we move away from legacy file permissions
> > to type enforcement, we would like to work with the community to
> > understand security relevant configuration options such as SELinux
> > Booleans used in operational environments.   To calm any fears associated
> > with SELinux, we are only considering targeted policy and not the MLS
> > enablement.  Shawn will be working to gather your input.  Any of your
> > input would be appreciated if we could get it by Tuesday March 22, 2016
> > at the end of business.
> >
> >
> > Hello Jason,
> >
> > After talking with selinux crew here in Red Hat, I have learned that
> > defaults for selinux booleans are set rather defensively. The default is
> > always the more secure unless too generic use-case would be restricted.
> >
> > There is over 300 houndred selinux booleans in Red Hat Enterprise Linux
> > 7. I wonder where we can start. Or do you have some specific booleans in
> > mind?
> >
> > Perhaps it makes sense to go through these 300 hundreds and put them
> > into some kind of buckets? Something like
> >
> >   booleans that should absolutely always be true
> >   booleans that should always be false
> >
> >   booleans that default to true, but operators may often need to turn
> >
> > them false
> >
> >   ...
> >
> >   booleans that default to true, but stig advices to keep them false
> >   ...
> >
> > Thoughts?
> >
> >
> > To ensure everyone is on the same page of booleans, here's a list of the
> > ~300 RHEL7 booleans (output of 'semanage boolean -l'):
> > http://people.redhat.com/swells/boolean_list.txt
> >
> > One of the things discussed with DISA was proper scoping of what a RHEL7
> > STIG looks like. In the past, the RHEL STIGs have been a catch-all and
> > included configuration settings for things like OpenLDAP Server, HTTPD,
> > and
> > other 3rd party software (defined as non Operation System functionality).
> >
> > An example is the "all software library files must be {owned grouped
> > chmod'd}" rules. In such a case, the RHEL STIG *should* cover
> > RHEL-provided
> > library files under /usr/lib/{kernel systemd} directories, but not
> > /usr/lib/3rd_party_app.
> >
> > Part of this descoping is the reflection that DISA's Application SRG
> > [0][1] has been maturing. 3rd party software deployments, such as java
> > middleware servers, should be covered by the Application SRG requirements.
> > Not lumped into the Operating System STIG.
> >
> > RHEL7 may ship SELinux booleans for 3rd party software (e.g.
> > httpd_can_connect_mythtv, or ftpd_connect_db) however their existence
> > doesn't correlate to inclusion in the *operating system* STIG. The above
> > booleans would appropriately placed in the Apache STIG or FTP Server STIG,
> > while the RHEL STIG should ensure SELinux is enforcing and should have
> > system-level booleans set (e.g. selinuxuser_execmod,
> > use_ecryptfs_home_dirs, staff_exec_content).
> >
> > Your buckets idea is really great. Through the above lens, perhaps we can
> > modify the groupings to something like below:
> >
> > - Operating System booleans that should be true
> > - Operating System booleans that should be false
> > - Non-OS booleans to include in 3rd party STIGs (helping DISA identify
> > these will expedite their inclusion in things like Apache and JBoss
> > STIGs).
> >
> > When writing XCCDF rules, their description tag will included cases where
> > modification of setting may be called for. The OVAL side can use
> > selinuxboolean_test to automate everything. Thankfully remediation is a
> > bash 1-liner.
> >
> > [0]
> > http://iasecontent.disa.mil/stigs/zip/Oct2015/U_Application_Server_V2R2_SR
> > G.zip [1]
> > http://iase.disa.mil/stigs/Documents/u_application_server_srg_v2_release_m
> > emo.pdf
> >
> > --
> > SCAP Security Guide mailing list
> > scap-security-guide@lists.fedorahosted.org
> >
> > https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedor
> > ahosted.org https://github.com/OpenSCAP/scap-security-guide/