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 <[email protected]> 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 > > [email protected] > > > > https://lists.fedorahosted.org/admin/lists/[email protected] > > ahosted.org https://github.com/OpenSCAP/scap-security-guide/ -- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected] https://github.com/OpenSCAP/scap-security-guide/
