Installer script disables SELinux

CyberPanel Project Bug Report
1

cyberpanel.sh installer disables SELinux entirely for the system, after setting it to permissive settings.

I am not an expert, but I have to wonder, if you guys are setting SEL to ‘permissive’, why not just leave it enabled?

Disabling it causes security problems and makes it that much more impossible to uninstall CyberPanel.

I’ve been making an uninstall script, and while talking to Gemini to investigate what the installer does to the system, I managed to brick my VPS. I can no longer SSH into it.

The reason it stops accepting SSH connections is that my uninstaller undoes the ‘permissive’ setting for SEL, but when it does that, it causes the kernel and the SEL settings to conflict with one another, which makes the machine unreachable.

Can you guys maybe not disable SELinux? It’s a pretty important piece of security software to have running on a Linux machine. I mean, the US government made it and open-sourced it, and the Linux kernel added it to the kernel repo for a reason. It’s like, REALLY freaking important to keep it enabled.

[root@vmi2662026 local]# grep "denied" /var/log/audit/audit.log

the command yields a typical output of something like this:

type=AVC msg=audit(1751202884.643:1616): avc:  denied  { transition } for  pid=7395 comm="(systemd)" path="/usr/lib/systemd/systemd" dev="sda4" ino=51t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process permissive=0
type=AVC msg=audit(1751202884.733:1622): avc:  denied  { dyntransition } for  pid=7399 comm="sshd" scontext=system_u:system_r:kernel_t:s0 tcontext=unctclass=process permissive=0

where permissive=0 indicates the SELinux setting (enforced/not permissive) that conflicts with the state of SELinux (disabled).

Why not to ever disable SEL:

Setting SELinux to “permissive” mode would likely have been sufficient to prevent it from blocking the installer’s operations while still allowing it to log potential issues. The script currently uses setenforce 0 to immediately put SELinux into permissive mode, and then modifies the configuration file to SELINUX=permissive. Disabling it entirely (setting SELINUX=disabled) would prevent it from logging anything and effectively turn off its security features.

2

Thank you for raising this important security topic. You’re right that SELinux is a valuable security layer, and we understand your concerns. Let me provide some context and address your suggestions.

Why CyberPanel Disables SELinux

  1. Industry Standard Practice: Most web hosting control panels (including cPanel, Plesk, and DirectAdmin) either disable SELinux or require it to
    be disabled. cPanel’s official documentation states: “We do not support SELinux” and recommends disabling it for proper functionality.
  2. Compatibility Issues: Web hosting control panels manage multiple complex services (web servers, mail servers, DNS, FTP, databases) that
    require specific file permissions and inter-process communications. SELinux policies often conflict with these requirements, causing:
    - File permission errors
    - Service communication failures
    - Backup/restore problems
    - Email delivery issues
  3. Support Complexity: With SELinux enabled, troubleshooting becomes exponentially more complex. Each issue requires checking SELinux contexts,
    which significantly increases support burden.

Regarding Uninstallation

The uninstall issues you experienced shouldn’t be related to SELinux being disabled. If you’re having trouble uninstalling, please create a separate thread and we’ll help you resolve it.

We appreciate your security-conscious approach and will definitely consider making SELinux handling more flexible in future releases. Security is important to us too, which is why we also implement other security measures like ModSecurity, CSF integration, and secure default configurations.

3

A few things to respond to here:

1st, I have to correct my earlier analysis: The machine was unreachable not because of SELinux misconfiguration. It may have been for another reason involving OpenLiteSpeed server uninstallation. I left OLS installed and it seems to work OK after a reboot.

There are some inconsistencies in my analysis so I may have the wrong culprit, but that is what I did. Still not sure why the SELinux status had both SELinux disabled while the configuration file stated it was set to enforce after my script ran.

Complicating factor: I freaked out during the uninstaller process and canceled a kernel upgrade, because I am not familiar with dnf and it decided to list the kernel upgrade as a kernel install, followed by a wall of text, followed by a kernel removal (listed as “unneeded dependencies LOL”). So I thought the kernel was being deleted entirely and smashed Ctrl-C over and over.

4

Thank you for your patience. I’ve analyzed our installation code to provide accurate context about SELinux handling.

Current Implementation

  1. SELinux Check Function Exists But Not Called

The installer has a checkIfSeLinuxDisabled() function that:

  • Runs sestatus command
  • Accepts both “disabled” and “permissive” states
  • Only exits installation if SELinux is “enforcing”

However, this function appears to not be actively called during the main installation flow.

  1. SELinux Configuration During Installation

Instead, the installer runs fix_selinux_issue() which:
setsebool -P httpd_can_network_connect 1
This sets an SELinux boolean to allow httpd network connections, suggesting the installer attempts to work with SELinux rather than requiring it
to be disabled.

  1. The Discrepancy Explained

Your observation about SELinux being disabled despite the config showing “enforcing” likely happens because:

  • Many VPS providers disable SELinux at the kernel level (selinux=0 in boot parameters)
  • CyberPanel’s installer doesn’t actively disable SELinux
  • The /etc/selinux/config file remains unchanged

Why Industry Practice Differs from Code

While our code shows some SELinux compatibility attempts, in practice:

  1. Most users and providers pre-disable SELinux
  2. Full SELinux support would require extensive policy writing
  3. Support complexity increases significantly with SELinux enabled

Moving Forward

Your feedback highlights that we should:

  1. Either fully support SELinux with proper policies
  2. Or be transparent about requiring it disabled
  3. Update our installer to handle SELinux more consistently

The current middle-ground approach (having checks that aren’t used, partial SELinux commands) creates confusion.

Thank you for prompting this code review - it reveals areas where our implementation could be clearer and more consistent with our documentation.