After installing version 1.2.6.a2 and the related SELinux RPMs, and relabeling on reboot, I get the following errors: # httpd doesn't seem to have access to the files in /usr/share/dirsrv node=ds.messinet.com type=AVC msg=audit(1267814536.415:885): avc: denied { getattr } for pid=1317 comm="httpd.worker" path="/usr/share/dirsrv" dev=md0 ino=57408 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:dirsrv_share_t:s0 tclass=dir node=ds.messinet.com type=SYSCALL msg=audit(1267814536.415:885): arch=c000003e syscall=6 success=yes exit=0 a0=7f3c80056508 a1=7f3c85401a50 a2=7f3c85401a50 a3=1 items=0 ppid=1311 pid=1317 auid=4294967295 uid=99 gid=99 euid=99 suid=99 fsuid=99 egid=99 sgid=99 fsgid=99 tty=(none) ses=4294967295 comm="httpd.worker" exe="/usr/sbin/httpd.worker" subj=system_u:system_r:httpd_t:s0 key=(null) # or the /etc/dirsrv files node=ds.messinet.com type=AVC msg=audit(1267814536.439:886): avc: denied { search } for pid=1317 comm="httpd.worker" name="dirsrv" dev=md0 ino=19824 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:dirsrv_config_t:s0 tclass=dir node=ds.messinet.com type=AVC msg=audit(1267814536.439:886): avc: denied { getattr } for pid=1317 comm="httpd.worker" path="/etc/dirsrv/admin-serv/adm.conf" dev=md0 ino=36663 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:dirsrv_config_t:s0 tclass=file node=ds.messinet.com type=SYSCALL msg=audit(1267814536.439:886): arch=c000003e syscall=4 success=yes exit=0 a0=7f3c8005b4e0 a1=7f3c85401870 a2=7f3c85401870 a3=20 items=0 ppid=1311 pid=1317 auid=4294967295 uid=99 gid=99 euid=99 suid=99 fsuid=99 egid=99 sgid=99 fsgid=99 tty=(none) ses=4294967295 comm="httpd.worker" exe="/usr/sbin/httpd.worker" subj=system_u:system_r:httpd_t:s0 key=(null) # or selinux's file_contexts file (not sure why it needs this) node=ds.messinet.com type=AVC msg=audit(1267813430.968:855): avc: denied { read } for pid=1239 comm="ns-slapd" name="file_contexts" dev=md0 ino=136 scontext=system_u:system_r:dirsrv_t:s0 tcontext=system_u:object_r:file_context_t:s0 tclass=file node=ds.messinet.com type=AVC msg=audit(1267813430.968:855): avc: denied { open } for pid=1239 comm="ns-slapd" name="file_contexts" dev=md0 ino=136 scontext=system_u:system_r:dirsrv_t:s0 tcontext=system_u:object_r:file_context_t:s0 tclass=file node=ds.messinet.com type=SYSCALL msg=audit(1267813430.968:855): arch=c000003e syscall=2 success=yes exit=32 a0=7f92600d47b0 a1=0 a2=1b6 a3=0 items=0 ppid=1 pid=1239 auid=4294967295 uid=99 gid=99 euid=99 suid=99 fsuid=99 egid=99 sgid=99 fsgid=99 tty=(none) ses=4294967295 comm="ns-slapd" exe="/usr/sbin/ns-slapd" subj=system_u:system_r:dirsrv_t:s0 key=(null) # or when using kerberos, it's own credentials, since the credentials are still created under the initrc context. node=ds.messinet.com type=AVC msg=audit(1267813431.261:858): avc: denied { read write } for pid=1239 comm="ns-slapd" name="ldap_99" dev=md0 ino=8377 scontext=system_u:system_r:dirsrv_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file node=ds.messinet.com type=AVC msg=audit(1267813431.261:858): avc: denied { open } for pid=1239 comm="ns-slapd" name="ldap_99" dev=md0 ino=8377 scontext=system_u:system_r:dirsrv_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file node=ds.messinet.com type=SYSCALL msg=audit(1267813431.261:858): arch=c000003e syscall=2 success=yes exit=32 a0=7f923c165830 a1=2 a2=180 a3=11 items=0 ppid=1 pid=1239 auid=4294967295 uid=99 gid=99 euid=99 suid=99 fsuid=99 egid=99 sgid=99 fsgid=99 tty=(none) ses=4294967295 comm="ns-slapd" exe="/usr/sbin/ns-slapd" subj=system_u:system_r:dirsrv_t:s0 key=(null)
What platform?
Created attachment 398130 [details] selinux alerts on current F-13 (with the fixed selinux-policy package)
(In reply to comment #1) > What platform? Fedora 12, x86_64.
Ok. Looks like the F-12 problem is because there is another conflict: [root@f12x8664 ~]# semodule -s targeted -i /usr/share/selinux/targeted/dirsrv-admin.pp libsepol.expand_terule_helper: conflicting TE rule for (httpd_t, var_run_t:dir): old was httpd_var_run_t, new is dirsrv_var_run_t libsepol.expand_module: Error during expand libsemanage.semanage_expand_sandbox: Expand module failed semodule: Failed!
(In reply to comment #4) > Ok. Looks like the F-12 problem is because there is another conflict: > > [root@f12x8664 ~]# semodule -s targeted -i > /usr/share/selinux/targeted/dirsrv-admin.pp > libsepol.expand_terule_helper: conflicting TE rule for (httpd_t, > var_run_t:dir): old was httpd_var_run_t, new is dirsrv_var_run_t > libsepol.expand_module: Error during expand > libsemanage.semanage_expand_sandbox: Expand module failed > semodule: Failed! Same problem on F-13 too :P
*** Bug 576427 has been marked as a duplicate of this bug. ***
Created attachment 404068 [details] ds patch
Created attachment 404069 [details] admin patch
Pushed both patches to master. Thanks for the reviews! Counting objects: 7, done. Delta compression using 2 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 662 bytes, done. Total 4 (delta 3), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git c559982..6f4d921 master -> master Counting objects: 7, done. Delta compression using 2 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 604 bytes, done. Total 4 (delta 3), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/admin.git 7eef51d..9f1ab16 master -> master
Now there's a different problem on F-13: [root@f13x8664 ~]# semodule -v -s targeted -i /usr/share/selinux/targeted/dirsrv-admin.pp Attempting to install module '/usr/share/selinux/targeted/dirsrv-admin.pp': Ok: return value of 0. Committing changes: libsepol.expand_terule_helper: duplicate TE rule for init_t dirsrvadmin_exec_t:process dirsrvadmin_t libsepol.expand_module: Error during expand libsemanage.semanage_expand_sandbox: Expand module failed semodule: Failed!
Created attachment 404564 [details] Additional admin patch The dirsrv-admin policy was calling two different macros that were not designed to be used together. This worked in the past, but it causes a conflicting rule to result on F-13. We really only need to use the init_daemon_domain macro. During testing, I also encountered an AVC when restarting the dirsrv-admin service. We needed to add ioctl permission for dirsrvadmin_t fifo files to the dirsrvadmin_t domain. There is still a separate issue on F-13 that prevents the dirsrv-admin policy from installing, but I believe it is a problem in the base policy. I have opened bug 579553 to get this issue addressed. I have tested my changes on F-12 to ensure that the policy builds and functions properly.
Pushed patch from comment #12 to master. Thanks to Rich for his review! Counting objects: 7, done. Delta compression using 2 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 640 bytes, done. Total 4 (delta 3), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/admin.git 258be85..2b661e5 master -> master
I don't see these errors with: 389-ds-base-1.2.6-0.7.rc2.fc13.x86_64 389-admin-1.1.11-0.5.rc1.fc13.x86_64
There are some in vim /var/log/audit/audit.log ..... type=AVC msg=audit(1306917222.336:6237): avc: denied { execute_no_trans } for pid=28388 comm="httpd.worker" path="/usr/lib64/dirsrv/cgi-bin/start_config_ds" dev=dm-0 ino=792830 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file type=SYSCALL msg=audit(1306917222.336:6237): arch=c000003e syscall=59 success=yes exit=0 a0=7f421faf8718 a1=7f421faf9388 a2=7f421faf8780 a3=7fff0b7ab860 items=0 ppid=17510 pid=28388 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=662 comm="start_config_ds" exe="/usr/lib64/dirsrv/cgi-bin/start_config_ds" subj=unconfined_u:system_r:httpd_t:s0 key=(null) type=AVC msg=audit(1306917222.450:6238): avc: denied { execute_no_trans } for pid=28389 comm="sh" path="/usr/lib64/dirsrv/slapd-testvm/start-slapd" dev=dm-0 ino=800671 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:lib_t:s0 tclass=file type=SYSCALL msg=audit(1306917222.450:6238): arch=c000003e syscall=59 success=yes exit=0 a0=19c0b40 a1=19c0bc0 a2=19bf660 a3=10 items=0 ppid=28388 pid=28389 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=662 comm="start-slapd" exe="/bin/bash" subj=unconfined_u:system_r:httpd_t:s0 key=(null) type=AVC msg=audit(1306917222.456:6239): avc: denied { read } for pid=28393 comm="cat" name="slapd-testvm.pid" dev=dm-0 ino=661111 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:initrc_var_run_t:s0 tclass=file type=AVC msg=audit(1306917222.456:6239): avc: denied { open } for pid=28393 comm="cat" name="slapd-testvm.pid" dev=dm-0 ino=661111 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:initrc_var_run_t:s0 tclass=file type=SYSCALL msg=audit(1306917222.456:6239): arch=c000003e syscall=2 success=yes exit=4 a0=7fff32b74a44 a1=0 a2=7fff32b74340 a3=a items=0 ppid=28390 pid=28393 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=662 comm="cat" exe="/bin/cat" subj=unconfined_u:system_r:httpd_t:s0 key=(null) type=AVC msg=audit(1306917222.456:6240): avc: denied { signull } for pid=28390 comm="start-dirsrv" scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=process @
(In reply to comment #17) > There are some in vim /var/log/audit/audit.log ..... > These appear to be something different than the initially reported issues. This should likely be a new bug, but it will need to be logged against selinux-policy-targeted so the system policy can be updated appropriately.
ok, then marking this bug as VERIFIED and will open a separate bug.