Description of problem: When trying to start dirsrv-admin under strict SELinux policy on RHEL5, I get an error: $ service dirsrv-admin start Starting dirsrv-admin: root:sysadm_r:unconfined_t:SystemLow-SystemHigh is not a valid context [FAILED] 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 --" fi $SELINUX_CMD $HTTPD $OMIT_DEFLATE -k start -f /etc/dirsrv/admin-serv/httpd.conf "$@"
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 SELINUX=enforcing SELINUXTYPE=targeted I know almost nothing about selinux, so I'm not sure what's going on here.
> 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: https://www.redhat.com/archives/fedora-directory-users/2008-March/msg00116.html 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 newcontext_domain=unconfined_t else newcontext_domain=slapd_t fi 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.
*** Bug 174855 has been marked as a duplicate of this bug. ***
Created attachment 311749 [details] Patch for SELinux policy for directory server
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.
https://admin.fedoraproject.org/accounts/user/view/bald contributor is a member of the cla_done group
Created attachment 312055 [details] tarball of the original policy files posted to fds list tarball of the original policy files posted to fds list
I guess the patch attachment should be applied to the files in the tarball attachment.
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.
*** Bug 491749 has been marked as a duplicate of this bug. ***
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).
[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 VERIFIED.