Bug 584156 - SELinux error on startup
Summary: SELinux error on startup
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Security - General
Version: 1.2.6
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 639035
TreeView+ depends on / blocked
 
Reported: 2010-04-20 20:38 UTC by Rob Crittenden
Modified: 2015-12-07 16:38 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-07 16:38:45 UTC


Attachments (Terms of Use)
Proposed Patch (3.20 KB, patch)
2010-04-21 20:59 UTC, Nathan Kinder
nkinder: review?
rmeggins: review+
Details | Diff

Description Rob Crittenden 2010-04-20 20:38:10 UTC
Description of problem:

Upgraded to 389-ds-base-1.2.6-0.3.a3.fc12.x86_64 and DS fails to start.

Not 100% sure but I think I was running 389-ds-base-1.2.5-1 previously. There is no other 389-ds-base entry in my yum log but I'm fairly sure this machine was up-to-date.

ldapi is configured:

nsslapd-ldapifilepath: /var/run/slapd-GREYOAK-COM.socket

from my audit log:

type=AVC msg=audit(1271794611.360:45385): avc:  denied  { unlink } for pid=12131 comm="ns-slapd" name="slapd-GREYOAK-COM.socket" dev=sda1 ino=40977 scontext=unconfined_u:system_r:dirsrv_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1271794611.360:45385): arch=c000003e syscall=87 success=yes exit=0 a0=b191f2 a1=a62681 a2=46 a3=7fff53236af0 items=0 ppid=12130 pid=12131 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=222 comm="ns-slapd" exe="/usr/sbin/ns-slapd" subj=unconfined_u:system_r:dirsrv_t:s0 key=(null)

Setting SELinux to permissive lets the server start

Version-Release number of selected component (if applicable):

389-ds-base-1.2.6-0.3.a3.fc12.x86_64

Steps to reproduce:

I think this is going to be difficult to reproduce. When trying to file this bug I checked on a few things, reset SELinux to enforcing and restarted the server and it worked.

Best I can guess is this only applies if you already have 389-ds running and you apply the upgrade. Could it be the label on /var/run/slapd-INSTANCE.socket changed?

Comment 1 Nathan Kinder 2010-04-20 20:47:49 UTC
(In reply to comment #0)
> Best I can guess is this only applies if you already have 389-ds running and
> you apply the upgrade. Could it be the label on /var/run/slapd-INSTANCE.socket
> changed?

Yes, the label changed from var_run_t to dirsrv_var_run_t.  The previous version of 389 that you upgraded from did not have a SELinux policy, so it ran as unconfined_t.

The AVC leads me to believe that the ldapi socket file is left around after stopping ns-slapd and then gets overwritten at start up.  This would mean that the newly upgraded ns-slapd starts running as dirsrv_t and tries to unlink the old ldapi socket file, which it is not allowed to do since it is var_run_t.  This would explain why things worked properly for you after you tried in permissive mode and then went back to enforcing since the file would have been recreated with the proper context.  I'll need to test to see if this theory is correct.

If this theory is indeed what is happening, it seems like we should not make ns-slapd be allowed to unlink var_run_t files.  The right thing would be to make the socket file be removed when the server is stopped and to have upgrade remove the socket file after stopping the server to allow us to upgrade from current releases.

Comment 2 Nathan Kinder 2010-04-20 20:59:10 UTC
I did confirm that the ldapi socket file is not removed when ns-slapd is stopped, so I believe my above theory is correct.

Comment 3 Rich Megginson 2010-04-20 21:07:13 UTC
So, three fixes:
1) change the server not to unlink the ldapi socket (but what should it do if there is already a socket there? just use it?)
2) change the server to unlink the ldapi socket at shutdown
3) add an upgrade scriptlet to remove the socket file

Comment 4 Nathan Kinder 2010-04-20 21:26:29 UTC
(In reply to comment #3)
> So, three fixes:
> 1) change the server not to unlink the ldapi socket (but what should it do if
> there is already a socket there? just use it?)

No, I think we should leave the unlink on startup just in case a server was killed ungracefully and the socket file was left around.  It is better to clean it up.  The only reason we get an AVC for this right now is since the last time the server was running, it was unconfined.

> 2) change the server to unlink the ldapi socket at shutdown

Yes.

> 3) add an upgrade scriptlet to remove the socket file    

Yes.

Comment 5 Nathan Kinder 2010-04-20 21:37:11 UTC
(In reply to comment #3)
> 2) change the server to unlink the ldapi socket at shutdown

I was just doing some tests, and there are some issues with trying to unlink the socket at shutdown.  The socket is created before we drop permissions, so it's owned by root.  This means we don't have permission to unlink the socket unless the server is running as root, which is discouraged.  This explains why the server currently attempts to unlink the socket at startup instead of shutdown.

I suppose we could just make the upgrade scriptlet to remove the socket file and make no other changes?

Comment 6 Rich Megginson 2010-04-20 21:50:35 UTC
(In reply to comment #5)
> (In reply to comment #3)
> > 2) change the server to unlink the ldapi socket at shutdown
> 
> I suppose we could just make the upgrade scriptlet to remove the socket file
> and make no other changes?    

ok - sounds good

Comment 7 Nathan Kinder 2010-04-21 20:59:17 UTC
Created attachment 408182 [details]
Proposed Patch

Comment 8 Nathan Kinder 2010-04-21 22:17:49 UTC
Pushed to master.  Thanks to Rich for his review!

Counting objects: 16, done.
Delta compression using 2 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (9/9), 1.36 KiB, done.
Total 9 (delta 6), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   2889536..b707395  master -> master

Comment 10 Amita Sharma 2011-06-24 09:12:05 UTC
Step Followed :

1. Make the Selinux enforcing.
2. Try to upgrade the 389-ds in online mode :

Which update mode do you want to use? [quit]: Online

==============================================================================
Please specify the authentication data for 'slapd-testvm'

Full DN of administrative user [cn=Directory Manager]: 
Password for this user: 
Finished successful update of directory server.
Please restart your directory servers.
Exiting . . .
Log file is '/tmp/setup3gR1Vo.log'

Is it fine to move it to VERIFIED state? or anything else required?

Comment 11 Nathan Kinder 2011-06-24 15:06:25 UTC
(In reply to comment #10)
> Step Followed :
> 
> 1. Make the Selinux enforcing.
> 2. Try to upgrade the 389-ds in online mode :
> 
> Which update mode do you want to use? [quit]: Online
> 
> ==============================================================================
> Please specify the authentication data for 'slapd-testvm'
> 
> Full DN of administrative user [cn=Directory Manager]: 
> Password for this user: 
> Finished successful update of directory server.
> Please restart your directory servers.
> Exiting . . .
> Log file is '/tmp/setup3gR1Vo.log'
> 
> Is it fine to move it to VERIFIED state? or anything else required?

You need to configure DS for ldapi prior to performing the updgrade.  You should also check the /var/log/audit/audit log for AVC messages that occur during the upgrade.

Comment 12 Amita Sharma 2011-06-27 08:22:03 UTC
Configured ldapi - nsslapd-ldapilisten: on
[root@testvm ~]# netstat -a | grep slapd
unix  2      [ ACC ]     STREAM     LISTENING     243998 /var/run/slapd-testvm.socket

To summarize:
  Online - servers remain running - you must provide admin name and password
           for each server - servers may need to be restarted
  Offline - servers must be shutdown - no username or password required

Which update mode do you want to use? [quit]: Online

==============================================================================
Please specify the authentication data for 'slapd-testvm'

Full DN of administrative user [cn=Directory Manager]: 
Password for this user: 
Finished successful update of directory server.
Please restart your directory servers.
Exiting . . .
Log file is '/tmp/setupNeOrQv.log'

Hance VERIFIED.


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