On Mon, Jan 26, 2015 at 03:29:23PM -0500, Daniel J Walsh wrote:
You could also set the secure_ booleans
Is this in addition to or instead of removing unconfined users?
getsebool -a | grep secure_* secure_mode --> off secure_mode_insmod --> off secure_mode_policyload --> off
Without removing unconfined users this definitely stops setenforce working... but root can still set the boolean off.
So playing around, just to see what destruction I can cause...
Window 1 had an unconfined user doing tail -f /var/log/messages Window 2 had a guest_u user Window 3 had a sysadm_u user, su'd to root
In window 3 I did 'semanage -d unconfined' and then 'semanage -d unconfineduser'. At that point that window threw up libsemanage.dbase_llist_query: could not query record value (No such file or directory).
and control-C, control-Z, control-\ all did nothing interesting.
Window 1 (unconfined) displayed tonnes of errors from messages, around things like staff_u not being valid. Then froze, then eventually ssh session died; I'm guessing SELinux starting blocking the port. SELinux: Context staff_u:unconfined_r:samba_unconfined_net_t:s0 became invalid (unmapped). SELinux: Context unconfined_u:system_r:samba_unconfined_net_t:s0-s0:c0.c1023 became invalid (unmapped). SELinux: Context staff_u:system_r:samba_unconfined_net_t:s0 became invalid (unmapped).
The one session that stayed active was the guest_u one... but not a lot I can do, there!
root login on the console failed: Unable to get valid context for root
Cannot make/remove an entry for the specified session [342970.402198] audit: backlog limit exceeded [342970.402622] audit: backlog limit exceeded [342970.402983] audit: backlog limit exceeded
ssh as the sysadm_u user fails with context issues.
I can login with the sysadm_u user on the console, although this user can't see his own home directory.
And that was able to su to root and re-enable the two modules :-)