3

Is it possible to restrict PHP's file access to its document root? Basically on my work's server we have our domains in a file structure like:

/home/something/domains/domain1/
/home/something/domains/domain2/
/home/something/domains/domain3/

Right now, any script on domain1 has read and write access to anything in /home/something/domains/ including all of our other domains. I would like to restrict file access for a script in domain1 to only that domain.

The server is hosted with mediatemple and it is their grid service, so I don't have root access or even vhost config access. We can change php.ini, and i know it offers open_basedir, but it doesn't sound like that solves my problem as I could only restrict file access to /domians/ and not the individual domains. Any help appreciated.

What I'm really trying to do:

This server was recently hacked, and the hackers were overwriting domains/.htaccess which affected all our sites. We have tons of sites and many of them have lots of lines of bad code. They uploaded WSO, a hacking backdoor/shell which gave them full access to everything. I don't know how they got access, I guess it was either from the timthumb exploit, one of the millions of lines of bad code, or they just got our FTP password somehow. We updated old timthumbs, changed the password and removed all the bad files we found, but since there is a decent chance whatever exploit they found is still on the server, or that we missed some backdoor, I would at least like to limit their access to the actual domain that contains the exploit or unfound backdoor.

ghbarratt
  • 11,496
  • 4
  • 41
  • 41
Andy Groff
  • 2,660
  • 1
  • 21
  • 25
  • What is the OS of the server? Are you familiar with configuring SELinux? –  Mar 19 '12 at 04:05
  • it doesn't really sound like a solution to the issue of being hacked in the first place. –  Mar 19 '12 at 04:05
  • Server is Cent OS, but we're pretty limited as its a weird shared hosting environment. I understand that the solution is to audit the code and make sure we're not letting people upload php files or somehow gain access through insecure practices but the unfortunate reality is that we have a million + lines of horrible, unreadable code and securing it all isn't feasible. I've grepped eval and gotten thousands of hits. I just don't know what to do. – Andy Groff Mar 19 '12 at 04:27

1 Answers1

3

My initial thought was to set open_basedir for each of the virtual hosts (even if you have to ask your host admin to do it for you), but I am doubtful that will even work because I am fairly certain external/shell commands that run in PHP/scripts will still work on directories outside of the designated tree.

After more consideration, the closest way to configure your setup and get what you want, that I could think of, would be to set up chroot-jailed user accounts for each vhost and have your webserver use those user accounts through a mechanism like the Apache 2 MPM ITK, which I can only assume your hosting provider will have trouble setting up.

Community
  • 1
  • 1
ghbarratt
  • 11,496
  • 4
  • 41
  • 41
  • Thanks for the response. I thought about setting open_basedir on a per virtual host basis, but when i asked about the ability to disable .htaccess files and/or move our url rewrites into virtual host files they said "On the Grid, you cannot modify the Apache web server configuration. All Apache directives need to be contained in the .htaccess file." Since they won't even let me modify vhost config, I highly doubt they would entertain anything like jailed user accounts. I guess their restrictions make it almost impossible for you guys to help me with this :( – Andy Groff Mar 19 '12 at 04:49
  • Your question might get better answers on [serverfault](http://serverfault.com/) or even [superuser](http://superuser.com). I am a developer with a bit of server administration experience, a true server administrator might have a better answer for you. Or he might just say your host is your problem. :-) – ghbarratt Mar 19 '12 at 05:07
  • haha thanks. This hosting environment has been a problem throughout this whole ordeal. I guess we'll just hope we got rid of their access and if it comes back, move to a server where we have root access to do what we need to. Thanksa bunch for your time. – Andy Groff Mar 19 '12 at 06:27