ssh with kerberos auth fails in one of my machines with the following AVC: type=AVC msg=audit(1242162696.342:40128): avc: denied { getattr } for pid=3392 comm="sshd" path="/var/tmp/host_0" dev=dm-3 ino=131192 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:krb5_host_rcache_t:s0 tclass=file On a different machine I get: type=AVC msg=audit(1242163719.190:36408): avc: denied { getattr } for pid=20929 comm="sshd" path="/var/tmp/host_0" dev=dm-4 ino=262170 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file On yet another machine ssh works but I see # ls -Z /var/tmp/host_0 -rw------- root root system_u:object_r:sshd_tmp_t /var/tmp/host_0 So I see two issues here: *) sshd needs to be able to access krb5_host_rcache_t *) /var/tmp/host_0 has the wrong context sometimes(?) depending on which service creates it I guess...
It's #428355 again I guess. The initrc_tmp_t context is from kpropd so I guess we need a policy for it at some point.
Do you have allow_kerberos boolean turned on ? # getsebool allow_kerberos
kpropd policy exists in F10. Also the kerberos libraries are supposed to create the /var/tmp/host_0 file with the correct label krb5_host_rcache_t So I would figure that either you did not have the latest policy installed or the latest kerberos files when these files were created.
All machines are up to date actually, allow_kerberos is on and the active kernel is the latest 2.6.27.21-170.2.56.fc10.x86_64. For kpropd I can see an fcontext with /etc/rc\.d/init\.d/kpropd as system_u:object_r:kerberos_script_exec_t:s0 but the init script is kprop and not kpropd which is the cause I guess. A quick test in the machine with the sshd_tmp_t label removing /var/tmp/host_0 and restarting sshd creates it with the right context as expected so not sure what went wrong I'll have to run some more tests.
That label is probably not a problem although it should be fixed in F10. It is probably labeled initrc_exec_t which is also allowed to transition to kpropd_t The only thing I can think of is the host_0 was created before the context and libraries were updated. If you can get this to happen using the latest code, we are real interested.
After a quick look at the policy I tried $chcon system_u:object_r:kpropd_exec_t:s0 /usr/kerberos/sbin/kpropd $/etc/init.d/kprop restart and now it's running with the correct context. Unfortunately this generates denials so the policy for kpropd isn't quite there yet :( sshd still needs a kerberos_manage_host_rcache(sshd_t) Do you want me to open new bugs for them? As for the context of /var/tmp/host_0 I am pretty sure that the file was OK a few weeks ago so something did fail but let me try to reproduce it.
sshd doesn't seem to create /var/tmp/host_0 with the right context as you can see below: hosta# ls -Z -rw------- root root system_u:object_r:krb5_host_rcache_t:s0 host_0 -rw------- cyrus mail unconfined_u:object_r:cyrus_tmp_t:s0 imap_76 -rw------- root root unconfined_u:object_r:kadmind_tmp_t:s0 kadmin_0 -rw------- root root unconfined_u:object_r:krb5kdc_tmp_t:s0 krb5kdc_rcache -rw------- root root unconfined_u:object_r:gssd_tmp_t:s0 nfs_0 -rw------- cyrus mail unconfined_u:object_r:cyrus_tmp_t:s0 sieve_76 hosta# rm host_0 rm: remove regular file `host_0'? y hostb$ ssh user@hosta (using my kerberos ticket) hosta# ls -Z -rw------- root root unconfined_u:object_r:sshd_tmp_t:s0 host_0 -rw------- cyrus mail unconfined_u:object_r:cyrus_tmp_t:s0 imap_76 -rw------- root root unconfined_u:object_r:kadmind_tmp_t:s0 kadmin_0 -rw------- root root unconfined_u:object_r:krb5kdc_tmp_t:s0 krb5kdc_rcache -rw------- root root unconfined_u:object_r:gssd_tmp_t:s0 nfs_0 -rw------- cyrus mail unconfined_u:object_r:cyrus_tmp_t:s0 sieve_76
I think we need to separate out these bugs. ssh not creating the host file with the correct label. And kprop(d)? labels being wrong, along with any other kprop problems.
New bug #500882 for kpropd.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping