Prevent Users from reading other webroots

use phpsuexec or suphp..runs php as user not apache module

 

phpsuexec will fix that problem - but it can also cause some problems as well.

 

I've been using suexec and phpsuexec for a long time. I like it better because everything in your own directory runs under your own account. So, you don't have to worry about making any folders world readable or writable as far as php goes, since php runs under the owner group.

Go for it!

 

Other security items

1. The "Prevent other users.." option MIGHT only apply to new accounts, as it sets the top level directory permissions (I do not know if it modifies existing accounts)

2 In WHM 11 SecurityCenter (you can also set directly in php.ini)
PHP's open_basedir protection prevents users from opening files outside of their home directory with PHP.

3 If you allow shell access, be sure to either disable shell access or use "jailed shell" for all accounts (except your own of course)

 

That is precisely what PHP's OpenBaseDir restrictions are all about ....

When you activate "OpenBaseDir" either manually or in the "Security Center" in WHM,
it modifies PHP so that every account is only able to access files within their own
directory tree irregardless how you have PHP actually configured to run under Apache.

If you attempted to run your sample script above on a server where OpenBaseDir
restrictions had been activated and the script wasn't being run from neighbour's
account then the script would abort with an error telling you that OpenBaseDir
restrictions were in effect and you would not be able to read the file.

You can actually take things a big step further than that by running either
phpSuExec (which I don't recommend for weakened security and performance reason)
or by running SuPHP which gives you the same functionality and capabilities
of phpSuExec without any of the negative downsides to running it. Either of
these two options will run all scripts as the account owner instead of user "nobody"
which allows you to go beyond OpenBaseDir restrictions and actually block access
by the use of file and folder ownership and permission settings.

I generally recommend that all servers have OpenBaseDir enabled and that
the server be configured to use both SuPHP (For PHP) and SuExec (For Perl scripts)
and set the main public_html folder to something more restrictive like 0750
with account login owner and 'nobody' group and set the permission settings
on your individual PHP scripts inside public_html to 600 or 400 with both
owner and group set to the account owner's login name for those scripts
along with permission 640 or 644 for non-script files. Perl scripts likewise
could be set as tightly as 700 or 750 when SuExec is active. Configured in
this manner, you shouldn't have any problems with cross site scripting
or users on the server reading other users files on the same server.

I generally do not recommend allowing any shell access of any kind to end users!

Jailed shell restrictions cannot be guaranteed to be enforced and it is far too trivial
and easy to escalate to full shell once you are logged in under a jailed shell.

The vast majority of users have no legitimate need to have shell access and those
who request it to install a local program don't need it either because requests like
that could be handled by the server administrator to setup custom programs for
the end user. It is EXTREMELY RARE for any end user to really legitimately need
any kind of shell access whatsoever.

In the same respect, I'm a bit leery as a security professional in allowing cronjob
access because most anything you can do in full SSH shell access, you can also
do from crontabs. I have cracked many a server using just the end user crontabs
to help the server owners back into root access once their root password was
forgotten who otherwise didn't have console access.

Actually it's kind of funny because most cronjobs that user's setup don't even need
to be setup as cronjobs. Often there is better ways to have the same effect as
cronjobs from my scripts without the actual real need for cronjobs. Those few
who do really need cronjobs, I usually leave the end user access disabled from
Cpanel and go and setup the cronjob on their behalf under their username from
/var/spool/cron via a support request from the end user.



.