+++ This bug was initially created as a clone of Bug #648949 +++ The two SELinux policy modules used for the 389 Directory Server are currently contained within the 389 packages. We would like these policy modules to be merged into the base system policy instead of being carried separately. We began including our policy modules in the following packages: 389-ds-base-1.2.6 389-admin-1.1.11 I will attach our policy module source code to this bug. Please let me know what other info you need from me. --- Additional comment from nkinder on 2010-11-02 11:28:08 EDT --- Created attachment 457199 [details] dirsrv policy source --- Additional comment from nkinder on 2010-11-02 11:29:49 EDT --- Created attachment 457200 [details] dirsrv-admin policy source --- Additional comment from nkinder on 2010-11-02 11:37:06 EDT --- One thing that we currently do during the 389 build process is to build the *.fc files from a template. You will see in the attachments that our *.fc files have path macros that are substituted with real paths. We will have to change this to use the actual hard-coded paths. The macros should be replaced with the following paths for the dirsrv module: @package_name@ dirsrv @sbindir@ /usr/sbin @localstatedir@ /var @sysconfdir@ /etc @datadir@ /usr/share I will gather the data for replacing the other macros used in the dirsrv-admin module. --- Additional comment from nkinder on 2010-11-02 16:51:43 EDT --- The dirsrv-admin *.fc macros should be replaced as follows: @configdir@ /etc/dirsrv/admin-serv @dsgwconfigdir@ @logdir@ /var/log/dirsrv/admin-serv @piddir@ /var/run/dirsrv @instancename@ admin-serv @cgibindir@ /usr/lib64/dirsrv/cgi-bin @dsgwcgibindir@ /usr/lib64/dirsrv/dsgw-cgi-bin @dsgwcookiedir@ /opt/dirsrv/var/run/dirsrv/dsgw/cookies Note that the paths for both @cgibindir@ and @dsgwcgibindir@ are going to differ between i586 and x86_64 platforms since they reside in libdir. --- Additional comment from dwalsh on 2010-11-03 09:52:19 EDT --- Nathan if you want to allow alternative paths you can do this with semanage commands now. For example # semanage fcontext -a -e /var/log/dirsrv /var/log/mydirsrv Would end up labeling everything under /var/log/mydirsrv the same as it would under /var/log/dirsrv. We are going to have to coordinate an update. I can ship an updated policy which contains your policy, then I will have to put a conflicts with your current dirsrv version, and you will have to ship an update which does not include the policy. When you install a module to you use -u or -i? --- Additional comment from nkinder on 2010-11-03 13:23:17 EDT --- (In reply to comment #5) > Nathan if you want to allow alternative paths you can do this with semanage > commands now. > > For example > > # semanage fcontext -a -e /var/log/dirsrv /var/log/mydirsrv > > Would end up labeling everything under /var/log/mydirsrv the same as it would > under /var/log/dirsrv. Yes, this is what we are going to be documenting for paths that are configurable at runtime. We hard-code some paths at buildtime that are built from options to configure. These are always the same when we build official 389 builds on Fedora and RHEL, so we can just hard-code them in the *.fc files as I described above. This will suit our needs just fine. > We are going to have to coordinate an update. I can ship an updated policy > which contains your policy, then I will have to put a conflicts with your > current dirsrv version, and you will have to ship an update which does not > include the policy. Ok. Perhaps you can get a test package for us to work with first and then we can coordinate a release. I will need to talk with Rich to determine the best timeline. > When you install a module to you use -u or -i? We curently use 'semodule -i' in our spec file to install the module. --- Additional comment from dwalsh on 2010-11-04 14:42:08 EDT --- What is the path for @dsgwconfigdir@ --- Additional comment from dwalsh on 2010-11-04 14:49:58 EDT --- What is this? # Net-SNMP persistent data file files_manage_var_files(dirsrv_snmp_t) --- Additional comment from nkinder on 2010-11-04 14:58:07 EDT --- (In reply to comment #7) > What is the path for > > @dsgwconfigdir@ Sorry about missing that one. The path for this is "/opt/dirsrv/etc/dirsrv/dsgw". (In reply to comment #8) > What is this? > > # Net-SNMP persistent data file > files_manage_var_files(dirsrv_snmp_t) The Net-SNMP libraries used by our SNMP subagent (ldap-agent) create a persistent data file in /var/lib/net-snmp. This access was required to allow that file to be managed. --- Additional comment from rmeggins on 2010-11-04 15:17:27 EDT --- (In reply to comment #9) > (In reply to comment #7) > > What is the path for > > > > @dsgwconfigdir@ > > Sorry about missing that one. The path for this is > "/opt/dirsrv/etc/dirsrv/dsgw". I think it is just /etc/dirsrv/dsgw since we're using FHS. --- Additional comment from dwalsh on 2010-11-04 16:02:45 EDT --- Created attachment 457927 [details] File context for admin policy --- Additional comment from dwalsh on 2010-11-04 16:03:34 EDT --- Created attachment 457929 [details] File context for dirsrv.fc --- Additional comment from dwalsh on 2010-11-04 16:04:23 EDT --- What is the last version of dirsrv that will have policy in it? I need to add an obsoletes for the package in selinux-policy. --- Additional comment from rmeggins on 2010-11-04 17:06:17 EDT --- 389-ds-base-1.2.6.1 and 389-admin-1.1.11 are the latest Stable packages. We can remove the policy from 389-ds-base-1.2.7 and 389-admin-1.1.12 --- Additional comment from dwalsh on 2010-11-05 14:47:59 EDT --- Latest rawhide has a fixed up policy for dirsrv and dirsrv-admin, please try it out. I removed some stuff, please add avc messages to this bugzilla. In Rawhide you want to conflicts: selinux-policy-base < 3.9.8 --- Additional comment from dwalsh on 2010-11-05 14:59:26 EDT --- selinux-policy-3.9.8 has Conflicts: 389-ds-base < 1.2.7, 389-admin < 1.1.12 --- Additional comment from nkinder on 2010-11-12 12:35:38 EST --- Testing with this new selinux-policy package looks good so far. Is there a chance that we can get the changes ported to F13 and F14 and released in updates-testing? We don't want the changes in stable there yet as we need to build and test our packages first so we can coordinate releasing everything. --- Additional comment from dwalsh on 2010-11-12 13:38:16 EST --- Miroslav can you take the dirsrv* files out of Rawhide and put them in F13 and F14 Nathan, I don't want to hold up F13 and F14 policy for a long period of time, so when Miroslav puts them in update testing, you will need to have packages ready to go also. If he adds Conflicts: 389-ds-base < 1.2.7, 389-admin < 1.1.12 Policy will not be allowed to update on machines with 389 installed, and 389 will not be allowed to be installed with the new version of selinux-policy. --- Additional comment from nkinder on 2010-11-12 13:56:17 EST --- (In reply to comment #18) > Nathan, I don't want to hold up F13 and F14 policy for a long period of time, > so when Miroslav puts them in update testing, you will need to have packages > ready to go also. > > If he adds > > Conflicts: 389-ds-base < 1.2.7, 389-admin < 1.1.12 > > Policy will not be allowed to update on machines with 389 installed, and 389 > will not be allowed to be installed with the new version of selinux-policy. Yes, this is what we want to avoid/minimize. We are working on building packages now, but we would like to test 389 upgrade scenarios before pushing to stable. --- Additional comment from nkinder on 2010-11-12 17:51:01 EST --- I will need to know the versions of selinux-policy-base that we need to conflict with for F-13 and F-14 to proceed with building our updated 389 packages. I would like a few days to play with some test selinux-policy packages to make sure everything seems ok on those platforms before pushing to stable. --- Additional comment from mgrepl on 2010-11-15 08:26:59 EST --- I am adding it to selinux-policy-3.7.19-72.fc13 selinux-policy-3.9.7-13.fc14 which I will build later today. So you can test it and I can wait till tomorrow with pushing to testing repo.
Actually fixed in selinux-policy-3.9.7-11.fc14.noarch. http://koji.fedoraproject.org/koji/buildinfo?buildID=205037
I'm getting AVC messages with our admin server (which runs in an extended httpd_t context) using selinux-policy-3.9.7-11.fc14.noarch. For example, here is what I see in the audit log when starting the dirsrv-admin service after upgrading 389-ds-base and 389-admin to the recent koji builds (1.2.7 and 1.1.12 respectively): type=AVC msg=audit(1290031235.970:55): avc: denied { execute_no_trans } for pid=3169 comm="ldd" path="/lib64/ld-2.12.1.so" dev=dm-0 ino=130147 scontext=unconfined_u:system_r:dirsrvadmin_t:s0 tcontext=system_u:object_r:ld_so_t:s0 tclass=file type=SYSCALL msg=audit(1290031235.970:55): arch=c000003e syscall=59 success=no exit=-13 a0=148f640 a1=148f6a0 a2=1499080 a3=20 items=0 ppid=3167 pid=3169 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="ldd" exe="/bin/bash" subj=unconfined_u:system_r:dirsrvadmin_t:s0 key=(null) type=AVC msg=audit(1290031236.027:56): avc: denied { search } for pid=3172 comm="httpd.worker" name="admin-serv" dev=dm-0 ino=1940 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:dirsrvadmin_config_t:s0 tclass=dir type=SYSCALL msg=audit(1290031236.027:56): arch=c000003e syscall=4 success=yes exit=128 a0=7f7ac841bdd0 a1=7fff285a2a30 a2=7fff285a2a30 a3=7fff285a27b0 items=0 ppid=3165 pid=3172 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="httpd.worker" exe="/usr/sbin/httpd.worker" subj=unconfined_u:system_r:httpd_t:s0 key=(null) type=AVC msg=audit(1290031236.035:57): avc: denied { search } for pid=3172 comm="httpd.worker" name="admin-serv" dev=dm-0 ino=1940 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:dirsrvadmin_config_t:s0 tclass=dir type=SYSCALL msg=audit(1290031236.035:57): arch=c000003e syscall=2 success=no exit=-13 a0=7f7ac841bdd0 a1=80000 a2=1b6 a3=7fff285a27f0 items=0 ppid=3165 pid=3172 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="httpd.worker" exe="/usr/sbin/httpd.worker" subj=unconfined_u:system_r:httpd_t:s0 key=(null) I'm still working on determining where exactly the problem lies.
Our admin server startup process has a chain of scripts that ultimately calls httpd.worker. Here is that chain and the labels on the scripts/binaries: /etc/init.d/dirsrv-admin (initrc_exec_t) -> /usr/sbin/start-ds-admin (dirsrvadmin_exec_t) -> /usr/sbin/httpd.worker (httpd_exec_t) In the dirsrv-admin policy, the dirsrvadmin_extend_httpd() macro is supposed to allow httpd_t processes to access some dirsrv files (among other things). This area of the policy seems broken now. Perhaps this has something to do with the dirsrv-admin policy using macros provided by the dirsrv policy interface? I would expect those sorts of issues to arise at policy build time though. I'm going to reopen this bug until we figure out what is causing this issue.
I also just confirmed that this issue has nothing to do with upgrading. If I install the new selinux-policy packages from koji along with my new 389-admin and 389-ds-base packages, I get the same slew of AVC messages when the Admin Server is started at the end of the install process. This same test worked fine in Rawhide with the selinux-policy packages that dwalsh created.
(In reply to comment #2) > I'm getting AVC messages with our admin server (which runs in an extended > httpd_t context) using selinux-policy-3.9.7-11.fc14.noarch. I misspoke here. This system is actually F13 using selinux-policy-3.7.19-72.fc13.noarch.rpm. Please let me know if there is a separate F13 bug that you would like me to move this issue to. I have yet to test the new packages on F14, but will be doing so shortly.
I am looking into. Nathan, could you switch to permissive mode and test it. # setenforce 0 test it and then execute # ps -eZ | grep initrc # ausearch -m avc -ts recent # setenforce 1
Actually I missed some changes which Dan did in Rawhide. Fixed in selinux-policy-3.9.7-12.fc14
(In reply to comment #7) > Actually I missed some changes which Dan did in Rawhide. > > Fixed in selinux-policy-3.9.7-12.fc14 This package works much better. Could you please make a new build for F13 with the same fixes?
Just building ... http://koji.fedoraproject.org/koji/taskinfo?taskID=2609671
selinux-policy-3.9.7-12.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-12.fc14
selinux-policy-3.9.7-12.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update selinux-policy'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-12.fc14
selinux-policy-3.9.7-12.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.