On Mar 21, 2016, at 12:12 PM, Shawn Wells <shawn(a)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_S...
[1]
http://iase.disa.mil/stigs/Documents/u_application_server_srg_v2_release_...
We have customers that must meet the STIG requirements but also need to have custom policy
written. Who is the intended audience that must meet this requirement? I would assume it’s
all federal systems running RHEL 7. I have some concerns about failing STIG checks and
getting push back because of it. I know that for the majority of the government these STIG
checks will actually be a good thing and will help them ensure that the SELinux policy is
the most “secure" state possible given their environment. However, I want to
understand how this change might impact those of us that do more customization of the
policy or completely replace it with one of our own. I’d imagine that it would just be a
documentation exercise to state that the solution has custom policy but hopefully the
audience on this list can validate that assumption.