How to fix error: Apache vhosts are not segmented or chroot()ed? we have enabled Jailed Shell but error still are not removed.
Hello,
You'd need to use Mod_Ruid2 with the "EXPERIMENTAL: Jail Apache Virtual Hosts using mod_ruid2 and cPanel® jailshell" option enabled in "WHM >> Tweak Settings". Or, you'd need to use CageFS with CloudLinux.
Thank you.
You'd need to use Mod_Ruid2 with the "EXPERIMENTAL: Jail Apache Virtual Hosts using mod_ruid2 and cPanel® jailshell" option enabled in "WHM >> Tweak Settings". Or, you'd need to use CageFS with CloudLinux.
Thank you.
So we need enable Mod_Ruid2 for use "EXPERIMENTAL: Jail Apache Virtual Hosts using mod_ruid2 and cPanel® jailshell" option enabled in "WHM >> Tweak Settings"? Ones enabled option "EXPERIMENTAL: Jail Apache Virtual Hosts using mod_ruid2 then Can disabled Mod_Ruid2?
That's correct, you will need to enable both Mod_Ruid2 and the "EXPERIMENTAL: Jail Apache Virtual Hosts using mod_ruid2 and cPanel® jailshell" option. Disable Mod_Ruid2 after enabling the option will automatically disable the option, as Mod_Ruid2 is required for it to work.
Thank you.
It sounded like maybe he was asking more DO we need to enable...
I'm wondering the same thing. This warning shows as critical on the list from the system analyzer, yet it seems like this is not a security issue or setting included in the base setup, but more of a hack/fix.
So: is it something that should absolutely be done on our dedicated servers? Or is it something that is really only necessary on shared servers with potentially malicious users?
I'm wondering the same thing. This warning shows as critical on the list from the system analyzer, yet it seems like this is not a security issue or setting included in the base setup, but more of a hack/fix.
So: is it something that should absolutely be done on our dedicated servers? Or is it something that is really only necessary on shared servers with potentially malicious users?
Hello @kwdamp,
Good question! We do recommend taking steps to ensure Apache virtual hosts are segmented or chroot()ed. While Mod_Ruid2 and the "Jail Apache" option together is one way to achieve this, using CageFS with CloudLinux is ideal if you are able to purchase a CloudLinux license. Note we have an internal case (SWAT-733) open to ensure that specific Security Advisor alert reflects the fact that Mod_Ruid2 is required in order to use the "Jail Apache" option.
Thank you.
Good question! We do recommend taking steps to ensure Apache virtual hosts are segmented or chroot()ed. While Mod_Ruid2 and the "Jail Apache" option together is one way to achieve this, using CageFS with CloudLinux is ideal if you are able to purchase a CloudLinux license. Note we have an internal case (SWAT-733) open to ensure that specific Security Advisor alert reflects the fact that Mod_Ruid2 is required in order to use the "Jail Apache" option.
Thank you.
Is it correct that this risk only exists if malicious users exist on the server (whether they get in by hacking an account login or have one assigned to them)?
The scenario I'm referring in particular is a dedicated server, where all accounts are under my control, and all user accounts are set to "Disabled Shell" in Home »Account Functions »Manage Shell Access. Doesn't that eliminate the concern entirely?
Please advise...
The scenario I'm referring in particular is a dedicated server, where all accounts are under my control, and all user accounts are set to "Disabled Shell" in Home »Account Functions »Manage Shell Access. Doesn't that eliminate the concern entirely?
Please advise...
That's correct. Though do note that disabling shell access to the account doesn't mitigate the issue.
Thank you.
Good point. I shouldn't have even mentioned the shell access setting. This doesn't represent an immediate concern for me because I am the only user, that could change in the future, and I'm sure for many others this is a current concern. Which leads me to this question:
HTTP/2 seems to be a forward looking standard but enabling mod_HTTP/2 requires the removal of mod_ruid2. Therefore are we to understand that the only available solution is to purchase and run CloudLinux? Is it really the case that if you want to move to HTTP/2 and don't want to run CouldLinux you're just stuck with a security hole, or is there more to this story?
That's correct. Without the Ruid2/Jail Apache functionality (which doesn't allow the use of HTTP/2), the only supported alternate solution at this point in time is to use a third-party product such as CloudLinux.
Thank you.
What about chrooting in a php-fpm environment. There's some discussion scattered throughout the the Feature Request for Enhanced FPM Support, but specifically:
Enhance FPM support
Has this been completely abandoned?
The jailmount for cPanel needs a little bit of work (it doesn't mount everything). I'm pretty sure I've mentioned that some where, but I can't remember where.
This doesn't solve CGI execution. Although that could be improved and possibly solved with some help from cPanel and Apache.
This doesn't provide complete isolation like CloudLinux does. But, how else do end users execute code in a shared hosting environment? Shell (jailshell solves this) or PHP (chroot'd php-fpm solves this) or CGI (no current solution). How much is CGI actually used any more?
Enhance FPM support
Has this been completely abandoned?
The jailmount for cPanel needs a little bit of work (it doesn't mount everything). I'm pretty sure I've mentioned that some where, but I can't remember where.
This doesn't solve CGI execution. Although that could be improved and possibly solved with some help from cPanel and Apache.
This doesn't provide complete isolation like CloudLinux does. But, how else do end users execute code in a shared hosting environment? Shell (jailshell solves this) or PHP (chroot'd php-fpm solves this) or CGI (no current solution). How much is CGI actually used any more?
Hello @sparek-3
Per our PHP FPM User Pools document:
Thank you.
Per our PHP FPM User Pools document:
Thus, even when using PHP-FPM, Mod_Ruid2 and the "Experimental: Jail Apache Virtual Hosts using mod_ruid2 and cPanel® jailshell" option are still required so the system automatically binds the user pool to the virtfs mount.
Thank you.
You may want to double check this.
Mod_Ruid2 and the "Experimental: Jail Apache Virtual Hosts using mod_ruid2 and cPanel® jailshell" aren't required for PHP-FPM to run in a chroot'd environment. At least not in what I have tested.
Using PHP-FPM and creating the /var/cpanel/feature_toggles/apachefpmjail file and insuring that the user is using noshell or jailshell as their shell, executes PHP through the php-fpm socket for that user in a chroot'd environment.
Perhaps I have my system misconfigured? If so, I don't want to fix it.
Granted, the jailmount that cPanel's modified php-fpm binary does to run the code in the chroot leaves a bit to be desired - it doesn't fully mount the /home/virtfs/%user% path. (The fix: login as the user using jailshell, and the path gets fully populated). But other than that, it seems to operate just as expected.
I've often wondered why this didn't get much fanfare, but perhaps that's because the right hand doesn't know what the left hand is doing.
One of the key features of CloudLinux is the CageFS system. But cPanel essentially has the same thing already baked in, with their jail system. But for whatever reason cPanel doesn't want to expand on this jail system and seems to just want to to forget that it's there, and then push people over to CloudLinux for CageFS.
Mod_Ruid2 and the "Experimental: Jail Apache Virtual Hosts using mod_ruid2 and cPanel® jailshell" aren't required for PHP-FPM to run in a chroot'd environment. At least not in what I have tested.
Using PHP-FPM and creating the /var/cpanel/feature_toggles/apachefpmjail file and insuring that the user is using noshell or jailshell as their shell, executes PHP through the php-fpm socket for that user in a chroot'd environment.
Perhaps I have my system misconfigured? If so, I don't want to fix it.
Granted, the jailmount that cPanel's modified php-fpm binary does to run the code in the chroot leaves a bit to be desired - it doesn't fully mount the /home/virtfs/%user% path. (The fix: login as the user using jailshell, and the path gets fully populated). But other than that, it seems to operate just as expected.
I've often wondered why this didn't get much fanfare, but perhaps that's because the right hand doesn't know what the left hand is doing.
One of the key features of CloudLinux is the CageFS system. But cPanel essentially has the same thing already baked in, with their jail system. But for whatever reason cPanel doesn't want to expand on this jail system and seems to just want to to forget that it's there, and then push people over to CloudLinux for CageFS.
Hello,
While it's not required, we recommend enabling the Experimental: Jail Apache Virtual Hosts using mod_ruid2 and cPanel® jailshell option. When PHP-FPM jails are active (e.g. /var/cpanel/feature_toggles/apachefpmjail exists and noshell or jailshell is enabled for a user), it causes PHP-FPM to attempt to chroot to virtfs for that user. However, it only verifies the jail is mounted (as opposed to fully setup and populated). This presents a problem when Mod_Ruid2 and the Experimental: Jail Apache Virtual Hosts using mod_ruid2 and cPanel® jailshell option are not enabled because PHP-FPM can potentially attempt to chroot into an incomplete jail environment. Internal case EA-5524 is open to address this behavior.
Thank you.
For me this option is greyed out, so, what do i do?
You have to install Mod_Ruid2 on the system using WHM >> EasyApache 4 in order to allow that option to be enabled. Note some modules are not compatible with Mod_Ruid2 (e.g. suPHP). WHM >> EasyApache 4 will prompt you if any modules currently installed on your server are not compatible with Mod_Ruid2 when you go to enable it under the Apache Modules section in the interface.
Thank you.
When i go to turn it on i get this list:
The following conflicts are installed on this machine. They will be removed as part of this package selection:
mod_mpm_worker
mod_cgid
mod_suphp
mod_suexec
What do these things do? would i miss them?
The following conflicts are installed on this machine. They will be removed as part of this package selection:
mod_mpm_worker
mod_cgid
mod_suphp
mod_suexec
What do these things do? would i miss them?
Hello,
It means that Mod_Ruid2 is not compatible with some of the existing RPMs installed as part of your EasyApache 4 profile. If you were to install Mod_Ruid2, you'd have to remove those RPMs and thus would require that you use a different MPM and uninstall suPHP. If you prefer to use the Worker MPM and suPHP on the server, then you won't be able to use Mod_Ruid2 and thus would need to use something like CageFS to address that warning in Security Advisor.
Thank you.
It means that Mod_Ruid2 is not compatible with some of the existing RPMs installed as part of your EasyApache 4 profile. If you were to install Mod_Ruid2, you'd have to remove those RPMs and thus would require that you use a different MPM and uninstall suPHP. If you prefer to use the Worker MPM and suPHP on the server, then you won't be able to use Mod_Ruid2 and thus would need to use something like CageFS to address that warning in Security Advisor.
Thank you.
I don't understand, to my knowledge this is a stock install of WHM, why is the security adviser advising that the settings presumably setup by cPanel inc. as the default ones are not good enough while it needs some serious re configuration to sort this out? I thought that buying commercial software would mean that it would work rather that warn me against itself's in built vulnerabilities!
what is "suPHP" and "WORKER" ?what do they do for me? what do i replace them with ?
SSH is disabled, isn't this enough?
what is "suPHP" and "WORKER" ?what do they do for me? what do i replace them with ?
SSH is disabled, isn't this enough?
Hello @Thunderchild,
We consider both security and functionality when deciding on the default options enabled as part of new cPanel & WHM installations.
The advice you see in WHM >> Security Advisor is intended to provide you with information to help increase your server's security, but sometimes the most secure configuration isn't the most functional for the websites that you host. Security Advisor is intended to provide you with information to help improve your server's security, but it's ultimately up to you and/or your system administrator if you take that advice. We're happy to help if you have questions about a specific warning that's presented in Security Advisor.
Multi-Processing Modules - MPMs - EasyApache 4 - cPanel Documentation
suPHP is a PHP handler. We document the available PHP handlers and their requirements at:
PHP Handlers - EasyApache 4 - cPanel Documentation
Thank you.
We consider both security and functionality when deciding on the default options enabled as part of new cPanel & WHM installations.
The advice you see in WHM >> Security Advisor is intended to provide you with information to help increase your server's security, but sometimes the most secure configuration isn't the most functional for the websites that you host. Security Advisor is intended to provide you with information to help improve your server's security, but it's ultimately up to you and/or your system administrator if you take that advice. We're happy to help if you have questions about a specific warning that's presented in Security Advisor.
MPM stands for Multi-Processing Module and we document how each option works at:
Multi-Processing Modules - MPMs - EasyApache 4 - cPanel Documentation
suPHP is a PHP handler. We document the available PHP handlers and their requirements at:
PHP Handlers - EasyApache 4 - cPanel Documentation
No, the option in-question will chroot() a user's Apache Virtual Host into the jailshell environment. Disabling SSH access on your accounts doesn't do that and doesn't negate the security issue addressed by this option or by an alternative such as CageFS.
Thank you.