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?

Læti
  • 2,075
  • 21
  • 33

1 Answers1

1

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.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
Segfault
  • 264
  • 1
  • 9
  • 1
    Not to mention the shared hosting market is so saturated it's very difficult to make any money. – Michael Hampton Dec 13 '13 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æti Dec 13 '13 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 '13 at 19:03
  • I'd have thought that LXC et al is probably a better way to ensure segregation on multi-tenant systems. – Tom O'Connor Dec 13 '13 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 '13 at 13:49