3

On servers doing shared web hosting, or sharing the PHP environment between different PHP applications, I usually implement a security policy that uses PHP open_basedir to restrict each user to his/her own directory (along with other PHP directives like disable_functions for example). I also see quite a lot of posts here on SF discussing the benefits of using this feature.

However, now I stumble on this notice in the Debian package file README.Debian.security stating explicitly that they don't provide security support for (amongst others):

* Vulnerabilities involving any kind of open_basedir violation, as
  this feature is not considered a security model either by us or by
  PHP upstream.

So I wonder, does this statement is just there to waive any responsibility or does it have more fundamental reasons?

In particular, how would you go to secure a PHP server used by multiple different users without open_basedir and while trying not to raise the maintenance effort to high? Or would you just recommend to never do shared hosting as the PHP developers are stating in their security note?

2 Answers 2

2

Seems the reason for the disclaimer is that there are ways to break out of the open_basedir rule. I would still use it on a shared host but don't count on it as your only security. Also have each virtual host owned by a different user and run the apache process under that user account for the scripts on that host.

To your more general question though, I do think the age of shared hosting is almost over. Virtual host technology has advanced to the point that a shared host is almost useless.

5
  • 1
    Not to mention the shared hosting market is so saturated it's very difficult to make any money. Dec 13, 2013 at 16:09
  • 2
    @segfault I'm not sure I understand how the link you point permits to override the open_basedir setting. Agreed for the shared hosting being of a different age, but you can also be in a very similar situation just with different PHP applications that you'd want to isolate. Still, maintaining a single PHP environment for 10 different applications, if it can be made secure, is easier to do than maintaining 10 different servers.
    – Lætitia
    Dec 13, 2013 at 18:34
  • Sorry, that link is not a good example. I agree with you about putting more than one PHP application on a server. I didn't mean to imply you needed a separate server for every application, just that shared hosting as a resold product is not a compelling product these days IMO.
    – Segfault
    Dec 13, 2013 at 19:03
  • I'd have thought that LXC et al is probably a better way to ensure segregation on multi-tenant systems. Dec 13, 2013 at 20:15
  • 1
    @TomO'Connor sure, I think that would work pretty well but have never tried it personally, why don't you write an answer about it?
    – Segfault
    Dec 16, 2013 at 13:49
1

A good article on previous open_basedir bypasses is available at https://www.bencteux.fr/posts/open_basedir/

In addition, the use of open_basedir is not very efficient. It requires PHP to check each file system access against the list of provided paths. open_basedir also disables the realpath caching, which further slows down file system accesses. So depending on your application and the number of configured paths you may experience serious degradation of performance.

On your question on how to secure a setup with multiple users: The answer is PHP-FPM. Run a FPM pool for each user assigned to their own OS user. Then use the classic ownership/file permission mechanisms to ensure that users can not cross their assigned boundaries aka home dirs.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .