State resource setenforce command not being executed

[ronlipke]

Cookbook version

1.0.4

Chef-client version

12.11.18 && 13.0.118

Platform Details

Centos 7.3 && Centos 6.8

Scenario:

With selinux enabled, use either selinux::enforcing or selinux::permissive to set the desired selinux state

Steps to Reproduce:

1. Initial selinux status (Centos 7.3):

   $ sestatus
   SELinux status:                 enabled
   SELinuxfs mount:                /sys/fs/selinux
   SELinux root directory:         /etc/selinux
   Loaded policy name:             targeted
   Current mode:                   enforcing
   Mode from config file:          enforcing
   Policy MLS status:              enabled
   Policy deny_unknown status:     allowed
   Max kernel policy version:      28

2. Add selinux::permissive to node runlist. Set node['selinux']['status'] = 'permissive'
3. Run chef-client

Expected Result:

$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   permissive
Mode from config file:          permissive
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28

Actual Result:

$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          permissive
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28

This behavior is due to the guard on the state resource https://github.com/chef-cookbooks/selinux/blob/master/resources/state.rb#L43 applying the setenforce only when the temporary attribute it set to true. Seems counter-intuitive to have to reboot your node when using the state resource with default attributes (in the case of the recipes).

Looks like this was also addressed in https://github.com/chef-cookbooks/selinux/issues/39

(edited after further troubleshooting)

[jeremymv2]

I agree with your assessment. https://github.com/chef-cookbooks/selinux/blob/master/resources/state.rb#L43 <--- I don't think that should have an if guard. If the user requested action: permissive by golly set it! The temporary property is already guarding the template rendering below on line 45 which makes it permanet across reboots or not.

[iennae]

Thanks for opening this issue. We're talking about why this works the way it does in this community cookbook. Previously there was some inconsistent behaviors. To be consistent in behaviors and be explicit about behaviors is why it's set up the way it is right now. I'm ok with making some changes here, but I want to do the thing that is minimally surprising (i.e. consistency across platforms, and behaviors on actions work in similar fashion) as well as minimal complexity. @jeremymv2 and I have talked and we're going to think about potential solutions to allow for a permanent, non-rebooting change here.

[ronlipke]

Thanks for looking into this @iennae and @jeremymv2. We are remaining pinned to an earlier version that gives us the expected behavior in the meantime.

I feel that a permanent, non-rebooting solution should be the default when explicitly calling for a state of "enforcing" or "permissive" as this would be the case in most scenarios. At least for Centos/RHEL, that entails ensuring the current status is the one you asked for (setenforce) and writing to the config file to persist the status on reboot. I understand that other distros that don't have selinux enabled in the kernel by default compound this problem by requiring a reboot just to get selinux active.

Let me know if we can be any help while you're working through it. Thanks again!

[iennae]

Thanks again for reporting this issue. After examining the issue thoroughly, and discussions within the team, we are deprecating support for ubuntu/debian from this cookbook so that we do not have the issue with different behaviors across systems. As of 2.0.0 behaviors will be different across the platforms as changes on rhel family systems will not require a reboot to activate. Please let us know if you have any issues with 2.0.0.

Thanks!