open_basedir?

  105606
May 7, 2019 10:11 nikita.ppv@gmail.com (Nikita Popov)
Hi internals,

The open_basedir ini setting has two significant problems:

1. It is a major performance hit, because it disables the realpath cache.

2. Many people think it is a security feature and use it as such. However,
open_basedir is in reality a "best effort" mechanism, with known
workarounds and more regularly being found. Especially when it comes to
interactions with 3rd party libraries, enforcing open_basedir is simply
impossible.

What open_basedir tries to do must be implemented on the operating system
level to work reliably (and of course such mechanisms exist, such as jails,
chroot and friends).

I wonder if it is feasible to drop this ini setting? Enforcing this doesn't
really seem like any of PHP's business. If not, I think we need to at least

a) make it clear in the documentation that this is *not* a security option
and only exists to prevent "accidents" and
b) update the security policy (https://wiki.php.net/security) to state that
open_basedir bypasses are not security issues. I believe this has been part
of Debian's security policy for some time already.

Regards,
Nikita
  105607
May 7, 2019 10:17 krakjoe@gmail.com (Joe Watkins)
Morning Nikita,

It would be wise to do a) and b) regardless of whether it's going to be
removed.

I think +1 on removing it in 8 ... I'm not sure if it should be deprecated
in 7.4 first, or how that would work ?

Cheers
Joe

On Tue, 7 May 2019 at 12:11, Nikita Popov ppv@gmail.com> wrote:

> Hi internals, > > The open_basedir ini setting has two significant problems: > > 1. It is a major performance hit, because it disables the realpath cache. > > 2. Many people think it is a security feature and use it as such. However, > open_basedir is in reality a "best effort" mechanism, with known > workarounds and more regularly being found. Especially when it comes to > interactions with 3rd party libraries, enforcing open_basedir is simply > impossible. > > What open_basedir tries to do must be implemented on the operating system > level to work reliably (and of course such mechanisms exist, such as jails, > chroot and friends). > > I wonder if it is feasible to drop this ini setting? Enforcing this doesn't > really seem like any of PHP's business. If not, I think we need to at least > > a) make it clear in the documentation that this is *not* a security option > and only exists to prevent "accidents" and > b) update the security policy (https://wiki.php.net/security) to state > that > open_basedir bypasses are not security issues. I believe this has been part > of Debian's security policy for some time already. > > Regards, > Nikita >
  105608
May 7, 2019 10:25 gertp93@gmail.com (Gert)
Hello,

If the plan is to remove it in 8.0, then i'd say its beneficial to already
deprecate it in 7.4. This will give users an earlier warning that these
upgrades need to happen.

Cheers

On Tue, 7 May 2019 at 12:18, Joe Watkins <krakjoe@gmail.com> wrote:

> Morning Nikita, > > It would be wise to do a) and b) regardless of whether it's going to be > removed. > > I think +1 on removing it in 8 ... I'm not sure if it should be deprecated > in 7.4 first, or how that would work ? > > Cheers > Joe > > On Tue, 7 May 2019 at 12:11, Nikita Popov ppv@gmail.com> wrote: > > > Hi internals, > > > > The open_basedir ini setting has two significant problems: > > > > 1. It is a major performance hit, because it disables the realpath cache. > > > > 2. Many people think it is a security feature and use it as such. > However, > > open_basedir is in reality a "best effort" mechanism, with known > > workarounds and more regularly being found. Especially when it comes to > > interactions with 3rd party libraries, enforcing open_basedir is simply > > impossible. > > > > What open_basedir tries to do must be implemented on the operating system > > level to work reliably (and of course such mechanisms exist, such as > jails, > > chroot and friends). > > > > I wonder if it is feasible to drop this ini setting? Enforcing this > doesn't > > really seem like any of PHP's business. If not, I think we need to at > least > > > > a) make it clear in the documentation that this is *not* a security > option > > and only exists to prevent "accidents" and > > b) update the security policy (https://wiki.php.net/security) to state > > that > > open_basedir bypasses are not security issues. I believe this has been > part > > of Debian's security policy for some time already. > > > > Regards, > > Nikita > > >
  105610
May 7, 2019 10:37 arvids.godjuks@gmail.com (Arvids Godjuks)
Hello,

as an end-user, I'd say that it should go the way of the dinosaurs as
request globals and alike went - these days there are a lot of ways to do
it better and way more securely.

Makes it easier on everyone and removes abuse of it for security purposes.
Deprecate 7.4, dump it in 8.0.

Implement a & b to warn people.

вт, 7 мая 2019 г. в 12:25, Gert <gertp93@gmail.com>:

> Hello, > > If the plan is to remove it in 8.0, then i'd say its beneficial to already > deprecate it in 7.4. This will give users an earlier warning that these > upgrades need to happen. > > Cheers > > On Tue, 7 May 2019 at 12:18, Joe Watkins <krakjoe@gmail.com> wrote: > > > Morning Nikita, > > > > It would be wise to do a) and b) regardless of whether it's going to be > > removed. > > > > I think +1 on removing it in 8 ... I'm not sure if it should be > deprecated > > in 7.4 first, or how that would work ? > > > > Cheers > > Joe > > > > On Tue, 7 May 2019 at 12:11, Nikita Popov ppv@gmail.com> wrote: > > > > > Hi internals, > > > > > > The open_basedir ini setting has two significant problems: > > > > > > 1. It is a major performance hit, because it disables the realpath > cache. > > > > > > 2. Many people think it is a security feature and use it as such. > > However, > > > open_basedir is in reality a "best effort" mechanism, with known > > > workarounds and more regularly being found. Especially when it comes to > > > interactions with 3rd party libraries, enforcing open_basedir is simply > > > impossible. > > > > > > What open_basedir tries to do must be implemented on the operating > system > > > level to work reliably (and of course such mechanisms exist, such as > > jails, > > > chroot and friends). > > > > > > I wonder if it is feasible to drop this ini setting? Enforcing this > > doesn't > > > really seem like any of PHP's business. If not, I think we need to at > > least > > > > > > a) make it clear in the documentation that this is *not* a security > > option > > > and only exists to prevent "accidents" and > > > b) update the security policy (https://wiki.php.net/security) to state > > > that > > > open_basedir bypasses are not security issues. I believe this has been > > part > > > of Debian's security policy for some time already. > > > > > > Regards, > > > Nikita > > > > > >
-- Arvīds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius
  105611
May 7, 2019 10:38 zeev@php.net (Zeev Suraski)
On Tue, May 7, 2019 at 1:25 PM Gert <gertp93@gmail.com> wrote:

> Hello, > > If the plan is to remove it in 8.0, then i'd say its beneficial to already > deprecate it in 7.4. This will give users an earlier warning that these > upgrades need to happen.
We should definitely deprecate it before removing it, if we decide to remove it. This has been our modus operandi for years and it's a good one - especially here, where folks who rely on it for (even some level of) security would have a lot of work on their hands to come up with a different solution for isolation. Zeev
  105613
May 7, 2019 11:28 rowan.collins@gmail.com (Rowan Collins)
On Tue, 7 May 2019 at 11:38, Zeev Suraski <zeev@php.net> wrote:

> - especially here, where folks who rely on it for (even some level of) > security would have a lot of work on their hands to come up with a > different solution for isolation. >
This point is worth dwelling on I think: if someone is using this feature as part of their security right now, is it better than nothing? I don't think it's sensible to assume that everyone seeing the deprecation notice will immediately put into place a security review of their hosting, so we should consider which of the following will lead to the best security outcome: a) open_basedir remains available, and people keep using it b) open_basedir is removed in PHP 8, and people upgrade without reviewing the rest of their security c) open_basedir is removed in PHP 8, and people stay on PHP 7.4 instead of upgrading If scenario (a) gives even a slight security advantage over scenario (b), we should think very carefully before removing the feature. Regards, -- Rowan Collins [IMSoP]
  105633
May 7, 2019 19:08 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> If scenario (a) gives even a slight security advantage over scenario (b), > we should think very carefully before removing the feature.
There's definitely _some_ security advantage, defense is always in layers, and while open_basedir can not be made secure, it certainly can avert _some_ attacks and prevent _some_ bugs from becoming a security catastrophe. *Relying* on it is wrong, but using it while being fully aware it is just a partial protection that is only good for certain things but not others is IMO fine. -- Stas Malyshev smalyshev@gmail.com
  105609
May 7, 2019 10:35 zeev@php.net (Zeev Suraski)
On Tue, May 7, 2019 at 1:11 PM Nikita Popov ppv@gmail.com> wrote:

> Hi internals, > > The open_basedir ini setting has two significant problems: > > 1. It is a major performance hit, because it disables the realpath cache. >
That's true, but only if it's in use. That's kind of fair...
> 2. Many people think it is a security feature and use it as such. However, > open_basedir is in reality a "best effort" mechanism, with known > workarounds and more regularly being found. Especially when it comes to > interactions with 3rd party libraries, enforcing open_basedir is simply > impossible. >
Agreed 100%.
> What open_basedir tries to do must be implemented on the operating system > level to work reliably (and of course such mechanisms exist, such as jails, > chroot and friends). >
Ditto
> I wonder if it is feasible to drop this ini setting? Enforcing this doesn't > really seem like any of PHP's business.
It's definitely feasible, although personally, I think the right way to go here is more around docs and policy. It's not completely without value, and I believe I've seen it being used in a lot of different places (most of them realizing the fact it's a 'best effort' feature and not a bulletproof one). I wouldn't introduce it today, but I don't see the compelling case the remove it. If not, I think we need to at least
> > a) make it clear in the documentation that this is *not* a security option > and only exists to prevent "accidents" and >
I'm not sure I'd phrase it that way exactly, but generally I very much agree. I think we should say it's just an extra safety net, that is in no way comprehensive and can therefore not be relied upon when security is needed. b) update the security policy (https://wiki.php.net/security) to state that
> open_basedir bypasses are not security issues. I believe this has been part > of Debian's security policy for some time already.
Agreed 100%. Zeev
  105632
May 7, 2019 19:05 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> b) update the security policy (https://wiki.php.net/security) to state that > open_basedir bypasses are not security issues. I believe this has been part > of Debian's security policy for some time already.
I think we've been treating them this way effectively for a while now. The big question is how we formulate what open_basedir actually *is*. I mean, some people find it rather useful, and in some situation such mechanism can be very valuable - one scenario I can think of it turning on open_basedir, run through application test suite and check that it doesn't reach anywhere it should not. It, of course, does not provide security guarantees, neither do unit tests, but we still find unit tests useful, and in the same vein people may find open_basedir useful. So before just swinging the ax and dropping it I think we should really research what people are actually using open_basedir for. And then try to formulate a proper description of what it can be used for without claiming any security guarantees we could not deliver. In general, I think we should slow down a bit (actually, a lot) with removing things from PHP. We've already accumulated a lot of BC baggage here, and if we want PHP 8 to become the version of PHP that an average developer can target without hearing "yeah, we're planning to upgrade sometimes in the next 2-3 years, probably, maybe", then we should slow down with the removals. PHP 7 had rather short list of removing things, and most of them very marginally used. And that IMHO worked well. Here we're talking about things that are used - on my estimation - much more widely. open_basedir particularly is not that bad in this regard, because likely no app critically depends on it being there - so it's more of a generic comment about what I am seeing on the lists nowdays, where tons of removals and global overhauls with enormous BC costs are proposed. -- Stas Malyshev smalyshev@gmail.com
  105637
May 8, 2019 06:37 phpmailinglists@gmail.com (Peter Bowyer)
On Tue, 7 May 2019 at 20:05, Stanislav Malyshev <smalyshev@gmail.com> wrote:

> So before just swinging the ax and dropping it I think we should really > research what people are actually using open_basedir for. And then try > to formulate a proper description of what it can be used for without > claiming any security guarantees we could not deliver. >
Yes.
> In general, I think we should slow down a bit (actually, a lot) with > removing things from PHP. We've already accumulated a lot of BC baggage > here, and if we want PHP 8 to become the version of PHP that an average > developer can target without hearing "yeah, we're planning to upgrade > sometimes in the next 2-3 years, probably, maybe", then we should slow > down with the removals. > > PHP 7 had rather short list of removing things, and most of them very > marginally used. And that IMHO worked well. Here we're talking about > things that are used - on my estimation - much more widely. open_basedir > particularly is not that bad in this regard, because likely no app > critically depends on it being there - so it's more of a generic comment > about what I am seeing on the lists nowdays, where tons of removals and > global overhauls with enormous BC costs are proposed. >
I agree with Stas. I support a campaign of education by doing Nikita's a) & b), with the addition of: c) highlighting the performance impact (particularly if it can be quantified) d) updating the PHP.ini comment to say it is not recommended to enable, with details of a) b) & c) https://github.com/php/php-src/blob/master/php.ini-development#L295-L300 I will vote against removing if it comes to a vote. Peter
  105638
May 8, 2019 07:23 nikita.ppv@gmail.com (Nikita Popov)
On Tue, May 7, 2019 at 9:05 PM Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi! > > > b) update the security policy (https://wiki.php.net/security) to state > that > > open_basedir bypasses are not security issues. I believe this has been > part > > of Debian's security policy for some time already. > > I think we've been treating them this way effectively for a while now. > > The big question is how we formulate what open_basedir actually *is*. I > mean, some people find it rather useful, and in some situation such > mechanism can be very valuable - one scenario I can think of it turning > on open_basedir, run through application test suite and check that it > doesn't reach anywhere it should not. It, of course, does not provide > security guarantees, neither do unit tests, but we still find unit tests > useful, and in the same vein people may find open_basedir useful. > > So before just swinging the ax and dropping it I think we should really > research what people are actually using open_basedir for. And then try > to formulate a proper description of what it can be used for without > claiming any security guarantees we could not deliver. >
Right. One practical question that would interest me in particular is if we can drop the implicit disabling of the realpath cache if open_basedir is enabled. It makes open_basedir trivially bypassable, but still requiring some specially crafted code -- not something that just happens by accident. If we see open_basedir as a non-security feature for detecting code that accidentally tries to access things it shouldn't, that should be fine. But I'm not quite sure if that's the right interpretation. I don't really care myself whether open_basedir exists or not, I mainly want users (and ourselves as well) to understand what the intended usage and limitations are. Regards, Nikita
  105635
May 7, 2019 20:55 jocelyn.fournier@gmail.com (jocelyn fournier)
Hi!

> Le 7 mai 2019 à 12:11, Nikita Popov ppv@gmail.com> a écrit : > > Hi internals, > > The open_basedir ini setting has two significant problems: > > 1. It is a major performance hit, because it disables the realpath cache. > > 2. Many people think it is a security feature and use it as such. However, > open_basedir is in reality a "best effort" mechanism, with known > workarounds and more regularly being found. Especially when it comes to > interactions with 3rd party libraries, enforcing open_basedir is simply > impossible. > > What open_basedir tries to do must be implemented on the operating system > level to work reliably (and of course such mechanisms exist, such as jails, > chroot and friends). > > I wonder if it is feasible to drop this ini setting? Enforcing this doesn't > really seem like any of PHP's business. If not, I think we need to at least > > a) make it clear in the documentation that this is *not* a security option > and only exists to prevent "accidents" and > b) update the security policy (https://wiki.php.net/security) to state that > open_basedir bypasses are not security issues. I believe this has been part > of Debian's security policy for some time already. > > Regards, > Nikita
The main issue with this option is that it’s used by default by hosting control panel like ispconfig / cpanel. And because of that a lot of users: 1) Are using it without really knowing it 2) Could experienced a major performance impact because of that, but don’t really understand why So deprecating it will at least lead to disabling by default the option in those software, which is good :) -- Jocelyn Fournier Founder M : +33 6 51 21 54 10 https://www.softizy.com Softizy - At your side to Optimize your PHP / MySQL applications
  105636
May 8, 2019 04:49 me@kelunik.com (Niklas Keller)
Am Di., 7. Mai 2019 um 12:11 Uhr schrieb Nikita Popov ppv@gmail.com>:
> > Hi internals, > > The open_basedir ini setting has two significant problems: > > 1. It is a major performance hit, because it disables the realpath cache. > > 2. Many people think it is a security feature and use it as such. However, > open_basedir is in reality a "best effort" mechanism, with known > workarounds and more regularly being found. Especially when it comes to > interactions with 3rd party libraries, enforcing open_basedir is simply > impossible. > > What open_basedir tries to do must be implemented on the operating system > level to work reliably (and of course such mechanisms exist, such as jails, > chroot and friends). > > I wonder if it is feasible to drop this ini setting? Enforcing this doesn't > really seem like any of PHP's business. If not, I think we need to at least > > a) make it clear in the documentation that this is *not* a security option > and only exists to prevent "accidents" and > b) update the security policy (https://wiki.php.net/security) to state that > open_basedir bypasses are not security issues. I believe this has been part > of Debian's security policy for some time already. > > Regards, > Nikita
Hi Nikita, I'm probably in favor of removing it. If it is used for unit tests to check file access outside some directory, we could maybe allow it to be set by code only but not by php.ini? If we decide to remove it in PHP 8, we should probably trigger a fatal startup error in case it is configured in php.ini to prevent loosing the protection entirely for people relying on it. Regards, Niklas
  105650
May 9, 2019 08:15 php@bohwaz.net (BohwaZ/PHP)
Kia ora,

I'm against deprecating it or removing it.

As said earlier, it has some security value, especially with mass 
hosting. If I'm hosting thousands of websites for thousands of users, 
using chroot is not doable, and open_basedir is a good alternative (at 
least it's better than nothing).

That's why it's used by ISPconfig and other panels: there is no other 
solution that I know of.
  105667
May 10, 2019 20:55 me@kelunik.com (Niklas Keller)
> I'm against deprecating it or removing it. > > As said earlier, it has some security value, especially with mass > hosting. If I'm hosting thousands of websites for thousands of users, > using chroot is not doable, and open_basedir is a good alternative (at > least it's better than nothing). > > That's why it's used by ISPconfig and other panels: there is no other > solution that I know of.
That's exactly the reason why I'm for removing it. There will always be ways to circumvent open_basedir and setups like this are insecure. It gives a false sense of security. It's not better than nothing, because most hosting providers would opt for a real solution instead of leaving users entirely unprotected. Regards, Niklas
  105669
May 11, 2019 00:12 php@bohwaz.net (BohwaZ)
On Fri, 10 May 2019 22:55:51 +0200 / Niklas Keller <me@kelunik.com>
said :

> That's exactly the reason why I'm for removing it. There will always > be ways to circumvent open_basedir and setups like this are insecure. > It gives a false sense of security. It's not better than nothing, > because most hosting providers would opt for a real solution instead > of leaving users entirely unprotected.
What's your solution then? I'll be more than happy to have anything better that will work with thousands of users :) Also I don't get the argument that because it isn't perfect it would not be useful. It definitely is, as a security measure. chroot isn't perfect either, but you might want to use it as well. Same for disable_functions, sure there will be ways to go around it, but it will still block 90% of attacks we might get. So, definitely not the most reliable thing, but it adds a layer that may help. I can pick the lock on my front door in about 10 minutes, a professional probably much less. And you can enter by breaking a window. But it is still effective as a security measure. And it would be silly if someone would come and tell me that the lock should be removed because it gives a false sense of security :)
  105673
May 11, 2019 07:53 me@kelunik.com (Niklas Keller)
> > That's exactly the reason why I'm for removing it. There will always > > be ways to circumvent open_basedir and setups like this are insecure. > > It gives a false sense of security. It's not better than nothing, > > because most hosting providers would opt for a real solution instead > > of leaving users entirely unprotected. > > What's your solution then? I'll be more than happy to have anything > better that will work with thousands of users :)
Solutions that work at the OS level have been suggested in this thread. It's not my job figuring out a solution that works better for your business at scale.
> Also I don't get the argument that because it isn't perfect it would > not be useful. It definitely is, as a security measure.
Quoting https://www.php.net/security-note.php:
> For Local exploits we mostly hear about open_basedir or safemode problems on shared virtual hosts. These two features are there as a convenience to system administrators and should in no way be thought of as a complete security framework. With all the 3rd-party libraries you can hook into PHP and all the creative ways you can trick these libraries into accessing files, it is impossible to guarantee security with these directives. The Oracle and Curl extensions both have ways to go through the library and read a local file, for example. Short of modifying these 3rd-party libraries, which would be difficult for the closed-source Oracle library, there really isn't much PHP can do about this.
The exact issue is that it appears to be good enough, but it really isn't.
> chroot isn't perfect either, but you might want to use it as well. > > Same for disable_functions, sure there will be ways to go around it, > but it will still block 90% of attacks we might get. So, definitely not > the most reliable thing, but it adds a layer that may help. > > I can pick the lock on my front door in about 10 minutes, a > professional probably much less. And you can enter by breaking a window. > But it is still effective as a security measure. And it would be silly > if someone would come and tell me that the lock should be removed > because it gives a false sense of security :)
My hope is that if we remove the feature, hosting providers will opt for a proper door instead of one made from paper. Regards, Niklas
  105674
May 11, 2019 09:11 lester@lsces.uk (Lester Caine)
On 11/05/2019 08:53, Niklas Keller wrote:
>>> That's exactly the reason why I'm for removing it. There will always >>> be ways to circumvent open_basedir and setups like this are insecure. >>> It gives a false sense of security. It's not better than nothing, >>> because most hosting providers would opt for a real solution instead >>> of leaving users entirely unprotected. >> What's your solution then? I'll be more than happy to have anything >> better that will work with thousands of users:) > Solutions that work at the OS level have been suggested in this > thread. It's not my job figuring out a solution that works better for > your business at scale.
Suggested, but that falls short of providing a solution for those users who may well not even be aware it is being used. When one hits a deprecation warning there should be a reasonable set of instruction to go with it offering an alternative. It SHOULD also be recognised that many users will not actually have any control over the OS level and being able to wrap different applications running in ones own shared hosting to protect one's own operation IS one of the useful features open_basedir provides? Having to create different hosting accounts to achieve that seems somewhat insane? https://uk.godaddy.com/help/can-i-use-open-basedir-on-my-server-running-parallels-plesk-panel-1619 is an example of one hosting providers use of it and something which would probably require every host to rework their support crib sheets :( -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
  105676
May 11, 2019 10:55 yohgaki@ohgaki.net (Yasuo Ohgaki)
On Sat, May 11, 2019 at 5:56 AM Niklas Keller <me@kelunik.com> wrote:

> > I'm against deprecating it or removing it. > > > > As said earlier, it has some security value, especially with mass > > hosting. If I'm hosting thousands of websites for thousands of users, > > using chroot is not doable, and open_basedir is a good alternative (at > > least it's better than nothing). > > > > That's why it's used by ISPconfig and other panels: there is no other > > solution that I know of. > > That's exactly the reason why I'm for removing it. There will always > be ways to circumvent open_basedir and setups like this are insecure. > It gives a false sense of security. It's not better than nothing, > because most hosting providers would opt for a real solution instead > of leaving users entirely unprotected. >
Under VM setup, there is not much problem for linux. However, docker (and/or cgroup based containers) has problem because there is no namespace for selinux. Therefore, containers cannot have workable selinux protection, as well as OSes that lacks selinux like protections. I don't care much about open_basedir. However, I wonder how many container setups relay on open_basedir as additional security. Regards, P.S. Anyone shouldn't rely on stack smashing attack protection, yet it's still there for sail safe purpose. open_basedir is fail safe feature. -- Yasuo Ohgaki yohgaki@ohgaki.net