During our System Administration II class we encountered an issue of not being able to undo the 'setsebool -P secure_mode_policyload on' command. This command writes the policy of: "do not allow the computer to go from enforcing to permissive mode", but the only way to turn off this policy is by being in permissive.... vicious little cycle.
After not being able to find this on any sources from the internet we decided to post it for anyone else that has encountered this issue.
This testing was done inside of VMware Workstation pro 15 with RHEL 7
Editor: Michael Mahnke
___________________________________________________________________________
The Setup: default configuration i started with.
#: Cat /etc/selinux/config
is the default where SELINUX=enforcing
#: Getsebool -a | grep policy
secure_mode_policyload -> off
#: sestatus
current mode: enforcing
mode from config file: enforcing
__________________________________________________________________________
The Processes: what i did to break it.
#: Setsebool -P secure_mode_policyload on
(if you get permission denied try running the command 1-2 times more)
#: Getsebool -a | grep policy
Verify it has changed to on
Reboot
#: Getsebool -a | grep policy
Verify it has changed to on
#: Setenforce permissive
You should get “setenforce: setenforce() failed”
#: Setsebool -P secure_mode_policyload off
This will NOT kick back any errors, BUT it will also not change the secure_mode_policyload Boolean to off.
#: Getsebool -a | grep policy
To verify
___________________________________________________________________________
The Fix: what i did to fix it.
#: Vi /etc/selinux/config
Edit file to “SELINUX=permissive”
Reboot
You should now be in permissive mode
#: Sestatus
To verify
Setsebool -P secure_mode_policyload off
This will act the same as previous with no errors
Getsebool -a | grep policy
Verify. NOW it says it is off.
Vi /etc/selinux/config
Edit file back to default of “SELINUX=enforcing”
Credit goes to:
Michael Mahnke
Robert Blong
Professor Trevor Chandler
Exactly!
And good choice with permissive. You had completely disabled SELinux you would not have been able to change the boolean with the commands and you would have required a reboot and relabel to get back to enabled.
The same type of thing happens with the audit daemon. There is a way to lock it down so that no attacker can change the settings but you must reboot in order to disable the lock down. It is a good reason to have different passwords for root and the grub boot loader.
Speaking of grub, I might have first tried to pass the enforcing=0 parameter to the kernel from grub so I would not be editing - and forgetting to reedit - the persistent configuration file.
Keep learning!
Thanks for the feedback! I'll have to investigate that in our next class. I'm really looking forward to exploring more into RHEL
Red Hat
Learning Community
A collaborative learning environment, enabling open source skill development.