Description of problem: When ipa-client-install --request-cert is run, it fails to retrieve the host certificate. Version-Release number of selected component (if applicable): ipa-server-4.2.0-9.el7.x86_64 ipa-client-4.2.0-9.el7.x86_64 The same output with RHEL 7.1 client as well: ipa-client-4.1.0-18.el7.x86_64 How reproducible: Tried once. Steps to Reproduce: 1. Install IdM server, ipa-server-4.2.0-9.el7.x86_64. 2. On another machine, install IPA client, tried with ipa-client-4.2.0-9.el7.x86_64 and ipa-client-4.1.0-18.el7.x86_64. 3. On the client, run ipa-client-install --server ipa.example.test --domain testrelm.test --request-cert Actual results: ipa-client-passes but /var/log/ipaclient-install.log says 2015-09-14T07:44:30Z ERROR certmonger request for host certificate failed and IdM for that host says Host Certificate Certificate: No Valid Certificate Also, # certutil -d /etc/ipa/nssdb -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI TESTRELM.TEST IPA CA CT,C,C Expected results: Based on man ipa-client-install, --request-cert Request certificate for the machine. The certificate will be stored in /etc/ipa/nssdb under the nickname "Local IPA host". So that certutil -L should list "Local IPA host". Additional info: First pointed out at https://www.redhat.com/archives/freeipa-users/2015-September/msg00163.html
Nothing interesting in server's /var/log/httpd/error_log.
Upstream ticket: https://fedorahosted.org/freeipa/ticket/5299
SELinux denies certmonger's attempt to write into /etc/ipa/nssdb directory. # getcert request -d /etc/ipa/nssdb/ -n "Local IPA host" -p /etc/ipa/nssdb/pwdfile.txt -N CN=`hostname -f`,O=TESTRELM.TEST -K host/`hostname -f`@TESTRELM.TEST The location "/etc/ipa/nssdb" could not be accessed due to insufficient permissions. ausearch -m avc type=SYSCALL msg=audit(1442301601.092:369): arch=c000003e syscall=21 success=no exit=-13 a0=7f794de97a70 a1=6 a2=4000 a3=fffffffffffffa08 items=0 ppid=1 pid=31420 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="certmonger" exe="/usr/sbin/certmonger" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1442301601.092:369): avc: denied { write } for pid=31420 comm="certmonger" name="nssdb" dev="dm-0" ino=135790237 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir Should we change the component to SELinux then?
Could you switch SELinux to permissive mode, re-test your scenario and collect SELinux denials? # ausearch -m avc -m user_avc -m selinux_err -i -ts recent
# ausearch -m avc -m user_avc -m selinux_err -i -ts recent ---- type=SYSCALL msg=audit(15/09/15 04:28:04.604:418) : arch=x86_64 syscall=open success=yes exit=11 a0=0x7f794dee04e0 a1=O_RDWR a2=0x180 a3=0x0 items=0 ppid=31420 pid=31744 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=certmonger exe=/usr/sbin/certmonger subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(15/09/15 04:28:04.604:418) : avc: denied { write } for pid=31744 comm=certmonger name=cert8.db dev="dm-0" ino=135790588 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file ---- type=SYSCALL msg=audit(15/09/15 04:28:04.525:417) : arch=x86_64 syscall=access success=yes exit=0 a0=0x7f794de97d30 a1=W_OK|R_OK a2=0x4000 a3=0x7f794992cd10 items=0 ppid=1 pid=31420 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=certmonger exe=/usr/sbin/certmonger subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(15/09/15 04:28:04.525:417) : avc: denied { write } for pid=31420 comm=certmonger name=nssdb dev="dm-0" ino=135790237 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir
Making comment 7 public. We shouldn't throw the bugzilla to SELinux team without being specific about what is asked here. To me it looks like the directory / file should have some reasonable label because we do not want certmonger to be able to write to any etc_t file -- in permissive, the AVC denials are type=AVC msg=audit(1442305539.621:284): avc: denied { write } for pid=31250 comm="certmonger" name="nssdb" dev="dm-0" ino=203258330 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir type=AVC msg=audit(1442305539.669:285): avc: denied { write } for pid=31288 comm="certmonger" name="cert8.db" dev="dm-0" ino=201919129 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file so it's not just the write to directory which is at stake here. What do we propose?
FWIW, /etc/pki/nssdb/ has cert_t. But I'm not sure what this label on /etc/ipa/nssdb would break.
I believe that cert_t is appropriate label for /etc/ipa/nssdb directory and everything that's inside.
Ok this is about a new labeling for /etc/ipa/nssdb. If /etc/ipa/nssdb is owned by a package, I agree cert_t is a correct labeling. Basically etc_t is read-only SELinu type so we should not break anything. To be sure, what does rpm -qf /etc/ipa/nssdb
$ rpm -qf /etc/ipa/nssdb/ ipa-python-4.1.0-18.el7_1.4.x86_64
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-2300.html