Question SElinux breaks Qmail in upgrade to Onyx

[southy]

Hi,

I have a machine, originally Plesk 12.5 on CentOS 7.
All was working fine.

Yesterday I upgraded to Onyx via the web-upgrade-Tool.

Today qmail won't accept SMTP connections any more:

# telnet localhost 25
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.

As all deamons seemed to be running fine, I checked SELinux:

/var/log/audit/audit.log
type=AVC msg=audit(1481709881.072:958): avc: denied { write } for pid=3482 comm="qmail-queue" path="pipe:[19640]" dev="pipefs" ino=19640 scontext=system_u:system_r:qmail_queue_t:s0 tcontext=system_u:system_r:qmail_start_t:s0 tclass=fifo_file
type=AVC msg=audit(1481709881.072:958): avc: denied { read } for pid=3482 comm="qmail-queue" path="pipe:[19641]" dev="pipefs" ino=19641 scontext=system_u:system_r:qmail_queue_t:s0 tcontext=system_u:system_r:qmail_start_t:s0 tclass=fifo_file
type=SYSCALL msg=audit(1481709881.072:958): arch=c000003e syscall=59 success=yes exit=0 a0=409776 a1=60d210 a2=7ffdf3c29998 a3=0 items=0 ppid=715 pid=3482 auid=4294967295 uid=2522 gid=2520 euid=2522 suid=2522 fsuid=2522 egid=31 sgid=31 fsgid=31 tty=(none) ses=4294967295 comm="qmail-queue" exe="/var/qmail/bin/qmail-queue" subj=system_u:system_r:qmail_queue_t:s0 key=(null)
type=AVC msg=audit(1481709881.075:959): avc: denied { read } for pid=3482 comm="qmail-queue" name="group" dev="vda1" ino=3396 scontext=system_u:system_r:qmail_queue_t:s0 tcontext=system_ubject_rasswd_file_t:s0 tclass=file

So, in order to get my system up and working again, I set SELinux to "permissive" - and immediately qmail starts to accept incoming connections again.

Apparently the upgrade breaks SElinux config or qmail requires additional permissions or... I don't know.

Is there any reference regarding how the thing is supposed to look like, how I can check that and how to get to where it should be? Is there a tool to re-set selinux to what it should be?
Does any of the Plesk-repair-tools reset selinux?

I found this documentation: https://linux.die.net/man/8/qmail_selinux
But with my very basic undertsnding of SELinux I'm not sure how to check these preconditions or how to adjust.

Also I see that I have almost 200 packets marked as"updates available", but it seems they do include qmail or SELinux, so I'll wait with that until stuff is sorted...?

Thanks for any help!
Southy

 

[Bitpalast]

Similar case discussed here: https://talk.plesk.com/threads/selinux-heads-up.337030/

 

[southy]

That case reffers to a OS upgrade being done before the problem occured.
I had CentOS 7 before already.
I just upgraded Plesk 12.5 -> Onxy.

But however, the suggestion in the thread is:
> Try to reinstall psa-selinux package after OS update.

So that would be:
# setenforce 0
# yum erase selinux\*
# rm -rf /etc/selinux
# yum install selinux-policy-targeted
# touch /.autorelabel
# reboot

Correct?
As I said, my SElinux background is very limited, but: aren't there plesk-specific configurations that might get lost that way?
Shouldn't those specific settings be part of one of the plesk repair scripts?

Honestly, I fear reinstalling might do more harm than good?!?

 

[southy]

Would
plesk repair installation
help here? According to this thread it appears to cover SElinux contexts.

 

[IgorG]

Would
plesk repair installation
help here? According to this thread it appears to cover SElinux contexts.

Yes. You can try at least.

 

[southy]

Yes. You can try at least.

Thanks for the heads-up and it did in fact show:

Restoring SELinux contexts...
Restoring SELinux context on '/usr/local/psa'
Restoring SELinux context on '/var/log/psa-horde'
Restoring SELinux context on '/var/qmail/alias'
Restoring SELinux context on '/var/qmail/bin'
Restoring SELinux context on '/var/qmail/boot'
Restoring SELinux context on '/var/qmail/control'
Restoring SELinux context on '/var/qmail/plugins'
Restoring SELinux context on '/var/qmail/popuser'
Restoring SELinux context on '/var/qmail/queue'
Restoring SELinux context on '/var/qmail/users'
Restoring SELinux context on '/var/db/kav'
Restoring SELinux context on '/var/db/Quarantine'
Restoring SELinux context on '/var/lib/plesk'
Restoring SELinux context on '/usr/libexec/postfix'
Restoring SELinux context on '/var/drweb'
Restoring SELinux context on '/opt/drweb'
Restoring SELinux context on '/usr/lib64/plesk-9.0'
Restoring SELinux context on '/etc/nginx'
Restoring SELinux context on '/usr/sbin/nginx'
Restoring SELinux context on '/var/lib/nginx'
Restoring SELinux context on '/var/log/nginx'
Restoring SELinux context on '/var/run/nginx.pid'
Restoring SELinux context on '/var/lib/plesk/mail'
Restoring SELinux context on '/opt/kav'
Restoring SELinux context on '/usr/lib64/php/modules'
Restoring SELinux context on '/var/run'
Restoring SELinux context on '/var/www/vhosts'
Restoring SELinux context on '/var/qmail/mailnames'
Restoring SELinux context on '/var/named/chroot'

...but setting SELinux back to "enforcing" still leads to the same result: SMTP won't accept connections.
How can that be? If plesk repair sets the contexts freshly based on its requirements, shouldn't it know what to set where?

 

[IgorG]

Have you updated to CentOS7.3 recently?

 

[southy]

The machine was installed ~6 months ago -> before 7.3 was released.
Two days ago I did the Plesk 12.5 -> Onyx upgrade via web frontend.
Today I updated a bunch of system packages.
Currently I have CentOS 7.3.1611 running.

I did never conciously update from 7.x -> 7.3, but as I don't know what actually is the specific characteristic for a small version number change (7.2 -> 7.3) in CentOS, both of these two updates of the last two days might have triggered this.

Looking at the timeline when SMTP broke and SElinux started performing odd, it probably has a connection with the Plesk upgrade (wasn't working _before_ todays packe updates)

I didn't notice that before. So it seems that there has been a CentOS upgrade with the Plesk upgrade. Could that be?
Then: Following your suggestion here shall I try to reinstall selinux? Basically, what could go wrong: I have deactivated it yet already - can't get any worse