Hide Forgot
Part of the fix for bug #766167 requires that we start allowing certmonger_t to do more than it's currently allowed to do. As a starting point, I set certmonger to run this script (/tmp/idlog) when it saved a certificate: #!/bin/sh logger `id` A sample run with certmonger 0.54 or later would go something like this: mkdir /tmp/certs chcon -t cert_t /tmp/certs getcert request -c SelfSign -C /tmp/idlog -k /tmp/certs/key -f /tmp/certs/cert When I did this in permissive mode, these are the AVC denials I saw when the script was run: ---- time->Wed Feb 15 14:56:52 2012 type=SYSCALL msg=audit(1329335812.534:44466): arch=c000003e syscall=42 success=yes exit=0 a0=9 a1=7fffe1a136b0 a2=6e a3=7fffe1a13340 items=0 ppid=31006 pid=31016 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3409 comm="certmonger" exe="/usr/sbin/certmonger" subj=unconfined_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1329335812.534:44466): avc: denied { write } for pid=31016 comm="certmonger" name="nss" dev=dm-0 ino=396265 scontext=unconfined_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:sssd_var_lib_t:s0 tclass=sock_file ---- The daemon needs to be able to look up information about a user based on their UID, and to then retrieve the list of supplemental groups for the user. ---- time->Wed Feb 15 14:56:52 2012 type=SYSCALL msg=audit(1329335812.533:44465): arch=c000003e syscall=2 success=yes exit=9 a0=3a2696333a a1=0 a2=ffffffffffffff40 a3=7fffe1a13650 items=0 ppid=31006 pid=31016 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3409 comm="certmonger" exe="/usr/sbin/certmonger" subj=unconfined_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1329335812.533:44465): avc: denied { read } for pid=31016 comm="certmonger" scontext=unconfined_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=file type=AVC msg=audit(1329335812.533:44465): avc: denied { search } for pid=31016 comm="certmonger" scontext=unconfined_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir ---- I'm not really sure what this one is. ---- time->Wed Feb 15 14:56:52 2012 type=SYSCALL msg=audit(1329335812.536:44467): arch=c000003e syscall=116 success=yes exit=0 a0=1 a1=8c2980 a2=10000 a3=1 items=0 ppid=31006 pid=31016 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3409 comm="certmonger" exe="/usr/sbin/certmonger" subj=unconfined_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1329335812.536:44467): avc: denied { setgid } for pid=31016 comm="certmonger" capability=6 scontext=unconfined_u:system_r:certmonger_t:s0 tcontext=unconfined_u:system_r:certmonger_t:s0 tclass=capability ---- The daemon calls setregid() (and initgroups(), though I'm not certain the latter it maps to the same access). ---- time->Wed Feb 15 14:56:52 2012 type=SYSCALL msg=audit(1329335812.536:44468): arch=c000003e syscall=113 success=yes exit=0 a0=1f1 a1=1f1 a2=ca a3=7fffe1a13650 items=0 ppid=31006 pid=31016 auid=0 uid=497 gid=495 euid=497 suid=497 fsuid=497 egid=495 sgid=495 fsgid=495 tty=(none) ses=3409 comm="certmonger" exe="/usr/sbin/certmonger" subj=unconfined_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1329335812.536:44468): avc: denied { setuid } for pid=31016 comm="certmonger" capability=7 scontext=unconfined_u:system_r:certmonger_t:s0 tcontext=unconfined_u:system_r:certmonger_t:s0 tclass=capability ---- The daemon calls setreuid() before exec()ing the specified command. ---- time->Wed Feb 15 14:56:52 2012 type=SYSCALL msg=audit(1329335812.536:44469): arch=c000003e syscall=59 success=yes exit=0 a0=8c2ec0 a1=8c2e50 a2=8b3090 a3=7fffe1a13650 items=0 ppid=31006 pid=31016 auid=0 uid=497 gid=495 euid=497 suid=497 fsuid=497 egid=495 sgid=495 fsgid=495 tty=(none) ses=3409 comm="idlog" exe="/bin/bash" subj=unconfined_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1329335812.536:44469): avc: denied { read open } for pid=31016 comm="certmonger" name="bash" dev=dm-0 ino=786547 scontext=unconfined_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file type=AVC msg=audit(1329335812.536:44469): avc: denied { execute } for pid=31016 comm="certmonger" name="bash" dev=dm-0 ino=786547 scontext=unconfined_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file type=AVC msg=audit(1329335812.536:44469): avc: denied { execute_no_trans } for pid=31016 comm="certmonger" path="/tmp/idlog" dev=dm-0 ino=1074834 scontext=unconfined_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file type=AVC msg=audit(1329335812.536:44469): avc: denied { execute } for pid=31016 comm="certmonger" name="idlog" dev=dm-0 ino=1074834 scontext=unconfined_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file ---- The 'idlog' script was in /tmp at the time. I don't think we're going to be able to define a specific type for commands that the daemon will run, as the point of this feature is to offer a lower barrier of entry than listening for the D-Bus signal that the daemon is also emitting when it goes to run the specified command. ---- time->Wed Feb 15 14:56:52 2012 type=SYSCALL msg=audit(1329335812.537:44470): arch=c000003e syscall=2 success=yes exit=6 a0=3a269636ff a1=0 a2=1b6 a3=2 items=0 ppid=31006 pid=31016 auid=0 uid=497 gid=495 euid=497 suid=497 fsuid=497 egid=495 sgid=495 fsgid=495 tty=(none) ses=3409 comm="idlog" exe="/bin/bash" subj=unconfined_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1329335812.537:44470): avc: denied { open } for pid=31016 comm="idlog" name="meminfo" dev=proc ino=4026532031 scontext=unconfined_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file type=AVC msg=audit(1329335812.537:44470): avc: denied { read } for pid=31016 comm="idlog" name="meminfo" dev=proc ino=4026532031 scontext=unconfined_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file ---- time->Wed Feb 15 14:56:52 2012 type=SYSCALL msg=audit(1329335812.537:44471): arch=c000003e syscall=5 success=yes exit=0 a0=6 a1=7fffde659bd0 a2=7fffde659bd0 a3=2 items=0 ppid=31006 pid=31016 auid=0 uid=497 gid=495 euid=497 suid=497 fsuid=497 egid=495 sgid=495 fsgid=495 tty=(none) ses=3409 comm="idlog" exe="/bin/bash" subj=unconfined_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1329335812.537:44471): avc: denied { getattr } for pid=31016 comm="idlog" path="/proc/meminfo" dev=proc ino=4026532031 scontext=unconfined_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file ---- Yeah... not really sure about these. I can't rule out that the administrator will tell us to run a script.
Ok, if I understand correctly, you can use a script with -C option and this script could be do a lot of staff. For example service httpd reload .. .. as you wrote.
(In reply to comment #1) > Ok, if I understand correctly, you can use a script with -C option and this > script could be do a lot of staff. For example > > service httpd reload > .. > .. > > as you wrote. Well, that's the idea. The command is parsed before we pass it to exec(), so it could just be "/sbin/service httpd reload", so long as it's quoted properly on the command line. That's probably a lot of privilege, though, and I don't know for certain exactly how much we need to start allowing certmonger to do. Adding Rob to the CC list. Rob, do you have a specific example we should be aiming to enable here?
My original intention was to send a signal to a daemon to cause it to reload its configuration and therefore see the updated certs. For example, sending SIGHUP will cause Apache to kill its children, re-load its configuration, and restarts the children. A SIGUSR1 does the same but waits for the children to exit gracefully first (so current connections are not interrupted). I suspect that if this started by supporting only SIGUSR1, SIGUSR2 and SIGHUP that would cover most requirements. Being able to specify a command would be nice for those daemons that don't reload on a signal but yeah, this could be easily abused.
Rob Which daemon httpd_t? Any others?
The other service we definitely handle certs for is 389-ds, so dirsrv_t. certmonger could theoretically manage certificates for any process that supports SSL.
Created attachment 564521 [details] Added this patch to Rawhide Certmonger. I don't want to allow certmonger to execute user_tmp_t, can we move the shell script to some other location?
Then we could do something similar what we have for ABRT event scripts.
Yes if an admin can place any script he wants within a specific directory and certmonger will execute it, then that script has to run as an unconfined domain.
Yes.
(In reply to comment #6) > Created attachment 564521 [details] > Added this patch to Rawhide Certmonger. > > I don't want to allow certmonger to execute user_tmp_t, can we move the shell > script to some other location? The script I was using in my contrived example was in /tmp before I told certmonger to run it. That my logs show certmonger accessing the user_tmp_t file isn't really meaningful, and shouldn't have much bearing on whether or not it should be allowed in the general case.
Yes, as you wrote in the description. But a default directory would be fine. Then admins could place own scripts to this directory.
It seems that since ipa wants this feature we will need to own it, I propose /var/lib/ipa/certmonger. I'll just need to know the context to apply to the directory and/or script(s) that reside there.
How about /usr/lib/ipa/certmonger ?
Added policy for F17, but I think we need a certmonger_script_domain() Interface so that ipa can define domains that certmonger could transition to, if they want to ship scripts to be executed by certmonger.
I'm ok with /usr over /var. We just don't currently create that namespace, no big deal to add it.
It could be test with selinux-policy-3.7.19-141.el6 /usr/lib/ipa/certmonger(/.*)? gen_context(system_u:object_r:certmonger_unconfined_exec_t,s0) so you can create this directory, fix label and test it.
# rpm -q selinux-policy selinux-policy-3.7.19-141.el6.noarch Getting an AVC in operation. I created the directory /usr/lib/ipa/certmonger: drwxr-xr-x. root root unconfined_u:object_r:certmonger_unconfined_exec_t:s0 /usr/lib/ipa/certmonger/ I created a script that just calls /sbin/service restart dirsrv -r-xr--r--. root root unconfined_u:object_r:certmonger_unconfined_exec_t:s0 restart_dirsrv I created an NSS database for certmonger: # mkdir /home/rcrit/mongerdb # cd /home/rcrit/mongerdb # certutil -N -d . # chcon unconfined_u:object_r:cert_t:s0 *.db I issued a request via certmonger: # ipa-getcert request -d /home/rcrit/mongerdb/ -n Server-Cert -C /usr/lib/ipa/certmonger/restart_dirsrv -N "CN=dane.example.com,O=EXAMPLE.COM" -K "imap/dane.example.com" The certificate gets added but the script is not run. I get these AVC: type=AVC msg=audit(1331924239.230:219914): avc: denied { search } for pid=2341 comm="certmonger" scontext=unconfined_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir type=AVC msg=audit(1331924239.244:219915): avc: denied { write } for pid=2341 comm="certmonger" name="nss" dev=sda2 ino=351904 scontext=unconfined_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:sssd_var_lib_t:s0 tclass=sock_file type=AVC msg=audit(1331924239.245:219916): avc: denied { setgid } for pid=2341 comm="certmonger" capability=6 scontext=unconfined_u:system_r:certmonger_t:s0 tcontext=unconfined_u:system_r:certmonger_t:s0 tclass=capability
ok, could you add this policy $ cat mycertmonger.te policy_module(mycertmonger, 1.0) require{ type certmonger_t; type certmonger_unconfined_exec_t; type certmonger_unconfined_t; } domtrans_pattern(certmonger_t, certmonger_unconfined_exec_t, certmonger_unconfined_t) init_domtrans_script(certmonger_unconfined_t) and execute $ make -f /usr/share/selinux/devel/Makefile mycertmonger.pp $ semodule -i mycertmonger.pp
Get these when submitting new cert request (cert is issued): type=AVC msg=audit(1332177266.853:161): avc: denied { search } for pid=3814 comm="certmonger" scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir type=AVC msg=audit(1332177266.857:162): avc: denied { write } for pid=3814 comm="certmonger" name="nss" dev=sda2 ino=351904 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=sock_file type=AVC msg=audit(1332177266.858:163): avc: denied { setgid } for pid=3814 comm="certmonger" capability=6 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:system_r:certmonger_t:s0 tclass=capability
could you also re-test it with $ semodule -d unconfined we should see AVC msgs for certmonger_unconfined_t
# semodule -d unconfined libsepol.print_missing_requirements: mycertmonger's global requirements were not met: type/attribute certmonger_unconfined_t (No such file or directory). libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory). semodule: Failed!
Oops, yes. I see it why you are not able to do it.
(In reply to comment #20) > Get these when submitting new cert request (cert is issued): > > type=AVC msg=audit(1332177266.853:161): avc: denied { search } for pid=3814 > comm="certmonger" scontext=system_u:system_r:certmonger_t:s0 > tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir > type=AVC msg=audit(1332177266.857:162): avc: denied { write } for pid=3814 > comm="certmonger" name="nss" dev=sda2 ino=351904 > scontext=system_u:system_r:certmonger_t:s0 > tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=sock_file > type=AVC msg=audit(1332177266.858:163): avc: denied { setgid } for pid=3814 > comm="certmonger" capability=6 scontext=system_u:system_r:certmonger_t:s0 > tcontext=system_u:system_r:certmonger_t:s0 tclass=capability Looks like these AVC msgs are caused by certmonger if I understand correctly.
Is this certmonger trying to find out what user to run as and calling setgid before trying to execute?
(In reply to comment #25) > Is this certmonger trying to find out what user to run as and calling setgid > before trying to execute? Yes. The daemon needs to be able to look up information about a user based on their UID, and to then retrieve the list of supplemental groups for the user. The daemon calls setregid() (and initgroups(), though I'm not certain the latter it maps to the same access) and setreuid() to assume the user's DAC privileges before attempting to run the specified command.
Ok, I am backporting it from Fedora.
Getting following AVC messages with selinux-policy-3.7.19-142.el6.noarch and Cert is generated successfully AVC messages ============ type=AVC msg=audit(1332317840.867:473): avc: denied { execute } for pid=17688 comm="service" name="consoletype" dev=dm-0 ino=8691 scontext=unconfined_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:consoletype_exec_t:s0 tclass=file type=SYSCALL msg=audit(1332317840.867:473): arch=c000003e syscall=59 success=no exit=-13 a0=7c3be0 a1=7c3c40 a2=7cb5e0 a3=7fff3528de10 items=0 ppid=17687 pid=17688 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=5 comm="service" exe="/bin/bash" subj=unconfined_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1332317840.867:474): avc: denied { getattr } for pid=17688 comm="service" path="/sbin/consoletype" dev=dm-0 ino=8691 scontext=unconfined_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:consoletype_exec_t:s0 tclass=file type=SYSCALL msg=audit(1332317840.867:474): arch=c000003e syscall=4 success=no exit=-13 a0=7c3be0 a1=7fff3528dff0 a2=7fff3528dff0 a3=7fff3528de10 items=0 ppid=17687 pid=17688 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=5 comm="service" exe="/bin/bash" subj=unconfined_u:system_r:certmonger_t:s0 key=(null) selinux-policy version ====================== [root@dhcp201-185 142]# rpm -q selinux-policy selinux-policy-3.7.19-142.el6.noarch [root@dhcp201-185 142]# Cert status =========== [root@dhcp201-185]# getcert request -d /tmp/kaleem -n test -I testing -P redhat -c SelfSign -C "/sbin/service httpd restart" New signing request "testing" added. [root@dhcp201-185]# getcert list Number of certificates and requests being tracked: 1. Request ID 'testing': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/tmp/kaleem',nickname='test',token='NSS Certificate DB',pin='redhat' certificate: type=NSSDB,location='/tmp/kaleem',nickname='test',token='NSS Certificate DB' CA: SelfSign issuer: CN=dhcp201-185.englab.pnq.redhat.com subject: CN=dhcp201-185.englab.pnq.redhat.com expires: 2013-03-21 08:17:20 UTC dns: dhcp201-185.englab.pnq.redhat.com principal name: host/dhcp201-185.englab.pnq.redhat.com eku: id-kp-serverAuth command: /sbin/service httpd restart track: yes auto-renew: yes
Could you please test it with selinux-policy-3.7.19-143.el6 which is now building. This release also contains domtrans_pattern(certmonger_t, certmonger_unconfined_exec_t, certmonger_unconfined_t) rule. Also please make sure the /usr/lib/ipa/certmonger/ directory is labeled correctly with the certmonger_unconfined_exec_t label.
(In reply to comment #30) > Could you please test it with selinux-policy-3.7.19-143.el6 which is now > building. This release also contains > > domtrans_pattern(certmonger_t, certmonger_unconfined_exec_t, > certmonger_unconfined_t) > > rule. Also please make sure the /usr/lib/ipa/certmonger/ directory is labeled > correctly with the certmonger_unconfined_exec_t label. Still the same behaviour even with selinux-policy-3.7.19-143 [root@dhcp201-185 ~]# ls -laZ /usr/lib/ipa/certmonger/ drwxr-xr-x. root root unconfined_u:object_r:certmonger_unconfined_exec_t:s0 . drwxr-xr-x. root root unconfined_u:object_r:certmonger_unconfined_exec_t:s0 .. -rwxr-xr-x. root root unconfined_u:object_r:certmonger_unconfined_exec_t:s0 httpd_restart [root@dhcp201-185 ~]# ls -laZ /usr/lib/ipa/certmonger/httpd_restart -rwxr-xr-x. root root unconfined_u:object_r:certmonger_unconfined_exec_t:s0 /usr/lib/ipa/certmonger/httpd_restart [root@dhcp201-185 ~]# rpm -q selinux-policy selinux-policy-3.7.19-143.el6.noarch [root@dhcp201-185 ~]# type=AVC msg=audit(1332328280.708:630): avc: denied { ioctl } for pid=18090 comm="sh" path="/usr/lib/ipa/certmonger/httpd_restart" dev=dm-0 ino=8988 scontext=unconfined_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:certmonger_unconfined_exec_t:s0 tclass=file type=SYSCALL msg=audit(1332328280.708:630): arch=c000003e syscall=16 success=no exit=-13 a0=6 a1=5401 a2=7fffdeae4be0 a3=7fffdeae49f0 items=0 ppid=9022 pid=18090 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=5 comm="sh" exe="/bin/bash" subj=unconfined_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1332328280.710:631): avc: denied { execute } for pid=18093 comm="service" name="consoletype" dev=dm-0 ino=8691 scontext=unconfined_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:consoletype_exec_t:s0 tclass=file type=SYSCALL msg=audit(1332328280.710:631): arch=c000003e syscall=59 success=no exit=-13 a0=17eabe0 a1=17eac40 a2=17f25e0 a3=7fff6a178340 items=0 ppid=18092 pid=18093 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=5 comm="service" exe="/bin/bash" subj=unconfined_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1332328280.711:632): avc: denied { getattr } for pid=18093 comm="service" path="/sbin/consoletype" dev=dm-0 ino=8691 scontext=unconfined_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:consoletype_exec_t:s0 tclass=file type=SYSCALL msg=audit(1332328280.711:632): arch=c000003e syscall=4 success=no exit=-13 a0=17eabe0 a1=7fff6a178520 a2=7fff6a178520 a3=7fff6a178340 items=0 ppid=18092 pid=18093 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=5 comm="service" exe="/bin/bash" subj=unconfined_u:system_r:certmonger_t:s0 key=(null) Cert Status: ============ Cert is generated and monitored by certmonger [root@dhcp201-185 kaleem]# getcert request -d /tmp/kaleem -n test1 -I testing -P redhat -c SelfSign -C /usr/lib/ipa/certmonger/httpd_restart New signing request "testing" added. [root@dhcp201-185 kaleem]# getcert list Number of certificates and requests being tracked: 1. Request ID 'testing': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/tmp/kaleem',nickname='test1',token='NSS Certificate DB',pin='redhat' certificate: type=NSSDB,location='/tmp/kaleem',nickname='test1',token='NSS Certificate DB' CA: SelfSign issuer: CN=dhcp201-185.englab.pnq.redhat.com subject: CN=dhcp201-185.englab.pnq.redhat.com expires: 2013-03-21 11:11:20 UTC dns: dhcp201-185.englab.pnq.redhat.com principal name: host/dhcp201-185.englab.pnq.redhat.com eku: id-kp-serverAuth command: /usr/lib/ipa/certmonger/httpd_restart track: yes auto-renew: yes [root@dhcp201-185 kaleem]# [root@dhcp201-185 ~]# ls -laZ /tmp/kaleem/ drwxr-xr-x. root root unconfined_u:object_r:cert_t:s0 . drwxrwxrwt. root root system_u:object_r:tmp_t:s0 .. -rw-------. root root unconfined_u:object_r:cert_t:s0 cert8.db -rw-------. root root unconfined_u:object_r:cert_t:s0 key3.db -rw-------. root root unconfined_u:object_r:cert_t:s0 secmod.db [root@dhcp201-185 ~]#
selinux-policy-3.7.19-143.el6 seems to be working for me, at least in my contrived test.
Is SELinux being arch-specific with the lib dir? Is it /usr/lib/ipa/certmonger on x86 and /usr/lib64/ipa/certmonger on x86-64?
Script was not executed as i was using restart command for httpd.It works if i use it for reload and reload of httpd is successful. Also its working for restart of dirsrv and does successful restart of dirsrv. But in both cases(httpd_reload and dirsrv_restart) i am getting following avc messages. dirsrv_restart_avc_messages =========================== type=AVC msg=audit(1332486613.429:111): avc: denied { read write } for pid=3782 comm="ns-slapd" path="anon_inode:[eventpoll]" dev=anon_inodefs ino=3621 scontext=system_u:system_r:dirsrv_t:s0 tcontext=system_u:object_r:anon_inodefs_t:s0 tclass=file type=AVC msg=audit(1332486613.429:111): avc: denied { read } for pid=3782 comm="ns-slapd" path="pipe:[11398]" dev=pipefs ino=11398 scontext=system_u:system_r:dirsrv_t:s0 tcontext=system_u:system_r:certmonger_t:s0 tclass=fifo_file type=AVC msg=audit(1332486613.429:111): avc: denied { write } for pid=3782 comm="ns-slapd" path="pipe:[11398]" dev=pipefs ino=11398 scontext=system_u:system_r:dirsrv_t:s0 tcontext=system_u:system_r:certmonger_t:s0 tclass=fifo_file type=AVC msg=audit(1332486613.429:111): avc: denied { read write } for pid=3782 comm="ns-slapd" path="/var/run/certmonger.pid" dev=dm-0 ino=261768 scontext=system_u:system_r:dirsrv_t:s0 tcontext=system_u:object_r:certmonger_var_run_t:s0 tclass=file type=AVC msg=audit(1332486613.429:111): avc: denied { write } for pid=3782 comm="ns-slapd" path="pipe:[15062]" dev=pipefs ino=15062 scontext=system_u:system_r:dirsrv_t:s0 tcontext=system_u:system_r:certmonger_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1332486613.429:111): arch=c000003e syscall=59 success=yes exit=0 a0=2512bd0 a1=24be480 a2=24bdc70 a3=7fffd4bf3e40 items=0 ppid=3781 pid=3782 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ns-slapd" exe="/usr/sbin/ns-slapd" subj=system_u:system_r:dirsrv_t:s0 key=(null) type=AVC msg=audit(1332486614.512:112): avc: denied { read write } for pid=3848 comm="restorecon" path="anon_inode:[eventpoll]" dev=anon_inodefs ino=3621 scontext=system_u:system_r:setfiles_t:s0 tcontext=system_u:object_r:anon_inodefs_t:s0 tclass=file type=AVC msg=audit(1332486614.512:112): avc: denied { read } for pid=3848 comm="restorecon" path="pipe:[11398]" dev=pipefs ino=11398 scontext=system_u:system_r:setfiles_t:s0 tcontext=system_u:system_r:certmonger_t:s0 tclass=fifo_file type=AVC msg=audit(1332486614.512:112): avc: denied { write } for pid=3848 comm="restorecon" path="pipe:[11398]" dev=pipefs ino=11398 scontext=system_u:system_r:setfiles_t:s0 tcontext=system_u:system_r:certmonger_t:s0 tclass=fifo_file type=AVC msg=audit(1332486614.512:112): avc: denied { read write } for pid=3848 comm="restorecon" path="/var/run/certmonger.pid" dev=dm-0 ino=261768 scontext=system_u:system_r:setfiles_t:s0 tcontext=system_u:object_r:certmonger_var_run_t:s0 tclass=file type=AVC msg=audit(1332486614.512:112): avc: denied { write } for pid=3848 comm="restorecon" path="pipe:[15062]" dev=pipefs ino=15062 scontext=system_u:system_r:setfiles_t:s0 tcontext=system_u:system_r:certmonger_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1332486614.512:112): arch=c000003e syscall=59 success=yes exit=0 a0=24fb500 a1=2510f20 a2=25125d0 a3=7fffd4bf4700 items=0 ppid=3760 pid=3848 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="restorecon" exe="/sbin/setfiles" subj=system_u:system_r:setfiles_t:s0 key=(null) httpd_reload_avc_messages ========================= type=AVC msg=audit(1332487000.687:113): avc: denied { write } for pid=3878 comm="httpd" path="anon_inode:[eventpoll]" dev=anon_inodefs ino=3621 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:anon_inodefs_t:s0 tclass=file type=AVC msg=audit(1332487000.687:113): avc: denied { read } for pid=3878 comm="httpd" path="pipe:[11398]" dev=pipefs ino=11398 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:certmonger_t:s0 tclass=fifo_file type=AVC msg=audit(1332487000.687:113): avc: denied { write } for pid=3878 comm="httpd" path="pipe:[11398]" dev=pipefs ino=11398 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:certmonger_t:s0 tclass=fifo_file type=AVC msg=audit(1332487000.687:113): avc: denied { read write } for pid=3878 comm="httpd" path="/var/run/certmonger.pid" dev=dm-0 ino=261768 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:certmonger_var_run_t:s0 tclass=file type=AVC msg=audit(1332487000.687:113): avc: denied { write } for pid=3878 comm="httpd" path="pipe:[15224]" dev=pipefs ino=15224 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:certmonger_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1332487000.687:113): arch=c000003e syscall=59 success=yes exit=0 a0=18b2100 a1=18b67d0 a2=18b23a0 a3=7fff87db40c0 items=0 ppid=3875 pid=3878 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null)
(In reply to comment #33) > Is SELinux being arch-specific with the lib dir? Is it /usr/lib/ipa/certmonger > on x86 and /usr/lib64/ipa/certmonger on x86-64? Yes, we have /usr/lib(64)?/ipa/certmonger(/.*)? gen_context(system_u:object_r:certmonger_unconfined_exec_t,s0
How does the script look?
Script is [root@dhcp201-185 certmonger]# cat dirsrv_restart #!/bin/bash /sbin/service dirsrv restart [root@dhcp201-185 certmonger]# cat httpd_reload #!/bin/bash /sbin/service httpd reload [root@dhcp201-185 certmonger]# if in httpd_reload , i replace reload with restart then script is not executed and getting avc messages mentioned in comment 31.
Ok, these should block nothing. Some of them look like a redirection and some of them look like leaked file descriptors. Is certmonger closing fds on exec? Could you also try to add this local policy $ cat mypol.te policy_module(mypol,1.0) require{ type certmonger_t; type certmonger_unconfined_exec_t; } allow certmonger_t certmonger_unconfined_exec_t:file read_file_perms; and execute $ make -f /usr/share/selinux/devel/Makefile mycertmonger.pp $ semodule -i mycertmonger.pp Then see if httpd_restart also work.
With local policy given in comment 38, now httpd_restart works but with following avc messages. type=AVC msg=audit(1332510310.074:264): avc: denied { write } for pid=4440 comm="httpd" path="anon_inode:[eventpoll]" dev=anon_inodefs ino=3621 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:anon_inodefs_t:s0 tclass=file type=AVC msg=audit(1332510310.074:264): avc: denied { read } for pid=4440 comm="httpd" path="pipe:[11398]" dev=pipefs ino=11398 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:certmonger_t:s0 tclass=fifo_file type=AVC msg=audit(1332510310.074:264): avc: denied { write } for pid=4440 comm="httpd" path="pipe:[11398]" dev=pipefs ino=11398 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:certmonger_t:s0 tclass=fifo_file type=AVC msg=audit(1332510310.074:264): avc: denied { read write } for pid=4440 comm="httpd" path="/var/run/certmonger.pid" dev=dm-0 ino=261768 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:certmonger_var_run_t:s0 tclass=file type=AVC msg=audit(1332510310.074:264): avc: denied { write } for pid=4440 comm="httpd" path="pipe:[19037]" dev=pipefs ino=19037 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:certmonger_t:s0 tclass=fifo_file type=SYSCALL msg=audit(1332510310.074:264): arch=c000003e syscall=59 success=yes exit=0 a0=126ca20 a1=126c6f0 a2=126cf60 a3=7fff25788af0 items=0 ppid=4439 pid=4440 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null) [root@dhcp201-185 ~]# cat /var/log/audit/audit.log | audit2allow #============= httpd_t ============== allow httpd_t anon_inodefs_t:file write; allow httpd_t certmonger_t:fifo_file { read write }; allow httpd_t certmonger_var_run_t:file { read write }; [root@dhcp201-185 ~]#
(In reply to comment #27) > Ok, I am backporting it from Fedora. Do you mean backporting _to_ Fedora? We'd need this in at least F17+. I can open a separate BZ if necessary.
I meant from Fedora but I need to add the latest RHEL6 fixes to Fedora now. Nalin, my question in the #38 comment.
(In reply to comment #38) > Ok, these should block nothing. Some of them look like a redirection and some > of them look like leaked file descriptors. > > Is certmonger closing fds on exec? Not previously, but it will start to in 0.57. I don't know that the change will make the cutoff here, though. The anon_inodefs_t file is probably libtevent's polling descriptor, the fifo_files are probably pipes hooked up to stdio, and the certmonger_var_run_t files are either the daemon's pid file. Only the pipes are worth allowing.
The problem is we have the following certmonger_t @certomnger_unconfined_exec_t -> certomnger_unconfined_t @whatever -> random_domain_t/certmonger_unconfined_t @ .. execute -> .. transition We don't have a way how we could allow/dontaudit passed fds using easy way for this situation. Basically we either allow or don't audit this between two domains. But you can end up with random domain like httpd_t, dirsrv_t and so on. Dan, any idea? Add a new boolean for this?
Nalin is there a security issue with allowing all domains to write anon_inodefs_t? Or is there a problem with dontaudit all access? Can processes use anon_inodefs_t to communicate with each other?
If the anon_inodefs_t descriptor is used for polling, then sharing it doesn't make a lot of sense to me. So far, we're not using the pipes to communicate with unconfined child processes (enrollment helpers, which still run as certmonger_t, do use them, however), so designating these access attempts from other domains as dontaudit should be fine.
Is there a mechanism to close these descriptors?
We'll start to in 0.57. I don't know that the change will make the cutoff here, though.
Created attachment 586635 [details] here are all AVCs which appear during the run in permissive mode
Ok, this is wrong. Nalin, are all needed fixes placed in certmonger?
(In reply to comment #58) > Ok, this is wrong. > > Nalin, > are all needed fixes placed in certmonger? As noted previously, the child is going to inherit some descriptors until 0.57. If you're referring to something else, you'll have to be more specific.
The problem is it looks like the basic concept does not work and a custom script runs as certmonger_t instead of certmonger_unconfned_t.
Well, it looks it works for me. I execute $ getcert request -d /tmp/mgrepl -n test1 -I testing1 -P redhat -c SelfSign -C /usr/lib/ipa/certmonger/httpd_restart and I get ;#============= httpd_t ============== allow httpd_t anon_inodefs_t:file write; allow httpd_t certmonger_t:fifo_file { write read }; allow httpd_t certmonger_var_run_t:file { read write } it means there is a transition to certmonger_unconfined_t.
(In reply to comment #60) > (In reply to comment #58) > > Ok, this is wrong. > > > > Nalin, > > are all needed fixes placed in certmonger? > > As noted previously, the child is going to inherit some descriptors until > 0.57. If you're referring to something else, you'll have to be more > specific. Ah, I thought we could get it to RHEL6.3. I am worry about certmonger_dontaudit_leaks($1) dontaudit $1 anon_inodefs_t:file write; globally for all services. It could hide other problems.
When abrtd is restarted by the script, then ausearch and audit2allow produce this output: #============= abrt_t ============== allow abrt_t anon_inodefs_t:file write; allow abrt_t certmonger_t:fifo_file { write read }; allow abrt_t certmonger_var_run_t:file { read write }; # When httpd is restarted by the script, then ausearch and audit2allow produce this output: #============= httpd_t ============== allow httpd_t anon_inodefs_t:file write; allow httpd_t certmonger_t:fifo_file { write read }; allow httpd_t certmonger_var_run_t:file { read write }; #
Lets dontaudit for 6.3 and fix it for 6.4. AS long as we are dontauditing the leaks and not allowing opens, this should not be a problem.
Milos, are you still getting this on RHEL6.4?
No AVC appears when abrtd is restarted. Following AVC appears when httpd is restarted: ---- time->Wed Sep 5 12:07:51 2012 type=PATH msg=audit(1346839671.313:36771): item=0 name="/etc/init.d/httpd" inode=20646 dev=08:03 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:httpd_initrc_exec_t:s0 type=CWD msg=audit(1346839671.313:36771): cwd="/" type=SYSCALL msg=audit(1346839671.313:36771): arch=40000003 syscall=11 success=no exit=-13 a0=bfd54f5d a1=bfd53a74 a2=9cfd860 a3=bfd53a64 items=1 ppid=9018 pid=9023 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=74 comm="env" exe="/bin/env" subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(1346839671.313:36771): avc: denied { execute } for pid=9023 comm="env" name="httpd" dev=sda3 ino=20646 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:httpd_initrc_exec_t:s0 tclass=file ----
Well this is bad again. It should not be running as certmonger_t. I think it could be a test issue?
I am closing this one to modified because I believe this is a test issue.
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. http://rhn.redhat.com/errata/RHBA-2013-0314.html