Description of problem: I am not able to authenticate using GSSAPI after upgrade from Fedora 32 to Fedora 33. When setting setenforce 0 I am allowed to do so. After setting semodule -DB I can see deny in the log: AVC avc: denied { write } for pid=12548 comm="sendmail" name="krb5_0.rcache2" dev="..." ino=... scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:krb5_host_rcache_t:s0 tclass=file permissive=0 Version-Release number of selected component (if applicable): selinux-policy-targeted-3.14.6-29.fc33.noarch How reproducible: By sending mail. Steps to Reproduce: 1. Configure sendmail to use GSSAPI for authentication. 2. Send a mail. Actual results: User is not authenticated using GSSAPI. Expected results: User is authenticated using GSSAPI. Additional info:
# ls -Z /var/tmp/krb5_0.rcache2 system_u:object_r:krb5_host_rcache_t:s0 /var/tmp/krb5_0.rcache2 according to file_contexts:/var/tmp/krb5_0.rcache2 -- system_u:object_r:krb5_host_rcache_t:s0 In contrary: # ls -Z /var/tmp/krb5_23.rcache2 system_u:object_r:squid_tmp_t:s0 /var/tmp/krb5_23.rcache2
Is there some quick workaround apart from putting selinux to permissive mode or stopping restrictions on sendmail as a whole? I consider both to be a security problem. Thanks Marek
Here is a quick workaround: # semanage fcontext -a -t krb5_host_rcache_t /var/tmp/krb5_23.rcache2 # restorecon -v /var/tmp/krb5_23.rcache2 Unfortunately, it only works when the /var/tmp/krb5_23.rcache2 file exists. If we knew which process created the /var/tmp/krb5_23.rcache2 file, we can prepare a policy module which contains a special filename transition rule, which would label the file correctly during its creation.
This is not a workaround. I have no problem with /var/tmp/krb5_23.rcache2. I have problem with /var/tmp/krb5_0.rcache2 which already has fcontext type set to rb5_host_rcache_t which is not working with sendmail. I meant workaround to have sendmail running with selinux in enforcing mode.
This is the workaround: # cat local_sendmail_hostrcache.cil (allow sendmail_t krb5_host_rcache_t (file (write))) # semodule -i local_sendmail_hostrcache.cil which will work together with the command in c#3. The fix will consist of adding this permission and possibly a file transition for squid and uid number 23.
Hello, but there is no problem with squid. I just showed it as an example. The had been also another rcache files. For example for saslauthd. What is the reason of changing type for squid if it is working? There is a risk it will stop thereafter. If I apply the workaround attached in c#5 how will it be affected with future selinux-policy-targeted upgrades? Should I reaplly always until it is contained it the update? Or should I remove before every update and then add again until contained? Thanks Marek
Hello, is there any chance it will be fixed in next release of selinux-policy-targeted? Thanks Marek
Hello Zdenek, you meant all the *rcache* files in the /var/tmp should have krb5_host_rcache_t? OK, that makes sense to have same labels for all these files. So not only fixing sendmail is then required but also permission for squid are required, if squids rcache file is relabeled. The rcache file for saslauthd is already working with that label. Thanks. Marek
Hello, is somebody going to fix this bug? If I understood well it seems quite trivial and the solution is known. Is not it? Thnaks Marek
Hello, I just realized I reported similar case for saslauthd in the past. It was the bug 1769532. The solution is probably the same. Just for inspiration. The same fix is needed for sendmail and squid. The /var/tmp/krb5_0.rcache2 and /var/tmp/krb5_23.rcache2 files are affected. For the squid the bug is not visible. Probably policy does not enforce the squids rcache file to be correctly labeled? Or it expects it to be system_u:object_r:squid_tmp_t:s0 and not system_u:object_r:krb5_host_rcache_t:s0 and thus it is correct for squid? Marek
Hi Marek, We have already made fix for sendmail, where sendmail was not able write to krb5_host_rcache_t files. Pull request is here: https://github.com/fedora-selinux/selinux-policy/pull/635 In PR is attached COPR, so you can try new fix before merging it to policy. Also issue with squid_tmp_t has fixed. This issue is generally related with bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1878348.
Hello Patrik, great news. Is it safe to install fc35 packages on fc33? Or you mean testing and then downgrading back? Many thanks. Marek
Marek, it will be better to use fc33 packages. I also have made build for f33, so you can use this build. Build: https://download.copr.fedorainfracloud.org/results/pkoncity/selinux-policy/fedora-33-x86_64/02067787-selinux-policy/ You're welcome. Patrik
Hello Patrik, I confirm the fix is working for sendmail. For squid: ls -Z /var/tmp/krb5_23.rcache2 yields system_u:object_r:squid_tmp_t:s0 /var/tmp/krb5_23.rcache2 Everything is working. I am just curious whether it is the intent, since other rcache2 files are labeled system_u:object_r:krb5_host_rcache_t:s0. Any chance this fix for sendmail will go into mainstream soon? Thanks Marek
Yes, I made build only with sendmail patch, not with squid. So squid will be work too, but fix is in another patch, which I didn't add to this build. It depends, when will be merge my PR's with fixes. Patrik
Hi folks, This bz was created for F33, so I plan to backport all the related fixes as soon as the review is done. The new F33 build should follow soon.
Hello, it seems new mainstream package destroyed the settings. So it seems the policy is completely replaced by upgrading the rpm. So should I apply workaround from comment #5 every upgrade until it gets mainstream? Is it correct or did I miss something? Thanks Marek
Both local modules and semanage-fcontext commands make persistent changes. The fix has been merged in F34 and F33.
Great news. Thanks. Marek
I confirm the policy works for sendmail+gssapi authentication. Marek
FEDORA-2021-e2de9e9e55 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-e2de9e9e55
FEDORA-2021-e2de9e9e55 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-e2de9e9e55` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e2de9e9e55 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-e2de9e9e55 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.