Bug 655206

Summary: Need dirsrv and dirsrv-admin policy modules merged into base policy
Product: Red Hat Enterprise Linux 6 Reporter: Nathan Kinder <nkinder>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: medium Docs Contact:
Priority: low    
Version: 6.1CC: dwalsh, ksrot, mmalik, rmeggins
Target Milestone: rc   
Target Release: 6.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: selinux-policy-3.7.19-59.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 648949 Environment:
Last Closed: 2011-05-19 11:57:00 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: 648949    
Bug Blocks: 639035, 642407, 653794    

Description Nathan Kinder 2010-11-19 21:07:24 UTC
+++ 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.

Comment 1 Daniel Walsh 2010-11-22 21:39:29 UTC
I think we really want to test and coordinate this change.

Comment 2 Daniel Walsh 2010-11-29 17:06:18 UTC
Is dirsrv being updated in 6.1?

Comment 3 Rich Megginson 2010-11-29 17:09:00 UTC
(In reply to comment #2)
> Is dirsrv being updated in 6.1?

Yes.  389-ds-base is going into RHEL 6.1 (it's already in).  It will not have selinux policy - we are assuming it will be provided by the base OS policy.

Comment 4 Nathan Kinder 2010-11-29 17:12:39 UTC
(In reply to comment #2)
> Is dirsrv being updated in 6.1?

Also, 389-ds-base will not be available at all on RHEL6 until RHEL 6.1.  This will be our first release outside of Fedora where 389 is confined by SELinux policy.

Comment 5 Miroslav Grepl 2010-11-29 17:30:18 UTC
So this is a different situation from Fedora. I mean the 398-* pkgs were released with own policy for the first time.

Comment 6 Nathan Kinder 2010-11-29 17:35:41 UTC
(In reply to comment #5)
> So this is a different situation from Fedora. I mean the 398-* pkgs were
> released with own policy for the first time.

Yes.  There should be no need for any "Conflicts" in any of the spec files.  We will simply need to add a "Requires" directive to 389-ds-base and 389-admin to require the proper version of selinux-policy where dirsrv policy is implemented.

Comment 8 Miroslav Grepl 2010-12-09 16:06:03 UTC
Fixed in selinux-policy-3.7.19-59.el6

Comment 11 errata-xmlrpc 2011-05-19 11:57:00 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0526.html