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 with password. kadmin.local: Permission denied while initializing kadmin.local interface Authenticating as principal root/admin 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 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
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
As of selinux-policy-3.3.1-95.fc9.noarch, 'run_init service X stop' still fails for X = krb5kdc and kadmin.
What avc's are you seeing?
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...
If you add domain_ptrace_all_domains(initrc_t) Does everything work?
Fixed in selinux-policy-3.3.1-103.fc9.noarch
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
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?
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 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 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.
restorecon -R /etc/krb5kdc principal.* should be labeled krb5kdc_principal_t? /etc/krb5kdc/principal.* gen_context(system_u:object_r:krb5kdc_principal_t,s0)
/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)
[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 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 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?
Ok the label on kadm5.keytab is wrong. If you chcon -t krb5_keytab_t /var/kerberos/krb5kdc/kadm5.keytab Does it work?
[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 ]
COuld you check out selinux-policy-3.3.1-110.fc9
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
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