Open Caffe1neAdd1ct opened 10 years ago
roundcube and phpmyadmin vhosts would be good, (keep mine at https://mysql.domain.com and https://webmail.domain.com) the rest should be locked down.
Could we not just implement 3 sub-domains on install??
Ask for the FQDN, webmail domain, & mysql domain in the installer?
I know it's more for the NOOBS to get their heads around but aren't we trying to phase them out anyway?
We could give them a docs link to look at first and acknowledge, and if they show up at the forums we just point them towards the docs link again.
I think /etc/app should run a different Vhost/ different context to improve permissions.
Let's say cp.zpanel.com:8080 a .htaccess could set a redirection so we don't get any major issues in menu's!
We can also beside different port add a suddomaine for access under port 80.
M B
We can also use .htaccess with auto_prepend_file. So all calls to files in the apps directory are first checked against login information.
/etc/zpanel/panel/etc/apps/.htaccess:
php_value auto_prepend_file "/etc/zpanel/panel/etc/apps/security.php"
With something like this:
/etc/zpanel/panel/etc/apps/security.php:
<?php
// For all 3rd-party applications, a good zpanel login should be necesarry.
// Therefor this file is include by .htaccess prepend functionality.
// So now we will check if the user is successfully logged in.
session_start();
if(!isset($_SESSION['zpuid'])) {
echo "No Authentication";
exit();
}
session_write_close();
(Didn't test is, so just theoretical)
I've thought about prepend file but wanted to avoid it if possible.
However that said it's a quick and easy fix!
I also feel phpmyadmin should definitely be restricted as it is used too many times before to collect information out of zpanel instances once attackers gained mysql root pass from the config files.
I'm not sure about separate vhosts as this would require more setting up on the user's behalf and not practical if hosting zpanel internally on a local server. However to get a similar setup we could add an openbase_dir restriction for each app along with the suhosin blacklist.
Something like:
<location /apps/phpmyadmin>
openbase_dir = "/apps/phpmyadmin"
blacklist = "shell_exec etc"
This way the apps can't do any file operations outside of their directories...
Thus my prior post over isolating completly the apps in a separate vhost where we could jail them and reduce permissions. Php my admin will not be an issue if we don't have mysql root under /cnf. Later we will manage to fix that too.
Phpmysysinfo should be moved off core and offered as third party module and we should keep only the essential apps in /etc/app as: webmail/phpmyadmin.
M B
I like the idea @MBlagui and @Caffe1neAdd1ct! - Isolate and jail the PHP functions that are not required! - You guys ok to start working on this?
Sorry, clicked the wrong button! - Re-opening issue :)
Yep ok for 1.1 and will be happy to team up with @Caffe1neAdd1ct over this.
Isolating the /app is key to improve security and we could also improve how webmail can accessed offer ing webmail.* for all domains and same for phpmyadmin. Sysinfo should be repackaged and set as an official module but no more in core.
M B
Personally I feel that all third-party app packages (that sit under /etc/apps/) should be offered as third-party add-ons only.In my opinion we should not be responsible for the bug fixes/potential issues that could arise from these packages.... These should be installed by the users and kept up to date by our new zppy upgrade functions of which I'm revisiting in the next couple of weeks!
On 19 October 2014 20:02, MBlagui notifications@github.com wrote:
Yep ok for 1.1 and will be happy to team up with @Caffe1neAdd1ct https://github.com/Caffe1neAdd1ct over this.
Isolating the /app is key to improve security and we could also improve how webmail can accessed offer ing webmail.* for all domains and same for phpmyadmin. Sysinfo should be repackaged and set as an official module but no more in core.
M B
— Reply to this email directly or view it on GitHub https://github.com/sentora/sentora-core/issues/56#issuecomment-59660663.
Webmail & phpmyadmin are very important for core. Unless we offer one click install. But removing them off sentora panel execution context & jailing them with suhosin would be contain any security breach/ flaw in these modules. Later adding a specific user under suEXEC will achieve this containment logic. I've been thinking about moving /etc/sentora/panel/etc/app to /etc/sentora/panel/app and creating a vhost for each module. Update indeed will be an issue but I think we can find solution for updating quickly those modules ( I see solutions). We should be able in the future to update core modules one by one too.
It will leave only pchart as the remaining third party in the panel. Notice we already jailed it with .htacces banning execution.
Zsudo will follow too as discussed in the forum and I think we have a good solution for backward compatiblity and avoid any bypass.
Webmail and phpMyAdmin may seem important for core but realistically I think that given they are third-party and just 'management' tools they should be made into third-party modules and installed as and when required by the users... maybe the installer at the end could ask say 'Would you like to download and install the latest phpMyAdmin and RoundCube clients now?' - There is a miriad of other web-based MySQL database managers and webmail clients that we could also provide.
Can you link the Zsudo discussion for me please?
On 19 October 2014 20:19, MBlagui notifications@github.com wrote:
Webmail & phpmyadmin are very important for core. Unless we offer one click install. But removing them off sentora panel execution context & jailing them with suhosin would be contain any security breach/ flaw in these modules. Later adding a specific user under suEXEC will achieve this containment logic. I've been thinking about moving /etc/sentora/panel/etc/app to /etc/sentora/panel/app and creating a vhost for each module. Update indeed will be an issue but I think we can find solution for updating quickly those modules ( I see solutions). We should be able in the future to update core modules one by one too.
It will leave only pchart as the remaining third party in the panel. Notice we already jailed it with .htacces banning execution.
Zsudo will follow too as discussed in the forum and I think we have a good solution for backward compatiblity and avoid any bypass.
— Reply to this email directly or view it on GitHub https://github.com/sentora/sentora-core/issues/56#issuecomment-59661268.
tagged you in the forum check your PM inbox
Looking into this. Roundcube should be ok for now. Mysql needs this auth lockdown.
I access phpMyAdmin very frequently without being logged into my panel since I do a lot of web design. Logging into the panel to work with databases is not a suitable solution. Lock them down with snuffleupagus/suhosin and maybe a custom vhost entry.
Third party applications reside in /etc/zpanel/panel/etc/apps/ and are publicly available.
Tighter security could be implemented to stop anyone using these applications unless they have authenticated with the sentora panel first.
1) Find a way to check sentora authentication before allowing each request inside this folder. 2) Implement restriction 3) Move roundcube to a virtual host of it's own as this app shouldn't be under such restrictions. 4) Webalizer can be restricted further to make sure the logged in username matches the url requested