Bug 570912
Summary: | SELinux denials with 1.2.6.a2 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Retired] 389 | Reporter: | Anthony Messina <amessina> | ||||||||||
Component: | Security - General | Assignee: | Nathan Kinder <nkinder> | ||||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Viktor Ashirov <vashirov> | ||||||||||
Severity: | high | Docs Contact: | |||||||||||
Priority: | high | ||||||||||||
Version: | 1.2.6 | CC: | amsharma, jgalipea, nkinder, rmeggins | ||||||||||
Target Milestone: | --- | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | All | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2015-12-07 17:07:41 UTC | Type: | --- | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Bug Depends On: | |||||||||||||
Bug Blocks: | 543590 | ||||||||||||
Attachments: |
|
Description
Anthony Messina
2010-03-05 20:24:45 UTC
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. |