Description of problem: Satellite 5.3 on RHEL 5.5 x86_64 with SELinux in Enforcing mode does not allow system registration by Satellite users with Kerberos PAM auth. Version-Release number of selected component (if applicable): Satellite 5.3 selinux-policy-2.4.6-279.el5_5.1 oracle-instantclient-selinux-10.2-9.6.el5sat spacewalk-selinux-0.5.4-10.el5sat How reproducible: Set Satellite Server to authenticate using PAM/Kerberos in /etc/rhn/rhn.conf (pam_auth_service = rhn-satellite). Set SELinux to be running in the Enforcing mode. Try to register a client, using the a user in the LDAP/Kerberos Database. Actual results: Cannot register the client. Expected results: Allow Kerberos users to register systems to Satellite when SELinux is Enforcing. Additional info: We reproduce this issue several times, and we created a **TEST** SELinux Policy module as a work around to the customer. The policy module is attached and the steps to run it: Before start, ensure if the packages below are installed: ## selinux-policy-2.4.6-279.el5_5.1 ## oracle-instantclient-selinux-10.2-9.6.el5sat ## spacewalk-selinux-0.5.4-10.el5sat If the packages were installed, now can go ahead: a) download the satellite-krb-ldap-auth-TEST-CASE00317907-unofficial.pp b) as root, install and load the selinux module policy. After this, the module will be persistent. $ semodule -i satellite-krb-ldap-auth-TEST-CASE00317907-unofficial.pp c) verify if the module is up and running $ semodule -l | grep satellite-kbr PS --> you must see the module loaded. d) try no register a client in Satellite Server e) To unload the policy, execute: $ semodule -r satellite-krb-ldap-auth-TEST-CASE00317907 Best Regards, Marcelo Moreira de Mello
Created attachment 450886 [details] TEST policy module data
Created attachment 450887 [details] TEST policy module source
Comment on attachment 450887 [details] TEST policy module source Changing content type to text/plain on the .te module source.
Taking.
For the PAM authentication to work, two things are needed: * allow_httpd_mod_auth_pam boolean set to on; * the new selinux-policy package(s) from bug 579105.
However, my tests show that on Satellite 5.4.0 on RHEL 5.5, those AVCs don't mean that the rhnreg_ks wouldn't work -- it passes fine.
(In reply to comment #10) > However, my tests show that on Satellite 5.4.0 on RHEL 5.5, those AVCs don't > mean that the rhnreg_ks wouldn't work -- it passes fine. Oops, scratch this -- I was in permissive.
Public note - as per comment #9 to have working PAM authentication in enforcing SELinux: They also need updated selinux-policy package plus allow_httpd_mod_auth_pam SELinux boolean needs to be set - this can be done manually by any customer encountering this issue as a work around. I am moving this bug from the sat54-errata tracker to sat600-triage. We will align a long term solution to the Sat 5.4.1 release cycles. Cliff
I've just checked that when I upgrade from RHEL 5.5's selinux-policy-targeted-2.4.6-279.el5 to RHEL 5.6's selinux-policy-targeted-2.4.6-300.el5_6.1, PAM auth works on Satellite 5.4.0 on RHEL 5, with # getsebool allow_httpd_mod_auth_pam allow_httpd_mod_auth_pam --> on Moving ON_QA.
On RHEL 6, tomcat6 no longer sources setenv.sh so the bug 627859 is back, albeit only on s390x, x86_64 seems to work. Our attempt to add the RHEL 5's tomcat5 behaviour to tomcat6 in RHEL 6 failed: bug 633810. Therefore we needed to hack in the setenv.sh support to tomcat6.conf, SATELLITE-5.4 56b078de2244b9fbdfecc8247cb3ddd17e92d532 and Satellite thirdparty 19e8ad06788e5f21e0fd9c88faa18f640a6f979b.
The new tomcatX.conf.3 needed during spacewalk-setup to modify the tomcat6.conf was not added to the spacewalk-setup-1.2.6-9 rpm -- my fault, sorry about that. Fixed in SATELLITE-5.4 d4ca322236e959bcae1806e6272e330b1a27823e. Tagged and built as spacewalk-setup-1.2.6-10.
Changing to Verified: Testing procedure: - Automated test Verified against: Satellite 5.4.1 re20110517.0 spacewalk-setup-1.2.6-10 oracle-config-1.1-7
Re-verified in oracle-config-1.1-7, spacewalk-setup-1.2.6-11. Moving to RELEASE_PENDING.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. https://rhn.redhat.com/errata/RHEA-2011-0875.html