Change of /etc/selinux/config's SELINUX causes port389 fail to start

[Lutz Berger]

Hi,

IHAC who wants to use ( under RHEL 7.2 ):

/etc/selinux/config with
SELINUX=enforcing


Changing the SELINUX setting from "permissive" to "enforcing" and
rebooting afterwards causes port389 DS fail to start due to
a permission problem of /var/run/dirsrv

Interestingly, the ownership of /var/run/dirsrv changed from 
port389:port389 to dirsrv:dirsrv
after reboot.

But, changing the ownership and permissions on the /var/run/dirsrv ( 
which is actually nsslapd-rundir )
back to its original value, doesn't help, i.e. port389 DS doesn't start 
anymore.

A fresh install with setup-ds-admin.pl "solves" my issues.

Question:
What side effects does a change of SELINUX cause with regards to port389?

The issue can be reproduced with changing the setting from
"enforcing" to "permissive" as well.

Any ideas?

Thanks and best regards,
   Lutz

[William Brown]

On Thu, 2016-04-07 at 17:35 +0200, Lutz Berger wrote:
>  Hi,
>  
>  IHAC who wants to use ( under RHEL 7.2 ):
>  
>  /etc/selinux/config with
>  SELINUX=enforcing
>  
>  
>  Changing the SELINUX setting from "permissive" to "enforcing" and
>  rebooting afterwards causes port389 DS fail to start due to
>  a permission problem of /var/run/dirsrv
>  
>  Interestingly, the ownership of /var/run/dirsrv changed from 
>  port389:port389 to dirsrv:dirsrv
>  after reboot.
>  
>  But, changing the ownership and permissions on the /var/run/dirsrv ( 
>  which is actually nsslapd-rundir )
>  back to its original value, doesn't help, i.e. port389 DS doesn't start 
>  anymore.
>  
>  A fresh install with setup-ds-admin.pl "solves" my issues.
>  
>  Question:
>  What side effects does a change of SELINUX cause with regards to port389?
>  
>  The issue can be reproduced with changing the setting from
>  "enforcing" to "permissive" as well.
>  
>  Any ideas?
>   
When you change from permissive to enforcing, you often need to re-label to make
sure the system is consistent.

sudo touch /.autorelabel
sudo reboot

After that, you can then examine what is causing the permission failures with the
following:

ausearch -ts recent 

Look for lines that have avcs, ie 

type=AVC msg=audit(1459987563.071:49221): avc:  denied  { write } for  pid=2489
comm="krb5kdc" name="pac" dev="dm-4" ino=181
scontext=system_u:system_r:krb5kdc_t:s0
tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=sock_file

This is not a dirsrv error, but this what the line will "look like"


If you want to temporarily set the dirsrv to be permissive so you can analyse the
issue;

First, check that ns-slapd has the right context:

ps auxZ | grep -i ns-slapd

It should be :

system_u:system_r:dirsrv_t:s0   dirsrv     854  0.1 12.2 1755728 230988
?      Sl   Mar26  35:20 /usr/sbin/ns-slapd....

Note the selinux label (-Z on many commands will show you selinux features)

Then to set *just* dirsrv to permissive rather than the whole system:

sudo semanage permissive -a dirsrv_t 


I recomend that if you have issues with enforcing, to do the relabel, set just
dirsrv to permissive, then to analyse the output with ausearch to find other
denials. From there, you may get hints to the problem.

I hope that helps you,

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane

[Gordon Messmer]

On 04/07/2016 03:15 PM, William Brown wrote:
>  When you change from permissive to enforcing, you often need to
> re-label to make
>  sure the system is consistent. 
 From "permissive"?  I know that's true if a system is set to enforcing 
from "disabled" but I've never seen an indication that switching from 
permissive would require a re-label.

Do you know what would cause permissive mode to mislabel filesystem objects?

[William Brown]

On Thu, 2016-04-07 at 15:27 -0700, Gordon Messmer wrote:
>  On 04/07/2016 03:15 PM, William Brown wrote:
>  > 
>  > When you change from permissive to enforcing, you often need to re-label to
>  > make
>  > sure the system is consistent.
>   From "permissive"?  I know that's true if a system is set to enforcing 
>  from "disabled" but I've never seen an indication that switching from 
>  permissive would require a re-label.
>  
>  Do you know what would cause permissive mode to mislabel filesystem objects? 

When you go from disabled to permissive, then to enforcing, this is very true,
because then no objects have labels.

The issue with permissive to enforcing, is that people may have been mv-ing
directories around, putting things in the wrong locations (so they have the
correct label for where they are, but wrong relative to the application). 

There certainly won't be as many issues as disabled -> permissive, but there are
still enough subtle things that can change an go wrong, that it's worth the
relabel to be sure that your issues going from perm -> enforce are not related to
mislabeling, but perhaps other issues.



-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane

[Gordon Messmer]

On 04/07/2016 08:35 AM, Lutz Berger wrote:
>  Changing the SELINUX setting from "permissive" to
> "enforcing" and
>  rebooting afterwards causes port389 DS fail to start due to
>  a permission problem of /var/run/dirsrv
>
>  Interestingly, the ownership of /var/run/dirsrv changed from 
>  port389:port389 to dirsrv:dirsrv
>  after reboot. 
Just to check the obvious, those users have different UIDs on the 
system, right?

SELinux isn't related to the ownership of files in /run (the target of 
the /var/run symlink).  Those files ownership are defined in 
/etc/tmpfiles.d/*

If the ownership of that directory changed, then you may have 
conflicting definitions in /etc/tmpfiles.d, or someone may have made an 
unrelated change that replaced or modified those files.

I'm confident that whatever broke your system was not the change from 
permissive to enforcing mode in SELinux.

>  But, changing the ownership and permissions on the /var/run/dirsrv (
>
>  which is actually nsslapd-rundir )
>  back to its original value, doesn't help, i.e. port389 DS doesn't 
>  start anymore.
>
>  A fresh install with setup-ds-admin.pl "solves" my issues. 
That being the case, there probably were more ownership changes than 
you've described.

[William Brown]

On Thu, 2016-04-07 at 15:33 -0700, Gordon Messmer wrote:
>  On 04/07/2016 08:35 AM, Lutz Berger wrote:
>  > 
>  > Changing the SELINUX setting from "permissive" to "enforcing"
> and
>  > rebooting afterwards causes port389 DS fail to start due to
>  > a permission problem of /var/run/dirsrv
>  > 
>  > Interestingly, the ownership of /var/run/dirsrv changed from 
>  > port389:port389 to dirsrv:dirsrv
>  > after reboot.
>  Just to check the obvious, those users have different UIDs on the 
>  system, right?
>  
>  SELinux isn't related to the ownership of files in /run (the target of 
>  the /var/run symlink).  Those files ownership are defined in 
>  /etc/tmpfiles.d/*
>  
>  If the ownership of that directory changed, then you may have 
>  conflicting definitions in /etc/tmpfiles.d, or someone may have made an 
>  unrelated change that replaced or modified those files.
>  
>  I'm confident that whatever broke your system was not the change from 
>  permissive to enforcing mode in SELinux.
>  
>  > 
>  > But, changing the ownership and permissions on the /var/run/dirsrv ( 
>  > which is actually nsslapd-rundir )
>  > back to its original value, doesn't help, i.e. port389 DS doesn't 
>  > start anymore.
>  > 
>  > A fresh install with setup-ds-admin.pl "solves" my issues.
>  That being the case, there probably were more ownership changes than 
>  you've described. 

I missed this part of the email it would seem.

You should check who the dirsrv process user is in dse.ldif, because that may
still have the old port389 user listed rather than dirsrv.

dn: cn=config
nsslapd-localuser: USERNAME


That would certainly cause issues if the other uid/gid permissions of the FS has
changed around you.


However, I would like to know what distro / versions you are running? I'm not
aware of a distro that ships a port389 user. Historically DS ran as
nobody:nobody, and only recently swapped to dirsrv:dirsrv.



-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane