Bug 718633
| Summary: | SELinux, saslauthd & /var/tmp/host_0 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Anthony Messina <amessina> |
| Component: | krb5 | Assignee: | Nalin Dahyabhai <nalin> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | dwalsh, nalin, ssorce |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | krb5-1.9.1-5.fc15 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-07-18 21:06:48 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
user_tmp_t is created via a user process. Something you are running in the login session is recreating this file. Probably a kerberized application. Does the pending update at https://admin.fedoraproject.org/updates/krb5-1.9.1-5.fc15 fix this for you? (It should.) I think I've actually seen something similar today with both dirsrv and krb5kdc while playing with plugins that made them crash. The replay cache management thing is particularly fragile it seems. I'll load 1.9.1-5 and report if I see anything again. Thanks, Dan. Do you know of a way I can try to watch the host_0 file to figure out which application is modifying the file label? From what I have configured, it could possibly be any one of: nfsv4, postfix (via saslauthd), cyrus-imapd (via saslauthd), httpd (koji), ... (In reply to comment #3) > I think I've actually seen something similar today with both dirsrv and krb5kdc > while playing with plugins that made them crash. > The replay cache management thing is particularly fragile it seems. > I'll load 1.9.1-5 and report if I see anything again. I will try it out. Ok, I have installed: krb5-workstation-1.9.1-5.fc15.x86_64 krb5-libs-1.9.1-5.fc15.x86_64 and will see if this fixes the issue. It may take some time however, as I can't pinpoint when this issue occurs. So far, /var/tmp/host_0 has not had it's label changed from krb5_host_rcache_t to user_tmp_t since installing; krb5-workstation-1.9.1-5.fc15.x86_64 krb5-libs-1.9.1-5.fc15.x86_64 I'll keep an eye out throughout the week to see if that happened to be the "fix' for this strange issue. I still have not seen this issue since installing: krb5-workstation-1.9.1-5.fc15.x86_64 krb5-libs-1.9.1-5.fc15.x86_64 Somehow, the fix must have been related. I would close this bug. |
I have a Kerberized environment where saslauthd is used to authenticate imap and smtp sessions via Kerberos/GSSAPI. I'm running into issues where saslauthd loses its ability to process Kerberos logins in enforcing mode. This occurs after the /var/tmp/host_0 file has its file context label changed from krb5_host_rcache_t to user_tmp_t. When I boot the system, the proper label, krb5_host_rcache_t, is in place and everything works well. At *some* point, the label is changed to user_tmp_t and saslauthd is rejected with the following AVC: type=SYSCALL msg=audit(1309755127.137:15828): arch=c000003e syscall=87 success=no exit=-13 a0=c029a0 a1=ffffffff a2=0 a3=36c7d933ac items=0 ppid=1368 pid=1373 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="saslauthd" exe="/usr/sbin/saslauthd" subj=system_u:system_r:saslauthd_t:s0 key=(null) type=AVC msg=audit(1309755681.793:15883): avc: denied { unlink } for pid=1369 comm="saslauthd" name="host_0" dev=sdd3 ino=3530947 scontext=system_u:system_r:saslauthd_t:s0 tcontext=system_u:object_r:user_tmp_t:s0 tclass=file I am having trouble figuring out where to go. Should saslauthd be allowed to unlink user_tmp_t? If not, how do I go about figuring out which other program is allowed to change the label to user_tmp_t? Is there a way to "watch" the host_0 file to determine which program is changing the SELinux label? Right now, I have the following in place until a solution can be found: module fixsaslauthd 1.0; require { type user_tmp_t; type saslauthd_t; class file unlink; } #============= saslauthd_t ============== allow saslauthd_t user_tmp_t:file unlink;