Normally, Red Hat does a decent job on their release notes about explaining what a new feature or change brings with each new RHEL minor release, but this time the release notes did not do the full scope of the change justice:
SSSD Fully Supported FeaturesThe key line here was "SELinux user mapping". This played in with IPA to generate some undesirable results, since the installation of IPA that was serving these systems did not have any SELinux user mapping defined, other than the default role.
A number of features introduced in Red Hat Enterprise Linux 6.3 are now fully supported in Red Hat Enterprise Linux 6.4. Specifically:
- support for central management of SSH keys,
- SELinux user mapping,
- and support for automount map caching.
Prior to the upgrade, mappings were not enforced, so the SELinux context was unconfined:
$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Post upgrade, the IPA default user was enforced. This was not obvious at first, though. The symptoms were that things that normally worked, didn't: sudo, su, dmesg, looking at log files. Standard sysadmin diagnostics stuff suddenly stopped working completely.
Trying to dig into this lead to very strange results, like not being able to run ls -l /bin/su directly and getting "?" for the su record when running ls -l /bin. The same kind of strange behavior happened to /var, /root, and a few other key areas. It behaved a lot like filesystem damage at first, but the fsck came back clean. Logging in as root on the system console did work though, so that was my first clue.
Because this behavior was so bizarre, I tried a setenforce 0 to rule out SELinux, and all of a sudden things started working for non-root users logged in remotely. I have been used to beating SELinux into submission a daemon context, but this was the first time I'd run into it as a user.
$id -ZUp until now, there were no SELinux User Maps in IPA, so default mapping to the guest role was being used. Thus, the first step was to define some non-guest roles to use.
guest_u:guest_r:guest_t:s0-s0:c0.c1023
There was not a lot of information about this on the IPA wiki, but I did find a decent writeup about configuring SELinux on Gentoo's site. This gave me the key pieces that I needed to setup a map for the user_u:user_r:user_t and the staff_u:staff_r:staff_t mappings for mere mortals and sysadmins.
Amazing what happens when you have permissions to actually run things!
The next step required was to cleanly handle the staff_t to sysadm_t transition for sudo without requiring a separate newrole command to be run. Thankfully, sudo is SELinux aware, so adding "role=sysadm_r" to the Sudo Rule in IPA that allows sysadmin commands took care of that part.
