Web Hosting Talk : Web Hosting Main Forums : Programming Discussion : Control panel written in php - security question

[steve45]

Hi,

I am kind of new to PHP

I am developing a site, similar to control panel, where people could register for an account, and upload their web pages.

When people register an account, a folder will be created for the user, and will be named with his/her username. However this folder will be owned by the linuxuser “http” since pages will be uploaded by people via a control panel written in PHP. So folders allocated to users, and any file that gets uploaded via the control panel will all be owned by the linuxuser “http” with permission 755.

Customer authentication is performed using a table stored in MySql. No linuxuser account will be created when a person registers for a webspace/account.

Now this is my question:-
If a CUSTOMER uploads a script, lets say written in php to read any file accessible by the linuxuser “http”, wont he be able to see the contents of those files, including /etc/passwd ?

How do we prevent it? Or is there a better design?

[HivelocityDD]

Yes .. he might be able to see those details. One way to prevent this is enable the openbasedir option in php. So the scripts can only run inside the specific folders.

Another option I think is you create your own encryption algorithm by which you rename the files inside before storing and decrypt it when it needs to be downloaded.

[foobic]

Viewing /etc/passwd isn't that big a deal, but you'll have no good way to separate customers from each other. The "better design" is the conventional shared-hosting model where each customer is set up as a different linux user and every user is isolated by file ownership and permissions. If you go ahead with a system like you describe then you should aim to prevent your clients running their own scripts (ie. block execution of both cgi and php (edit: and ssi) in client-accessible areas).

Slightly OT: You might want to look at WordpressMU because it sounds like you may be reinventing it.

[steve45]

Yes I guess a "better design" is what I should be looking for. Should use linux users.
I found an article on net that seems to address my concern.
jimkeller.blogspot.com/2008/01/php-security-in-shared-hosting.html

Thanks a lot folks for your advises.
Regards.

[kieransimkin]

We found that the conventional shared hosting model was still weak from a security standpoint because many scripts tell you to chmod some of their files to world readable during the install process. This resulted in many of our users having mysql passwords stored and visible to anyone who was looking. Eventually someone did look and we were in trouble. PHP's openbasedir doesn't cover you completely because of SSI and CGI.

The solution that we came up with was to configure apache to run all PHP as CGI and then hack Apache's suexec.c to call chroot() before changing to the user. This gave us PHP that ran as the user chrooted to their home directory, which contained a copy of the FreeBSD base system hardlinked in. This effectively isolates each user and also discourages them from applying insecure file permissions because they're simply not needed. To this day we've had no further security problems.

I believe you can essentially do the things I describe now with suPHP and the like but I haven't tried as we're still using the CGI method with our custom apache patch.

Of course if you don't want your users to be able to run scripts at all then you needn't worry about any of this. But if you do, then I would strongly advise creating separate proper UNIX accounts for each of your users and having their scripts run as them. foobic's right it's not /etc/passwd you wanna be worried about, that file contains no plaintext passwords, but unfortunately eventually there will be other fils on your server that do.

[XCart]

You need to either forbid these kind of scripts or use jails for such scripts.

By the way, you could find browse sourforge.net , they may have this kind of management panel created already.

[alons]

Creating UNIX accounts is the only way to get out of the situation.
Otherwise users who have SSH access will be able to browse through all the files.