Description of problem: ipa-server-install generates certmonger related AVCs. There are no obvious errors, but the AVCs are concerning. # ipa-server-install # ausearch -m AVC -ts today | audit2allow #============= certmonger_t ============== #!!!! This avc can be allowed using the boolean 'authlogin_nsswitch_use_ldap' allow certmonger_t dirsrv_var_run_t:sock_file write; allow certmonger_t ldconfig_exec_t:file { execute getattr }; I will also attach full audit.log from ipa-server-install. Version-Release number of selected component (if applicable): freeipa-server-4.0.0GIT3e64386-0.fc20.x86_64 certmonger-0.75.6-1.fc20.x86_64 selinux-policy-3.12.1-177.fc20.noarch How reproducible: Always Steps to Reproduce: 1. Install freeipa-server package 2. Run ipa-server-install Actual results: Server installs, AVCs are logged Expected results: Server installs, no AVCs are logged Additional info:
Created attachment 919943 [details] audit.log
Nalin, was there any functional change in certmonger in Fedora 20 that would warrant these AVCs? Should they be allowed in default policy?
Uh, no, there wasn't. Most of the denials are coming from commands that we must be invoking 'dogtag-ipa-ca-r' (the name appears to have been truncated) and 'sh'. It looks like commands that we're having certmonger invoke via its pre-save/post-save hook functionality aren't labeled in such a way that certmonger executing them causes them to be run in a domain which would be allowed to do these things. As a starting point, after the installation completes in permissive mode, I'd suggest checking the output of 'getcert list', locating the commands which are invoked, and checking the labels of the binaries. There's one call to ipa-submit which I can't explain in this way, though, since when the daemon invokes ipa-submit, it should only be passed descriptors to /dev/null for stdin/stderr and a pipe to the certmonger daemon for stdout.
I tried installing FreeIPA in a permissive mode, listing all certificates and tried to resubmit them. All certificates using /usr/lib64/ipa/certmonger/renew_ra_cert or /usr/lib64/ipa/certmonger/renew_ca_cert caused AVCs (even one more not mentioned in Description): # getcert list -i 20140723081902 Number of certificates and requests being tracked: 7. Request ID '20140723081902': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=MKOSEK-FEDORA20.TEST subject: CN=IPA RA,O=MKOSEK-FEDORA20.TEST expires: 2016-07-12 08:45:28 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes # getcert resubmit -i 20140723081902 Resubmitting "20140723081902" to "dogtag-ipa-ca-renew-agent". audit.log: type=AVC msg=audit(1406105125.964:2274): avc: denied { execute } for pid=24382 comm="sh" name="ldconfig" dev="dm-0" ino=133760 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file type=AVC msg=audit(1406105125.964:2274): avc: denied { read open } for pid=24382 comm="sh" path="/usr/sbin/ldconfig" dev="dm-0" ino=133760 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file type=AVC msg=audit(1406105125.964:2274): avc: denied { execute_no_trans } for pid=24382 comm="sh" path="/usr/sbin/ldconfig" dev="dm-0" ino=133760 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file type=SYSCALL msg=audit(1406105125.964:2274): arch=c000003e syscall=59 success=yes exit=0 a0=e43bf0 a1=e43cf0 a2=e41d00 a3=7fff03bf2860 items=0 ppid=24381 pid=24382 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ldconfig" exe="/usr/sbin/ldconfig" subj=system_u:system_r:certmonger_t:s0 key=(null) type=PROCTITLE msg=audit(1406105125.964:2274): proctitle=2F7362696E2F6C64636F6E666967002D70 type=AVC msg=audit(1406105127.701:2275): avc: denied { write } for pid=24380 comm="dogtag-ipa-ca-r" name="slapd-MKOSEK-FEDORA20-TEST.socket" dev="tmpfs" ino=648462 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:dirsrv_var_run_t:s0 tclass=sock_file type=AVC msg=audit(1406105127.701:2275): avc: denied { connectto } for pid=24380 comm="dogtag-ipa-ca-r" path="/run/slapd-MKOSEK-FEDORA20-TEST.socket" scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:system_r:dirsrv_t:s0 tclass=unix_stream_socket type=SYSCALL msg=audit(1406105127.701:2275): arch=c000003e syscall=42 success=yes exit=0 a0=4 a1=7fff1b95d0c0 a2=6e a3=7fff1b95d0c2 items=0 ppid=22930 pid=24380 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dogtag-ipa-ca-r" exe="/usr/bin/python2.7" subj=system_u:system_r:certmonger_t:s0 key=(null) type=PROCTITLE msg=audit(1406105127.701:2275): proctitle=2F7573722F62696E2F707974686F6E32002D45002F7573722F6C6962657865632F636572746D6F6E6765722F646F677461672D6970612D63612D72656E65772D6167656E742D7375626D6974 type=SERVICE_START msg=audit(1406105140.541:2276): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=' comm="httpd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' type=SERVICE_STOP msg=audit(1406105140.541:2277): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=' comm="httpd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' type=SERVICE_START msg=audit(1406105141.110:2278): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=' comm="httpd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' # ausearch -m avc -ts today | audit2allow #============= certmonger_t ============== #!!!! This avc can be allowed using one of the these booleans: # authlogin_nsswitch_use_ldap, daemons_enable_cluster_mode allow certmonger_t dirsrv_t:unix_stream_socket connectto; #!!!! This avc can be allowed using the boolean 'authlogin_nsswitch_use_ldap' allow certmonger_t dirsrv_var_run_t:sock_file write; allow certmonger_t ldconfig_exec_t:file { read execute open getattr execute_no_trans }; These pre-save/post-save files are owned by freeipa-server package and have certmonger_unconfined_exec_t file context: # ls -Zl /usr/lib64/ipa/certmonger/ total 20 -rwxr-xr-x. 1 system_u:object_r:certmonger_unconfined_exec_t:s0 root root 4000 Jun 23 16:08 renew_ca_cert -rwxr-xr-x. 1 system_u:object_r:certmonger_unconfined_exec_t:s0 root root 1946 Jun 23 16:08 renew_ra_cert -rwxr-xr-x. 1 system_u:object_r:certmonger_unconfined_exec_t:s0 root root 1435 Jun 23 16:08 restart_dirsrv -rwxr-xr-x. 1 system_u:object_r:certmonger_unconfined_exec_t:s0 root root 1193 Jun 23 16:08 restart_httpd -rwxr-xr-x. 1 system_u:object_r:certmonger_unconfined_exec_t:s0 root root 1667 Jun 23 16:08 stop_pkicad Does the problem root in a fact that scripts are run with certmonger_t context and not with certmonger_unconfined_exec_t context?
So these AVCs are caused by files which are executed by certmonger and located in /usr/lib64/ipa/certmonger/. If you we should have them running with certmonger_unconfined_t.
Correct. These scripts connect to FreeIPA LDAP server instance to do necessary updates due to pre- certificate submission or post- certificate submission tasks or read from PKI/HTTPD NSS database. There are also tasks to stop/start/restart Directory Server, web server or PKI. I wonder why those are allowed by SELinux policy as it is IMO much more serious task than just connecting to LDAP. I think they should run either with some unconfined context or with some FreeIPA context allowing these actions as these files are indeed owned by FreeIPA and not certmonger.
(In reply to Nalin Dahyabhai from comment #3) > Uh, no, there wasn't. Most of the denials are coming from commands that we > must be invoking 'dogtag-ipa-ca-r' (the name appears to have been truncated) > and 'sh'. It's "dogtag-ipa-ca-renew-agent-submit". It accesses the ldapi socket, which causes the denials. I have a patch for IPA 4.1, which was originally planned for 4.0, which fixes this, but it hasn't been pushed yet. > There's one call to ipa-submit which I can't explain in this way, though, > since when the daemon invokes ipa-submit, it should only be passed > descriptors to /dev/null for stdin/stderr and a pipe to the certmonger > daemon for stdout. This is because ipa-submit accesses the ldapi socket as well, when it is handling the FETCH-ROOTS operation. The ldap URL is read from /etc/ipa/default.conf and on IPA servers it points to the ldapi socket.
(In reply to Jan Cholasta from comment #7) > (In reply to Nalin Dahyabhai from comment #3) > > Uh, no, there wasn't. Most of the denials are coming from commands that we > > must be invoking 'dogtag-ipa-ca-r' (the name appears to have been truncated) > > and 'sh'. > > It's "dogtag-ipa-ca-renew-agent-submit". It accesses the ldapi socket, which > causes the denials. I have a patch for IPA 4.1, which was originally planned > for 4.0, which fixes this, but it hasn't been pushed yet. Do you mean to change how it connects to the server, a patch for policy to change the label it gets in its current location, or to move it to /usr/lib(64)?/ipa/certmonger, where it'll default to being labeled certmonger_unconfined_exec_t? > > There's one call to ipa-submit which I can't explain in this way, though, > > since when the daemon invokes ipa-submit, it should only be passed > > descriptors to /dev/null for stdin/stderr and a pipe to the certmonger > > daemon for stdout. > > This is because ipa-submit accesses the ldapi socket as well, when it is > handling the FETCH-ROOTS operation. The ldap URL is read from > /etc/ipa/default.conf and on IPA servers it points to the ldapi socket. Ah, thanks for clearing that up. I think we're going to have to let certmonger_t communicate with dirsrv_var_run_t sock_files in the policy, since I don't think it needs to be granted any other privileges beyond what it could do previously.
(In reply to Nalin Dahyabhai from comment #8) > (In reply to Jan Cholasta from comment #7) > > (In reply to Nalin Dahyabhai from comment #3) > > > Uh, no, there wasn't. Most of the denials are coming from commands that we > > > must be invoking 'dogtag-ipa-ca-r' (the name appears to have been truncated) > > > and 'sh'. > > > > It's "dogtag-ipa-ca-renew-agent-submit". It accesses the ldapi socket, which > > causes the denials. I have a patch for IPA 4.1, which was originally planned > > for 4.0, which fixes this, but it hasn't been pushed yet. > > Do you mean to change how it connects to the server, a patch for policy to > change the label it gets in its current location, or to move it to > /usr/lib(64)?/ipa/certmonger, where it'll default to being labeled > certmonger_unconfined_exec_t? It changes how it connects to the server. The ldapi access is a side effect of other change and the patch fixes that. > > > > There's one call to ipa-submit which I can't explain in this way, though, > > > since when the daemon invokes ipa-submit, it should only be passed > > > descriptors to /dev/null for stdin/stderr and a pipe to the certmonger > > > daemon for stdout. > > > > This is because ipa-submit accesses the ldapi socket as well, when it is > > handling the FETCH-ROOTS operation. The ldap URL is read from > > /etc/ipa/default.conf and on IPA servers it points to the ldapi socket. > > Ah, thanks for clearing that up. I think we're going to have to let > certmonger_t communicate with dirsrv_var_run_t sock_files in the policy, > since I don't think it needs to be granted any other privileges beyond what > it could do previously. I agree.
selinux-policy-3.12.1-179.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-179.fc20
I tested new selinux-policy, but the problem seems to be still not resolved: # rpm -q selinux-policy selinux-policy-3.12.1-179.fc20.noarch # ipa-server-install # ausearch -m avc -ts today ---- time->Fri Jul 25 00:00:49 2014 type=PROCTITLE msg=audit(1406239249.154:2965): proctitle=2F7573722F62696E2F707974686F6E32002D45002F7573722F6C6962657865632F636572746D6F6E6765722F646F677461672D6970612D63612D72656E65772D6167656E742D7375626D6974 type=SYSCALL msg=audit(1406239249.154:2965): arch=c000003e syscall=42 success=no exit=-13 a0=4 a1=7fff8c1672c0 a2=6e a3=7fff8c1672c2 items=0 ppid=26625 pid=26666 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dogtag-ipa-ca-r" exe="/usr/bin/python2.7" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1406239249.154:2965): avc: denied { write } for pid=26666 comm="dogtag-ipa-ca-r" name="slapd-MKOSEK-FEDORA20-TEST.socket" dev="tmpfs" ino=1547724 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:dirsrv_var_run_t:s0 tclass=sock_file ---- time->Fri Jul 25 00:00:49 2014 type=PROCTITLE msg=audit(1406239249.172:2966): proctitle=2F7573722F62696E2F707974686F6E32002D45002F7573722F6C6962657865632F636572746D6F6E6765722F646F677461672D6970612D63612D72656E65772D6167656E742D7375626D6974 type=SYSCALL msg=audit(1406239249.172:2966): arch=c000003e syscall=42 success=no exit=-13 a0=4 a1=7fff8c167850 a2=2c a3=0 items=0 ppid=26625 pid=26666 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dogtag-ipa-ca-r" exe="/usr/bin/python2.7" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1406239249.172:2966): avc: denied { write } for pid=26666 comm="dogtag-ipa-ca-r" name="slapd-MKOSEK-FEDORA20-TEST.socket" dev="tmpfs" ino=1547724 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:dirsrv_var_run_t:s0 tclass=sock_file ---- time->Fri Jul 25 00:00:49 2014 type=PROCTITLE msg=audit(1406239249.399:2967): proctitle=2F7573722F62696E2F707974686F6E32002D45002F7573722F6C6962657865632F636572746D6F6E6765722F646F677461672D6970612D63612D72656E65772D6167656E742D7375626D6974 type=SYSCALL msg=audit(1406239249.399:2967): arch=c000003e syscall=42 success=no exit=-13 a0=4 a1=7fff8d4006e0 a2=6e a3=7fff8d4006e2 items=0 ppid=26625 pid=26664 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dogtag-ipa-ca-r" exe="/usr/bin/python2.7" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1406239249.399:2967): avc: denied { write } for pid=26664 comm="dogtag-ipa-ca-r" name="slapd-MKOSEK-FEDORA20-TEST.socket" dev="tmpfs" ino=1547724 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:dirsrv_var_run_t:s0 tclass=sock_file ---- ... # ausearch -m avc -ts today | audit2allow #============= certmonger_t ============== #!!!! This avc can be allowed using the boolean 'authlogin_nsswitch_use_ldap' allow certmonger_t dirsrv_var_run_t:sock_file write;
Added to updates by mistake. It's not fixed.
So it is not caused by a scripta located in /usr/lib64/ipa/certmonger/.
As Jan and Nalin mentioned in Comments 7-9, this may not be caused by the pre/post callbacks after all, but rather by /usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit: # ls -laZ /usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit Which is also being run by certmonger. As Jan commented, this should be addressed in later FreeIPA 4.1 versions, but for now, we should allow certmonger_t to communicate with DS via socket in the default policy as agreed in Comment 9. JFTR, this are the policy changes identified during investigation: # ausearch -m avc -ts today | audit2allow #============= certmonger_t ============== #!!!! This avc can be allowed using one of the these booleans: # authlogin_nsswitch_use_ldap, daemons_enable_cluster_mode allow certmonger_t dirsrv_t:unix_stream_socket connectto; #!!!! This avc can be allowed using the boolean 'authlogin_nsswitch_use_ldap' allow certmonger_t dirsrv_var_run_t:sock_file write; allow certmonger_t ldconfig_exec_t:file { read execute open getattr execute_no_trans };
commit 7caf77f74d64525c70d67b1e5214e1f76e8a93c0 Author: Miroslav Grepl <mgrepl> Date: Fri Jul 25 11:00:59 2014 +0200 Allow certmonger to stream connect to dirsrv to make ipa-server-install working. commit a9b3b5af79cb795651cbea5e06bdb225f1365923 Author: Miroslav Grepl <mgrepl> Date: Wed Jul 23 11:36:00 2014 +0200 Allow certmonger to exec ldconfig to make ipa-server-install working. (#1122110)
Package selinux-policy-3.12.1-179.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-179.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-8830/selinux-policy-3.12.1-179.fc20 then log in and leave karma (feedback).
selinux-policy-3.12.1-179.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.