Bug 442228 - dirsrv-admin startup error under SELinux strict policy: root:sysadm_r:unconfined_t:SystemLow-SystemHigh is not a valid context
Summary: dirsrv-admin startup error under SELinux strict policy: root:sysadm_r:unconfi...
Alias: None
Product: 389
Classification: Retired
Component: Security - General
Version: 1.1.0
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Viktor Ashirov
: 174855 491749 (view as bug list)
Depends On:
Blocks: 434915 389_1.2.6
TreeView+ depends on / blocked
Reported: 2008-04-13 00:33 UTC by Aleksander Adamowski
Modified: 2015-12-07 16:42 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-12-07 16:42:52 UTC

Attachments (Terms of Use)
Patch for SELinux policy for directory server (3.70 KB, patch)
2008-07-14 18:57 UTC, Pär Aronsson
no flags Details | Diff
tarball of the original policy files posted to fds list (5.07 KB, application/octet-stream)
2008-07-17 15:07 UTC, Rich Megginson
no flags Details

Description Aleksander Adamowski 2008-04-13 00:33:16 UTC
Description of problem:

When trying to start dirsrv-admin under strict SELinux policy on RHEL5, I get an

$ service dirsrv-admin start
Starting dirsrv-admin:
root:sysadm_r:unconfined_t:SystemLow-SystemHigh is not a valid context

The problem is in the start-ds-admin script. After changing the unconfined_t
type (which doesn't exist in strict policy) to something else, dirsrv-admin
starts up correctly:

$ diff -u /usr/sbin/start-ds-admin.orig /usr/sbin/start-ds-admin
--- /usr/sbin/start-ds-admin.orig       2008-04-13 02:27:29.000000000 +0200
+++ /usr/sbin/start-ds-admin    2008-04-13 02:25:18.000000000 +0200
@@ -60,7 +60,7 @@
 [ -f /etc/sysconfig/dirsrv-admin ] && . /etc/sysconfig/dirsrv-admin

 if [ -x /usr/sbin/selinuxenabled ] && /usr/sbin/selinuxenabled; then
-    SELINUX_CMD="runcon -t unconfined_t --"
+    SELINUX_CMD="runcon -t slapd_t --"

 $SELINUX_CMD $HTTPD $OMIT_DEFLATE -k start -f /etc/dirsrv/admin-serv/httpd.conf

Comment 1 Rich Megginson 2008-06-24 21:38:41 UTC
This doesn't work for me with the latest fedora 9:
runcon: invalid context: unconfined_u:unconfined_r:slapd_t:s0-s0:c0.c1023:
Invalid argument

I have

I know almost nothing about selinux, so I'm not sure what's going on here.

Comment 2 Aleksander Adamowski 2008-06-25 19:25:22 UTC
> SELINUXTYPE=targeted

You're using the "targeted" policy, so the "unconfined_t" domain is OK over
there and the start-ds-admin works properly.

However, if you switch to the "strict" policy, you'll get a failure because
there's no "unconfined_t" domain in "strict".

There's a "slapd_t" domain that was prepared for OpenLDAP, however the best
would be to prepare a dedicated policy module for Fedora DS that would define a
different domain.

An initial attempt at such module was recently posted on the mailing list:


Directory Server works in dirsrv_t domain with those policy modules.

I think Dan Walsh would be happy to help you with that since he's the Red Hat's
SELinux guru...

Anyway, the start-ds-admin script shouldn't use an invalid security context for
a given runtime policy, so a quick temporary fix would be to detect the running
policy and choose a domain type for the new context accordingly.

I don't know how to determine the name of currently running policy, but the one
from config file can be a good bet most of the time and it's returned by
"sestatus" utility:

policy_name=$(sestatus | grep '^Policy from config file:' | awk '{print $5}');
if [ "$policy_name" == "targeted" ]; then
SELINUX_CMD="runcon -t $newcontext_domain --"

OTOH what I suggest might not be very elegant, so I think you'd be better off if
you would consult any changes with Dan Walsh.

Comment 3 Rich Megginson 2008-07-01 13:32:51 UTC
*** Bug 174855 has been marked as a duplicate of this bug. ***

Comment 4 Pär Aronsson 2008-07-14 18:57:24 UTC
Created attachment 311749 [details]
Patch for SELinux policy for directory server

Comment 5 Pär Aronsson 2008-07-14 19:01:12 UTC
Comment on attachment 311749 [details]
Patch for SELinux policy for directory server

This is an update to the policy mentioned in Comment #2. See
http://www.nsa.gov/selinux/list-archive/0803/25615.cfm for an answer to the
comment by Dan Walsh.

Comment 6 Rich Megginson 2008-07-17 14:44:14 UTC
contributor is a member of the cla_done group

Comment 7 Rich Megginson 2008-07-17 15:07:45 UTC
Created attachment 312055 [details]
tarball of the original policy files posted to fds list

tarball of the original policy files posted to fds list

Comment 8 Rich Megginson 2008-07-17 15:08:32 UTC
I guess the patch attachment should be applied to the files in the tarball

Comment 9 Rich Megginson 2008-07-17 15:29:50 UTC
The dirsrv-admin files should go in the adminserver CVS module and ds-admin
package.  The dirsrv files should go in the ldapserver CVS module and the
ds-base package.  The console packages should go in the fedora-idm-console CVS
module and package.

The ds and admserv configure.ac will need some way to detect if selinux is being
used on the system.  Conditional make in Makefile.am will be used to build and
install the policy files.  We have to preserve cross platform build capability,
but at the same time make it easy to build the selinux parts on platforms that
support it.  For the fedora-idm-console package, this will be a little different
since it uses ant and build.xml, but it should be easy to change that to detect
and build the selinux policy.

The spec files will have the following changes:
* appropriate BuildRequires will be added to have the selinux devel stuff
* The policy will be added to the main package, not in a sub package

I don't know if there are any rpm macros for selinux paths (e.g. the commands ot
use to install policy, the paths where policy is installed), but we should avoid
hardcoding such things as much as possible, both in the makefiles and in the
spec files.

Comment 10 Rich Megginson 2009-03-30 18:06:41 UTC
*** Bug 491749 has been marked as a duplicate of this bug. ***

Comment 11 Nathan Kinder 2009-10-26 20:13:52 UTC
This issue should be taken care of now as I've checked in a dirsrv-admin policy to the adminserver GIT repository.  The unconfined_t context is no longer used with the policy module loaded.

This change is not yet in a released build, but will be in one of the upcoming 389-admin builds (post 1.1.9).

Comment 14 Amita Sharma 2011-06-01 09:12:28 UTC
[root@testvm slapd-testvm]# ps -efZ | grep httpd
unconfined_u:system_r:httpd_t:s0 root    28425     1  0 14:04 ?        00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf
unconfined_u:system_r:httpd_t:s0 root    28428 28425  0 14:04 ?        00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf
unconfined_u:system_r:httpd_t:s0 nobody  28429 28425  0 14:04 ?        00:00:00 /usr/sbin/httpd.worker -k start -f /etc/dirsrv/admin-serv/httpd.conf
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 29119 27896  0 14:41 pts/0 00:00:00 grep httpd


Note You need to log in before you can comment on or make changes to this bug.