Bug 461489 - MLS policy: kerberos warning on start, can't stop
MLS policy: kerberos warning on start, can't stop
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-mls (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-08 10:36 EDT by Robert Story
Modified: 2009-06-10 07:15 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-10 07:15:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
avcs, error msgs, policy (11.37 KB, text/plain)
2008-11-04 16:04 EST, Robert Story
no flags Details

  None (edit)
Description Robert Story 2008-09-08 10:36:08 EDT
Description of problem:
when starting kadmin with MLS enforcing policy, an error is logged:

# run_init service kadmin start
Authenticating root.
Password:
Extracting kadm5 Service Keys: Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local: Permission denied while initializing kadmin.local interface
Authenticating as principal root/admin@EXAMPLE.COM with password.D]

after that, attempting to stop kadmin fails.

Version-Release number of selected component (if applicable):
selinux-policy-mls-3.3.1-84.fc9.noarch

How reproducible:
first run

Steps to Reproduce:
1. install/configure kerberos (create db, admin user)
2. run_init service kadmin start
3. run_init service kadmin stop
  
Actual results:
error when starting, but kadmin starts. stopping fails.

Expected results:
no error

Additional info:
1) avcs when starting:
type=AVC msg=audit(1220868133.160:428): avc:  denied  { read } for  pid=2347 comm="kadmin.local" name="principal" dev=dm-0 ino=89442 scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023 tcontext=system_u:object_r:krb5kdc_principal_t:s0 tclass=file
type=AVC msg=audit(1220868133.188:429): avc:  denied  { read } for  pid=2349 comm="kadmin.local" name="principal" dev=dm-0 ino=89442 scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023 tcontext=system_u:object_r:krb5kdc_principal_t:s0 tclass=file

2) avcs when stopping: NONE, until after 'semodule -DB'. Minimal fix seems to be allowing ptrace:

module kadmin 1.0.0;

require {
        type initrc_t;
        type kadmind_t;
        type krb5kdc_t;
        class process ptrace;
}

#============= initrc_t ==============
allow initrc_t kadmind_t:process ptrace;
allow initrc_t krb5kdc_t:process ptrace;


3) Merging the ptrace fix with the audit2allow for the read failures gets us to:

module kadmin 1.0.1;

require {
        type krb5kdc_principal_t;
        type initrc_t;
        type kadmind_t;
        type krb5kdc_t;
        class file read;
        class process ptrace;
}

#============= initrc_t ==============
allow initrc_t krb5kdc_principal_t:file read;
allow initrc_t kadmind_t:process ptrace;
allow initrc_t krb5kdc_t:process ptrace;

This still results in the permission denied error.

3) running the failed command by hand creates the file, and then service start works fine:

# /usr/kerberos/sbin/kadmin.local -q 'ktadd -k /var/kerberos/krb5kdc/kadm5.keytab kadmin/keymaster.example.com'
Authenticating as principal root/admin@EXAMPLE.COM with password.
Entry for principal kadmin/keymaster.example.com with kvno 5, encryption type [...]

# ll -Z /var/kerberos/krb5kdc/kadm5.keytab
-rw-------  root root system_u:object_r:krb5kdc_conf_t:s0 /var/kerberos/krb5kdc/kadm5.keytab
Comment 1 Daniel Walsh 2008-09-08 11:39:40 EDT
I think for this case we need to label kadmin.local as kadmin_exec_t
chcon -t kadmind_exec_t /usr/kerberos/sbin/kadmin.local

We probably need to then allow sysadm_t to exec kadmind_exec_t

Which should fix the problem.

Fixed in selinux-policy-3.3.1-89.fc9.noarch
Comment 2 Robert Story 2008-10-16 13:02:18 EDT
As of selinux-policy-3.3.1-95.fc9.noarch, 'run_init service X stop' still fails for X = krb5kdc and kadmin.
Comment 3 Daniel Walsh 2008-10-16 16:53:32 EDT
What avc's are you seeing?
Comment 4 Robert Story 2008-10-16 18:53:33 EDT
none.. the ptrace avc seems to be don't audited... Note that this problem also exists for all the nfs processes (as reported in bz#467300), and after a 'semodule -DB' there are a bunch (30+) of these when trying to stop the services:

type=AVC msg=audit(1224197436.434:1003): avc:  denied  { ptrace } for  pid=2370 comm="pidof" scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023 tcontext=system_u:system_r:gssd_t:s0-s15:c0.c1023 tclass=process

The avcs for kerberos were similar...
Comment 5 Daniel Walsh 2008-10-20 14:27:38 EDT
If you add

domain_ptrace_all_domains(initrc_t)


Does everything work?
Comment 6 Daniel Walsh 2008-10-20 14:30:38 EDT
Fixed in selinux-policy-3.3.1-103.fc9.noarch
Comment 7 Robert Story 2008-11-04 16:04:58 EST
Created attachment 322485 [details]
avcs, error msgs, policy

we are getting closer... the normal start/stop now work, except for the initial start when it creates the keytab... see the attached file for the errors, avcs (with semodule -db), and the resulting policy that works... I did prune out some of the rules that audit2allow created.. and starting krb5kdc still wants to write to kdc.conf, but seems to work without that permission..

whoops.. just notices 2 more avcs not in the attachment thay may also need fixes.. especially the lock file one:

type=AVC msg=audit(1225817861.960:341): avc:  denied  { write } for  pid=2133 comm="krb5kdc" name="principal.ok" dev=dm-0 ino=89467 scontext=system_u:system_r:krb5kdc_t:s0-s15:c0.c1023 tcontext=root:object_r:krb5kdc_conf_t:s0 tclass=file
type=AVC msg=audit(1225817861.961:342): avc:  denied  { write } for  pid=2133 comm="krb5kdc" name="principal.kadm5.lock" dev=dm-0 ino=89470 scontext=system_u:system_r:krb5kdc_t:s0-s15:c0.c1023 tcontext=system_u:object_r:krb5kdc_principal_t:s0 tclass=file
Comment 8 Daniel Walsh 2008-11-05 09:51:17 EST
Could you try selinux-policy-3.3.1-107.fc9 

The two avc's above are dontaudited there although I would have thought they would be dontaudited in 103.  I don't have an MLS F9 machine but changing this to mcs it tells me they would be dontaudited.

If you run the avc's through audit2why what does it say?
Comment 9 Robert Story 2008-11-07 13:17:33 EST
I think those avc were dontaudited, but i had run semodule -db.. It just seemed to me that interfering with an applications locking scheme might cause trouble.. Anyhoo, after an update to 107 from testing:

root@sefos ~]# run_init service kadmin start
Authenticating root.
Password:
Extracting kadm5 Service Keys: Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local: Insufficient access to lock database while changing kadmin/admin's key
kadmin.local: Insufficient access to lock database while changing kadmin/changepw's key
Authenticating as principal root/admin@EXAMPLE.COM with password. ]

no avcs until semodule -DB, where I get exactly the same avcs as the the first section of the above attachment... failed writes to kdc.conf, krb5.conf and principal.ok.

After allowing the write to principal.ok, I get failed creates for kadm5.keytab, as seen in the second set of avcs in the above attachement.
Comment 10 Daniel Walsh 2008-11-10 11:21:52 EST
restorecon -R /etc/krb5kdc

principal.* should be labeled krb5kdc_principal_t?

/etc/krb5kdc/principal.*		gen_context(system_u:object_r:krb5kdc_principal_t,s0)
Comment 11 Daniel Walsh 2008-11-10 11:25:06 EST
/var/kerberos/krb5kdc/principal.*	gen_context(system_u:object_r:krb5kdc_principal_t,s0)
/var/kerberos/krb5kdc/principal\.ok	gen_context(system_u:object_r:krb5kdc_lock_t,s0)
Comment 12 Robert Story 2008-11-10 12:54:13 EST
[root@sefos ~]# ll -Z /var/kerberos/krb5kdc/
-rw-r--r--  root root system_u:object_r:krb5kdc_conf_t:s0 kadm5.acl
-rw-r--r--  root root system_u:object_r:krb5kdc_conf_t:s0 kdc.conf
-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 root:object_r:krb5kdc_conf_t:s0  principal.ok

[root@sefos ~]# restorecon -R -v /var/kerberos/krb5kdc/
restorecon reset /var/kerberos/krb5kdc/principal.ok context root:object_r:krb5kdc_conf_t:s0->system_u:object_r:krb5kdc_lock_t:s0

[root@sefos ~]# run_init service kadmin start
Extracting kadm5 Service Keys: Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local: No such file or directory while adding key to keytab
kadmin.local: No such file or directory while adding key to keytab
Authenticating as principal root/admin@EXAMPLE.COM with password. ]
                                                           [  OK  ]
Starting Kerberos 5 Admin Server:                          [  OK  ]

[root@sefos ~]# newaudit
*** /tmp/newaudit       2008-11-10 08:52:22.000000000 -0500
--- /tmp/newaudit.new   2008-11-10 08:53:19.000000000 -0500
***************
*** 598 ****
--- 599,600 ----
+ type=AVC msg=audit(1226325148.806:251): avc:  denied  { create } for  pid=2026 comm="kadmin.local" name="kadm5.keytab" scontext=system_u:system_r:kadmind_t:s0-s15:c0.c1023 tcontext=system_u:object_r:krb5kdc_conf_t:s0 tclass=file
+ type=AVC msg=audit(1226325148.823:252): avc:  denied  { create } for  pid=2026 comm="kadmin.local" name="kadm5.keytab" scontext=system_u:system_r:kadmind_t:s0-s15:c0.c1023 tcontext=system_u:object_r:krb5kdc_conf_t:s0 tclass=file


so, the restorecon helps with the lock, but not the keytab. but why does the lock file orignall get created with the wrong context? maybe the rpm should create it with the right context on install?
Comment 13 Daniel Walsh 2008-11-10 14:50:59 EST
Ok the label on 
kadm5.keytab is wrong.

If you chcon -t krb5_keytab_t /var/kerberos/krb5kdc/kadm5.keytab 

Does it work?
Comment 14 Robert Story 2008-11-10 15:17:00 EST
[root@sefos ~]# chcon -t krb5_keytab_t /var/kerberos/krb5kdc/kadm5.keytab
chcon: cannot access `/var/kerberos/krb5kdc/kadm5.keytab': No such file or directory

[root@sefos ~]# touch /var/kerberos/krb5kdc/kadm5.keytab
[root@sefos ~]# chcon -t krb5_keytab_t /var/kerberos/krb5kdc/kadm5.keytab
[root@sefos ~]# run_init service kadmin restart
Authenticating root.
Password:
Stopping Kerberos 5 Admin Server:                          [  OK  ]
Starting Kerberos 5 Admin Server:                          [  OK  ]
Comment 15 Daniel Walsh 2008-11-14 15:40:02 EST
COuld you check out selinux-policy-3.3.1-110.fc9
Comment 16 Robert Story 2008-11-18 12:55:33 EST
Sure. I get the 'Insufficient access to lock database' error on start, probably because principal.ok was created with the old policy. After a restorecon on /var/kerberos,  I get the 'No such file or directory while adding key to keytab' error and these avcs:

+ type=AVC msg=audit(1227016314.369:527): avc:  denied  { create } for  pid=2852 comm="kadmin.local" name="kadm5.keytab" scontext=system_u:system_r:kadmind_t:s0-s15:c0.c1023 tcontext=system_u:object_r:krb5kdc_conf_t:s0 tclass=file
+ type=AVC msg=audit(1227016314.390:528): avc:  denied  { create } for  pid=2852 comm="kadmin.local" name="kadm5.keytab" scontext=system_u:system_r:kadmind_t:s0-s15:c0.c1023 tcontext=system_u:object_r:krb5kdc_conf_t:s0 tclass=file
Comment 17 Bug Zapper 2009-06-09 22:39:43 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  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 '9'.

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 9'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 9 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.