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.
Created attachment 457199 [details] dirsrv policy source
Created attachment 457200 [details] dirsrv-admin policy source
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.
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.
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?
(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.
What is the path for @dsgwconfigdir@
What is this? # Net-SNMP persistent data file files_manage_var_files(dirsrv_snmp_t)
(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.
(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.
Created attachment 457927 [details] File context for admin policy
Created attachment 457929 [details] File context for dirsrv.fc
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.
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
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
selinux-policy-3.9.8 has Conflicts: 389-ds-base < 1.2.7, 389-admin < 1.1.12
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.
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.
(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.
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.
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.