[Spacewalk-list] CentOS 7.4 + Spacewalk 2.6: PAM fails because of SELinux

[Paul-Andre Panon]

OK, after re-reading my notes in that e-mail, I should probably have changed the target context on /etc/krb5.conf to krb5_conf_t, though I have no idea why it wouldn't have been that way in the first place. And Olli should probably look at changing the target context on the keytab file to krb5_keytab_t. However I can't see how tomcat would have lost access to the PAM APIs. There is no way I would have changed that.

Paul-Andre Panon
Senior systems administrator
 

On Thursday, January 4, 2018 4:56 PM, Paul-Andre Panon wrote:
Hi Michael,

I beg to differ. I upgraded to Spacewalk 2.7 at about the same time as the 7.4 updates came out and it took me a long time to figure out that the SELinux policies are what broke PAM. I didn't get them fixed until just before Christmas.
While upgrading to SW 2.7 fixed a lot of issues with the 7.4 policy, the PAM sssd module still had problems accessing the krb5.conf file, and tomcat had problems accessing pam. 
Here's the notes I wrote for our internal team on the steps I took to resolve the PAM authentication issue:

"So I've finally got Spacewalk AD authentication working again. My PAM configuration is fine.
 
The first clue was an SELinux error in /var/log/messages that sssd couldn't access krb5.conf:

Dec 21 17:28:44 dc1-lsw01 python: SELinux is preventing /usr/libexec/sssd/sssd_be from write access on the file /etc/krb5.conf.#012#012*****  Plugin catchall_labels (83.8 confidence) suggests   *******************#012#012If you want to allow sssd_be to have write access on the krb5.conf file#012Then you need to change the label on /etc/krb5.conf#012Do#012# semanage fcontext -a -t FILE_TYPE '/etc/krb5.conf'#012where FILE_TYPE is one of the following: abrt_var_cache_t, afs_cache_t, auth_cache_t, faillog_t, gkeyringd_tmp_t, initrc_tmp_t, krb5_conf_t, krb5_host_rcache_t, krb5_keytab_t, mozilla_plugin_tmp_t, mozilla_plugin_tmpfs_t, puppet_tmp_t, security_t, selinux_login_config_t, sssd_public_t, sssd_var_lib_t, sssd_var_log_t, sssd_var_run_t, user_cron_spool_t, user_tmp_t.#012Then execute:#012restorecon -v '/etc/krb5.conf'#012#012#012*****  Plugin catchall (17.1 confidence) suggests   **************************#012#012If you believe that sssd_be should be allowed write access on the krb5.conf file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'sssd_be' --raw | audit2allow -M my-sssdbe#012# semodule -i my-sssdbe.pp#012

That led me to a post about CentOS 7.4 SELinux breaking a bunch of Spacewalk 2.6 stuff and not all of it fixed with Spacewalk 2.7. So I fixed that above error with the recommended ausearch/audit2allow command. Then I started seeing the following in /var/log/secure Dec 21 17:58:16 dc1-lsw01 java: PAM audit_log_acct_message() failed: Permission denied which led me to https://www.endpoint.com/blog/2013/11/20/selinux-fix-for-sudo-pam
and when I tried to turn off SELinux enforcement, authentication by PAM sssd started working.
 
So then I ran through the rest of the process in that latter blog entry, looked again in /var/log/messages, saw new SELinux errors about java (Spacewalk's Tomcat) and ran those through ausearch/audit2allow. And we're good to go again."

If you follow the endpoint blog link, you'll see that I was not the only person to find that not all SW 2.7 issues with the new SELinux policy have been resolved.

Paul-Andre Panon
Senior systems administrator