Bug 653794

+++ 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.