Bug 500486 - context of /var/tmp/host_0
context of /var/tmp/host_0
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
10
All Linux
low Severity high
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-12 17:43 EDT by Kostas Georgiou
Modified: 2009-12-11 09:45 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-11 09:45:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kostas Georgiou 2009-05-12 17:43:28 EDT
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...
Comment 1 Kostas Georgiou 2009-05-12 18:38:56 EDT
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.
Comment 2 Miroslav Grepl 2009-05-13 05:16:26 EDT
Do you have allow_kerberos boolean turned on ?

# getsebool allow_kerberos
Comment 3 Daniel Walsh 2009-05-13 09:58:31 EDT
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.
Comment 4 Kostas Georgiou 2009-05-13 12:30:41 EDT
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.
Comment 5 Daniel Walsh 2009-05-13 13:59:37 EDT
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.
Comment 6 Kostas Georgiou 2009-05-13 15:39:29 EDT
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.
Comment 7 Kostas Georgiou 2009-05-13 15:49:42 EDT
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
Comment 8 Daniel Walsh 2009-05-14 08:41:45 EDT
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.
Comment 9 Kostas Georgiou 2009-05-14 12:58:02 EDT
New bug #500882 for kpropd.
Comment 10 Bug Zapper 2009-11-18 05:01:39 EST
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

Note You need to log in before you can comment on or make changes to this bug.