suPHP, suExec and open_basedir oh my!

[Evolve]

I am at a loss. I have suPHP, suExec and open_basedir installed on my server and today I decided to use some PHP code from one account and put it on another account to work on. I discovered that the code on the new account had no problem executing the database connection code from the old account's root! I could even echo out the file contents from the other account and see the database passwords plain as day. Thank god I manage all of the sites on my server.

My main concern is that I can execute the files in another accounts web root or anywhere just by knowing their username and the file name.

echo file_get_contents('/home/otherUser/file.php');

Am I wrong in assuming that the purpose of suExec and suPHP is to lock down files to the account's user?

While I can't find an explanation stating that I just assumed it was true. Here is something I found that sort of backs up my assumption:

PHP Files are not meant to be read, but parsed, otherwise everyone who is able to read your php file will able to view settings that you would want to keep private, such as your MySQL username and password.

SuPHP fixes this issue because it requires PHP scripts to be executed with the permissions of their owners.

What am I missing here?

Btw I realized recently that open_basedir doesn't work out of the box with suPHP and have found the thread where Tristan explains how to lock down php.ini files. I will do this after I figure out what's going on.

I'm using PHP 5.4

 

[ThinIce]

Potentially stupid question, but what are the permissions on the files in question? What version of PHP are you using to test? Many cms auto install their scripts config / sensitive files and leave them with 644 permissions, whereas they'd be better off as lower (i.e others cannot read). While settings like safe mode have come and gone, in the end it's the linux permissions that are the final protection.

Things along the lines of this have come as a nasty shock in a variety of cases (for example the symlink issue where readable config files with 'normal' permissions can be harvested from the server)

http://forums.cpanel.net/f185/solutions-handling-symlink-attacks-202242.html

 

[cPanelMichael]

Hello

I recommend checking the ownership values for the files in question. Check to see if they are owned by the appropriate user. Also, you mentioned installing suPHP. Did you ensure it was selected as the PHP handler in Web Host Manager(Home » Service Configuration » Configure PHP and suEXEC)?

Thank you.

 

[Evolve]

The file I am executing in account1 is owned by account1 and has 644 permissions. If I change the permissions to 640 then it gets blocked from account2. Is this something I'm going to have to do to protect my files from other users??

Yes suPHP is the selected handler:
Default PHP Version (.php files) 5
PHP 5 Handler suphp

Apache suEXEC on
Apache Ruid2 off

I even re-saved the configuration and tried again.

PHPInfo says: Server API: CGI/FastCGI

Thanks

 

[ThinIce]

The file I am executing in account1 is owned by account1 and has 644 permissions. If I change the permissions to 640 then it gets blocked from account2. Is this something I'm going to have to do to protect my files from other users??
Thanks

If the files are sensitive and shouldn't be read, yes. Essentially whatever clever (or not so clever i.e. the now removed php safe mode) techniques are put in place to offer ersatz protection the file system permissions are the base of the thing. The history of protections for file access and execution on shared hosting is a bit of a roller coaster ride, these days it's de rigueur to deal with this at the OS level i.e. Technology

If you're only maintaining a system for your own sites then likely you know which files are sensitive and can amend their permissions accordingly.

 

[quizknows]

Your users home directories or public_html directories may have improper permissions. Make sure public_html is chowned to user:nobody and has permissions set to 750. Public_html directories themselves should not be 755 but I see them like this all the time. This should stop cross-account read on SuPHP systems, other than the symlink "hack"

 

[Evolve]

ThinIce: Yes I think I will take particular precautions with database files etc. from now on. I thought that if I had it in the root of the account, above public_html, it couldn't be accessible but that doesn't matter when accessing it from another account. I also thought suPHP would restrict usage to the account and that open_basedir was still working (which i know isn't working by default)

quizknows: My public_html folders are g:nobody o:user permissions:750
I'm actually accessing a file above public_html though. My cPanel account folder is: g:user o:user permission: 711

Recently I had a corruption of the http.conf file when trying to block mod_security on a folder on an account. I used /scripts/rebuildhttpdconf to rebuilt it. Would that have had any negative effects?

I'm seeing the following with each account:

    <IfModule mod_suphp.c>
        suPHP_UserGroup user user
    </IfModule>
and
<IfModule !mod_disable_suexec.c>
        <IfModule !mod_ruid2.c>
            SuexecUserGroup user user
        </IfModule>
    </IfModule>

 

[quizknows]

sounds like directory perms are good then.

/scripts/rebuildhttpdconf is a perfectly acceptable way to rebuild the apache config; you shouldn't edit httpd.conf directly on a cpanel system anyway. Rebuilding it that way will build it from the current settings and account data.

 

[Evolve]

So, I'm still stuck at square one.

Should suPHP make it impossible for other users to execute your files?

I see Tristan posted this in another thread:

No other users can call a script they do not own under suPHP regardless of VirtualHost entries, since that folder has to be owned by the reseller user. Under suPHP, you will end up with user and group mismatch errors when those other accounts try to call the script(s) in that folder.

Why am I not getting these errors?

quizknows: I actually wasn't modifying the httpd.conf directly; the corruption happened after running /scripts/ensure_vhost_includes/

 

[ThinIce]

suPHP doesn't make it impossible for other's to execute your files. suPHP is an interpreter and what *it* will execute can be configured (outside file permissions). It might be worthing taking a look at EasyApache: PHP Request Handling The defaults in /opt/suphp/etc/suphp.conf are reasonable, but can be tightened a little.

check_vhost_docroot - This security check causes suPHP to check that the target script resides in the document root of the VirtualHost that serves the request. For a UserDir request, suPHP considers the domain part of the URL to be the VirtualHost that serves the request. If you set this to true it will cause UserDir requests and some types of PHP aliases to fail. However, security will be significantly improved. This setting is false by default.

This said, I'm unsure if that particular setting would make any difference to the function you mention in your original post, I'd imagine it may influence execution only

 

[cPanelPeter]

Hello,

Feel free to open a support ticket on this using the link in my signature. One of our analysts will be happy to look into this for you. Once you've opened a ticket, please post the ticket number in this thread so that we can update it accordingly.

 

[Evolve]

Ticket #4491249

Thanks!

 

[cPanelPeter]

Hello,

To update this thread, there was some confusion on how permissions are inherited, but as a result there was also a new feature request created to assist with tightening permissions. The request is here and needs some more votes

 

[Evolve]

You beat me to it Peter!

My thanks goes out to the cPanel staff helping me clarify what was going on.

I'm not sure inheritance would be the right word.. maybe traversal? I got corrected for using inheritance by one of your staff :p

I made the mistake of assuming suExec was some complex system that protected all of my folders automatically, regardless of location, by allowing only the user to access them; I didn't realize I had to take extra steps to change permissions on folders above the public_html folder to protect them from eavesdropping.

I look forward to David Nielson's feature request getting some traction. I think it would help people out by adding one more layer of protection in that they may be oblivious to.

 

[ThinIce]

My support added to this one

 

[georgeb]

Btw I realized recently that open_basedir doesn't work out of the box with suPHP and have found the thread where Tristan explains how to lock down php.ini files. I will do this after I figure out what's going on.[/I]
I'm using PHP 5.4

"open_basedir" is working with no problems. In my case I did this:
- php.ini for each account, protected (only root access to those files, I can customize this by user needs);
- for each account newly created a php.ini file will be generated automatically at account creation, with the open_basedir customized by username and username directory, so no access "out of the box";

It is not complicated....


Regards

 

[stelian]

Hello,

I have a similar situation where error_get_last() print this:

Array
(
    [type] => 2
    [message] => file_exists(): [B]open_basedir restriction in effect.[/B] File(/home/[B]user1[/B]/public_html/cache/lang/lang.php) [B]is not within the allowed path[/B](s): (/home/romanian/public_html/ewcms/ewcms_cache/lang:/home2/statisti/public_html)
    [file] => /home2/[B]user2[/B]/public_html/includes/libraries/cache.php
    [line] => 59
)

I have PHP running as suphp and suexex = On.
/home2/user2/public_html/php.ini looks like this

open_basedir = "/home/USER1/public_html/cache/lang:/home2/user2/public_html"

but it looks like "/home/USER1/public_html/cache/lang" is ignored.

Basically I want that PHP running as user2 to modify some files on user1 homedir. I can't switch to DSO.
Is there any way I could achieve what I want?

Please help!

 

[quizknows]

Basically I want that PHP running as user2 to modify some files on user1 homedir. I can't switch to DSO.
Is there any way I could achieve what I want?

Please help!

Is there any way to? Probably. Is it a good idea at all? No. Not at all. Assuming you're using SuPHP instead of DSO you'd have to loosen the security provided by SuPHP, likely disable symlink protection if you have any, and loosen file permissions.

Find another way to do what you need to do without allowing cross-account access for web applications. From a security standpoint, what you're asking to do is a horrible idea (sorry, not trying to be personally offensive, it just is a terrible idea).

 

[stelian]

Thank you @quizknows

You are right, but that's a "horrible" application. I ended up setting a cronjob that synchronize 2 folders than chown on them. This way both users have their own copy and there is no need to mess with permissions.

Best regards!

 

[quizknows]

Thank you @quizknows

You are right, but that's a "horrible" application. I ended up setting a cronjob that synchronize 2 folders than chown on them. This way both users have their own copy and there is no need to mess with permissions.

Best regards!

This sounds like a much better solution Glad you were able to get it figured out. Cheers.