Bug 505696 - kpropd is prevented from updating a slave KDC by SELinux policy
Summary: kpropd is prevented from updating a slave KDC by SELinux policy
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 11
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-06-12 23:31 UTC by Ben Webb
Modified: 2010-06-28 12:57 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-06-28 12:57:15 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Patch to add kpropd access (1.26 KB, application/octet-stream)
2009-07-06 19:28 UTC, Daniel Walsh
no flags Details
First attempt to fix the problem (247 bytes, text/plain)
2009-07-14 15:45 UTC, Ben Webb
no flags Details
Modified policy module that actually works (265 bytes, text/plain)
2009-07-14 15:47 UTC, Ben Webb
no flags Details

Description Ben Webb 2009-06-12 23:31:27 UTC
Description of problem:
We are running a Kerberos slave server (KDC) that runs kpropd (to get updates from the master). However, updates fail with SELinux in Enforcing mode, but work in Permissive mode.
This problem claims to have been fixed in selinux-policy-targeted 3.6.12-37 according to the changelog, but it doesn't work for us.


Version-Release number of selected component (if applicable):
selinux-policy-targeted-3.6.12-39.fc11.noarch
krb5-server-1.6.3-20.fc11.i586

How reproducible:
Always.

Steps to Reproduce:
1. Set up a master KDC (master) and a slave KDC (slave).

2. Allow the master to connect to the slave by adding
host/master@REALM
to /var/kerberos/krb5kdc/kpropd.acl on the slave.

3. Run on the master KDC
/usr/kerberos/sbin/kdb5_util dump foo
/usr/kerberos/sbin/kprop -f foo slave
  
Actual results:
kprop fails (with no output). kpropd reports on the slave, in /var/log/messages:
Jun 12 16:21:39 slave kpropd[2547]: Rejected connection from unauthorized principal host/master@REALM

Expected results:
kprop on the master reports
Database propagation to slave: SUCCEEDED

and kpropd on the slave reports in /var/log/messages
Jun 12 16:22:39 slave kpropd[2567]: Connection from master


Additional info:
Attaching strace to kpropd on the slave shows in the trace the following output:
[pid  2580] open("/var/kerberos/krb5kdc/kpropd.acl", O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission denied)

Thus, SELinux appears to be preventing it from reading the ACLs.

If I switch to Permissive mode with "setenforce 0" and try again, the update succeeds, but I see the following avcs:
Jun 12 16:27:12 slave kernel: type=1400 audit(1244849232.305:19): avc:  denied  { create } for  pid=2607 comm="kpropd" name="from_master.temp" scontext=system_u:system_r:kpropd_t:s0 tcontext=system_u:object_r:krb5kdc_conf_t:s0 tclass=file
Jun 12 16:27:12 slave kernel: type=1400 audit(1244849232.419:20): avc:  denied  { rename } for  pid=2607 comm="kpropd" name="from_master.temp" dev=sdb2 ino=2429 scontext=system_u:system_r:kpropd_t:s0 tcontext=system_u:object_r:krb5kdc_conf_t:s0 tclass=file
Jun 12 16:27:12 slave kernel: type=1400 audit(1244849232.420:21): avc:  denied  { unlink } for  pid=2607 comm="kpropd" name="from_master" dev=sdb2 ino=2428 scontext=system_u:system_r:kpropd_t:s0 tcontext=system_u:object_r:krb5kdc_conf_t:s0 tclass=file
Jun 12 16:27:13 slave kernel: type=1400 audit(1244849233.061:22): avc:  denied  { setattr } for  pid=2608 comm="kdb5_util" name="principal~.ok" dev=sdb2 ino=2430 scontext=system_u:system_r:kpropd_t:s0 tcontext=system_u:object_r:krb5kdc_conf_t:s0 tclass=file

File and process contexts look OK:
# ls -lZ /var/kerberos/krb5kdc/
-rw-------. root root system_u:object_r:krb5kdc_lock_t:s0 from_master
-rw-r--r--. root root system_u:object_r:krb5kdc_conf_t:s0 kadm5.acl
-rw-------. root root system_u:object_r:krb5_keytab_t:s0 kadm5.keytab
-rw-r--r--. root root system_u:object_r:krb5kdc_conf_t:s0 kdc.conf
-rw-r--r--. root root unconfined_u:object_r:krb5kdc_conf_t:s0 kpropd.acl
-rw-------. root root system_u:object_r:krb5kdc_principal_t:s0 principal
-rw-------. root root system_u:object_r:krb5kdc_principal_t:s0 principal.kadm5
-rw-------. root root system_u:object_r:krb5kdc_principal_t:s0 principal.kadm5.lock
-rw-------. root root system_u:object_r:krb5kdc_lock_t:s0 principal.ok

# ps auxwZ|grep kprop
system_u:system_r:kpropd_t:s0   root      1312  0.0  0.0   3124   360 ?        Ss   14:01   0:00 /usr/kerberos/sbin/kpropd -S

Comment 1 Daniel Walsh 2009-06-15 19:07:00 UTC
Fixed in selinux-policy-3.6.12-52.fc11

Comment 2 Louis Lagendijk 2009-06-20 15:16:48 UTC
I just tried 
[root@travel tmp]# rpm -qa selinux-policy*
selinux-policy-doc-3.6.12-53.fc11.noarch
selinux-policy-3.6.12-53.fc11.noarch
selinux-policy-targeted-3.6.12-53.fc11.noarch

I am still getting:
SummarySELinux is preventing the kpropd from using potentially mislabeled files (/usr/tmp). Detailed DescriptionSELinux has denied kpropd access to potentially mislabeled file(s) (/usr/tmp). This means that SELinux will not allow kpropd to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. Allowing AccessIf you want kpropd to access this files, you need to relabel them using restorecon -v '/usr/tmp'. You might want to relabel the entire directory using restorecon -R -v '/usr/tmp'. Additional InformationSource Context:  unconfined_u:system_r:kpropd_t:s0Target Context:  system_u:object_r:tmp_t:s0Target Objects:  /usr/tmp [ dir ]Source:  kpropdSource Path:  /usr/kerberos/sbin/kpropdPort:  <Unknown>Host:  travel.pheasantSource RPM Packages:  krb5-server-1.6.3-20.fc11Target RPM Packages:  filesystem-2.4.21-1.fc11Policy RPM:  selinux-policy-3.6.12-53.fc11Selinux Enabled:  TruePolicy Type:  targetedMLS Enabled:  TrueEnforcing Mode:  EnforcingPlugin Name:  home_tmp_bad_labelsHost Name:  travel.pheasantPlatform:  Linux travel.pheasant 2.6.29.4-167.fc11.x86_64 #1 SMP Wed May 27 17:27:08 EDT 2009 x86_64 x86_64Alert Count:  3First Seen:  Sat 20 Jun 2009 05:09:35 PM CESTLast Seen:  Sat 20 Jun 2009 05:15:37 PM CESTLocal ID:  a6f92c0b-0162-48ca-a32c-562c05fe1c50Line Numbers:  Raw Audit Messages :node=travel.pheasant type=AVC msg=audit(1245510937.693:107): avc: denied { write } for pid=5268 comm="kpropd" name="tmp" dev=dm-1 ino=47 scontext=unconfined_u:system_r:kpropd_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir node=travel.pheasant type=SYSCALL msg=audit(1245510937.693:107): arch=c000003e syscall=2 success=no exit=-13 a0=7fd436bb93b0 a1=2c1 a2=180 a3=7fff3ddedc10 items=0 ppid=5266 pid=5268 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=6 comm="kpropd" exe="/usr/kerberos/sbin/kpropd" subj=unconfined_u:system_r:kpropd_t:s0 key=(null)

Comment 3 Ben Webb 2009-06-23 01:59:50 UTC
Similar situation here with selinux-policy-targeted-3.6.12-53.fc11.noarch; the slave kpropd still cannot read the ACL file with SELinux activated. If I switch to permissive mode, it works (as before). However, now I don't see any avcs in the logs either in enforcing or permissive mode.

Comment 4 Daniel Walsh 2009-06-23 20:55:41 UTC
You can add these rules now using

# grep avc /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Fixed in selinux-policy-3.6.12-58.fc11  

Lets try this one, should be in koji soon

Comment 5 Ben Webb 2009-07-02 14:32:35 UTC
Still doesn't work for me with selinux-policy-targeted-3.6.12-62.fc11.noarch. With SELinux enforcing I still see the following in /var/log/messages:
Jul  2 07:19:44 slave kpropd[24529]: Connection from master
Jul  2 07:19:45 slave kpropd[24529]: Rejected connection from unauthorized principal host/master@REALM

with SELinux permissive I just get the first log entry, and the master reports:
Database propagation to slave: SUCCEEDED

As with the -53 update, I get no avcs now in either permissive or enforcing mode, so I can't use audit2allow.

If I turn off the dontaudit rules with "semodule -DB" I now see in the logs during a kprop attempt:

Jul  2 07:28:55 slave kernel: type=1400 audit(1246544935.824:15): avc:  denied  { write } for  pid=24614 comm="kpropd" name="krb5.conf" dev=sdb2 ino=21214 scontext=system_u:system_r:kpropd_t:s0 tcontext=system_u:object_r:krb5_conf_t:s0 tclass=file
Jul  2 07:28:55 slave kernel: type=1400 audit(1246544935.825:16): avc:  denied  { search } for  pid=24614 comm="kpropd" name="selinux" dev=sdb2 ino=11961 scontext=system_u:system_r:kpropd_t:s0 tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
Jul  2 07:28:55 slave kernel: type=1400 audit(1246544935.825:17): avc:  denied  { search } for  pid=24614 comm="kpropd" name="selinux" dev=sdb2 ino=11961 scontext=system_u:system_r:kpropd_t:s0 tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
Jul  2 07:28:55 slave kernel: type=1400 audit(1246544935.825:18): avc:  denied  { setfscreate } for  pid=24614 comm="kpropd" scontext=system_u:system_r:kpropd_t:s0 tcontext=system_u:system_r:kpropd_t:s0 tclass=process
Jul  2 07:28:55 slave kpropd[24614]: Rejected connection from unauthorized principal host/master@REALM
Jul  2 07:28:55 slave kernel: type=1400 audit(1246544935.867:19): avc:  denied  { read } for  pid=24614 comm="kpropd" name="kpropd.acl" dev=sdb2 ino=12064 scontext=system_u:system_r:kpropd_t:s0 tcontext=unconfined_u:object_r:krb5kdc_conf_t:s0 tclass=file

Comment 6 Daniel Walsh 2009-07-06 19:28:57 UTC
Created attachment 350665 [details]
Patch to add kpropd access

Miroslav can you add the following to f11 policy

Comment 7 Daniel Walsh 2009-07-06 19:29:43 UTC
You can add these rules for now using

# grep kpropd /var/log/audit/audit.log | audit2allow -M mykprop
# semodule -i mykprop.pp

Comment 8 Miroslav Grepl 2009-07-07 08:32:17 UTC
Fixed in selinux-policy-3.6.12-64.fc11

Comment 9 Ben Webb 2009-07-14 15:45:48 UTC
Created attachment 351615 [details]
First attempt to fix the problem

Comment 10 Ben Webb 2009-07-14 15:47:02 UTC
Created attachment 351617 [details]
Modified policy module that actually works

Comment 11 Ben Webb 2009-07-14 15:53:01 UTC
(In reply to comment #7)
> You can add these rules for now using
> 
> # grep kpropd /var/log/audit/audit.log | audit2allow -M mykprop
> # semodule -i mykprop.pp  

I did this just with the last two avcs in the logs (the setfscreate and read of kpropd.acl) and got attachment 351615 [details]. This seems to pretty closely match your patch (attachment 350665 [details]).

However, it doesn't work... Now, I get the following avc on slave propagation:

Jul 14 08:32:52 slave kernel: type=1400 audit(1247585572.614:34): avc:  denied  { open } for  pid=29777 comm="kpropd" name="kpropd.acl" dev=sdb2 ino=12064 scontext=unconfined_u:system_r:kpropd_t:s0 tcontext=unconfined_u:object_r:krb5kdc_conf_t:s0 tclass=file

So I added that to my audit2allow invocation and got attachment 351617 [details]. Now everything works correctly. Perhaps your policy also needs to be modified to allow the {open}?

Comment 12 Bug Zapper 2010-04-27 14:50:58 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  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 '11'.

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 11'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 11 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

Comment 13 Bug Zapper 2010-06-28 12:57:15 UTC
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


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