Securing server without CloudLinux question

Ultimately, end-users need to learn about file permissions. If you are executing PHP as a per VirtualHost user (php-fpm, suphp, etc) - which most hosts are - then there's no reason for the world readable bit to be set for any wp-config.php. There's no reason for the world readable bit to be set on any php file for that matter.

But, that's asking for a whole lot. Why learn something when you can get someone else to do it for you? ... that's a separate soapbox and not entirely applicable here.

The other solution would be to wrap all CGI scripts through cPanel's jailshell. They already have the /usr/local/cpanel/bin/jailexec system written. It needs a bit of work, but could possibly be made to work.

But I don't think cPanel is too interested in actively developing a CageFS alternative. Doing so would be a main killer for CloudLinux.

 

I would suggest 0600 permissions. 0400 isn't going to let the owner of the file save any changes.

Wrapping CGI scripts through the jailexec system is probably a solution that needs to happen. cPanel is already allowing the chrooting of PHP through php-fpm. Would seem logical to do this with CGI as well. Or as you are attempting to do, disabling CGI entirely. Most everything is PHP these days. I'm sure there is still some CGI out there, but how much?

I think, though I may be wrong, the CGI box in account creation is referring to the cgi-bin directory. It used to be the case that all CGI scripts had to be put in the cg-bin directory (or the directory designated as ScriptAlias). With the advent of the cgi-script directive, this is no longer necessary. The cgi-bin directory is a relic of a way back era. When you leave that box unchecked, it doesn't create the cgi-bin directory (or ScriptAlias it), but cgi is still open due to the cgi-script directive.

 

0400 means the owner of the file has read access. That's it. If you can save changes to a file (and you're not root) that has 0400 permissions, then something is wrong.

You can probably view the file in the file manager to make changes, but you won't be able to save those changes. Unless the file manager is resetting the permissions.

You can probably turn off ExecCGI to prevent cgi scripts from executing outside of the cgi-bin directory. I don't know what all this may break in doing so. But that's kind of trivial because it can be added back into the .htaccess file. You can probably remove mod_cgid if you really don't want any CGI to run. I don't know what this will break, because some of cPanel's redirects (like account suspension and the default page) is controlled by CGI.

Again, the better solution would probably be to wrap all cgi scripts around a jailexec wrapper. That part wouldn't be all that difficult, but you've got to prevent cgi-script from being used in .htaccess files, which would require an edit some where within the Apache source code (I don't know where). That would seem to be the most viable solution. This would also allow administrators to add real cgi-script access to specific VirtualHosts through the Apache userdata include system if it is so required.

However, if cPanel built their own jail chroot for PHP and cgi execution, this would effectively nullify most of the advantages that CloudLinux's CageFS provides. I don't think they are all that willing to do that.