Post4VPS Forum | Free VPS Provider

Full Version: Consequences of disabling SELinux? VPS 9 Phoenix after KVM Upgrade
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
OK, so I've now fired up my VPS 9 Phoenix again.  I thought I'd be smart and go for an older version of CentOS - CentOS 6.5.  And guess what, I couldn't get access to the network with SSH with CentOS 6.5.  I then re-installed CentOS 7 and I was able to get access to the network again.  So guess Virmach has the upgraded VPS 9 Phoenix configured in such a way that it can't work with CentOS 6.5.  Or who knows, maybe it was a fluke.  

OK - we're now ready to disable SELinux.  But before I do it I'd like to understand why I need to do it and what the consequences are going to be for the VPS.

Like why is it not needed in the case of VPS 9 Seattle, which as we know was one of the first VPSs to go through the Virmach KVM upgrade process.  Like what happened in the later upgrades to cause the need for disabling SELinux?

Also, if disabled, exactly what will the consequences be for the VPS?

I tried to Google this, but can't completely wrap my brain cells around it.  What I do understand now is that SELinux stands for security enhanced Linux.  So immediately when it is disabled, the VPS has less protection than before it was enabled.  So why would Virmach recommend this on a massive scale for all of the upgraded VPSs?  Like we can't use Ubuntu, basically we are limited to CentOS, and now it would seem a CentOS that doesn't come with the protection that it has been designed for with SELinux?

Also, it would be nice if someone could create a simplified fool-proof tutorial for disabling SELinux that all of the VPS 9 users with issues can use.  The tutorial below is what I sourced with Google, but I'd like our experts here to have a look at it before I start down this road.

First challenge I may have is that when I last used my VPS Phoenix after the KVM upgrade - loaded with CentOS 7.0, it had yum issues.  Should I ignore all of that first, and then just go straight in disabling SELinux as follows?


It should come with an output like this one:

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      31

There is a temporary and permanent way that SELinux can be disabled.  Which is the better one - temporary or permanent?  

Temporary Disabling of SELinux

setenforce 0

Permanent Disabling of SELinux

Change SELINUX to disabled.  Output should be:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - No SELinux policy is loaded.
# SELINUXTYPE= can take one of these two values:
#       targeted - Targeted processes are protected,
#       mls - Multi Level Security protection.

Save the file and reboot with:

shutdown -r now

Then check the status of SELinux again:


Output should then look like this:

SELinux status:                 disabled

OK now if the above is successful, what should our next steps be to get CentOS 7.0 to operate perfectly?  I.e. to take care of all of the shortcomings that caused the need for SELinux to be disabled in the first place?
Well I'd not speak about the SELinux issue, as I amn't familiar with it, so it's better if describes about it.

Instead, I'd suggest you to implement the fix I've described in this thread:

as you're also a CentOS user and might be affected by the same trouble.

Well, just to mention, I liked your signature. Wink

that's is the way to go about doing it, Dean. nice one.

but what really stumps me is why would VPS 9 users need to disable selinux now on centos 7 ? selinux on hist has no effect on guest in case of KVM and keeping KVM enforced in both host and guest is the way to go (according to big guys. i personally like my permissive mode. never spent time learning selinux much). at the least in host.

with libvirt and KVM, selinux works by confining the Qemu binary, so that any attempts to break the guest boundary is stopped. That is why it is always recommended to have selinux set enforcing in both host and guest to maximise your level of protection (i hear it really works for people who know what they are doing and have spent time learning the hoops. that excludes me of course).

now one thing i can think of is if one is using a non default location for the virtual machines and forgot to issue commands to prepare that for selinux, due to a lot of work during upgrade . but i never saw such issues crop up from that.

so, in overall, this is a curious problem i am very much interested in and want to know the whys and hows of. just disabling might be a good temp solution for now.

selinux, even in warning (permissive) mode, is a good tool for warnings. just an added fence.

EDIT. for anyone with some time (50 minutes approximately) and a wish to learn selinux, here is a nice video tutorial..