open_basedir?

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

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

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

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

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

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 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

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

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

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

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

• 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]

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

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

Hi!

Le 7 mai 2019 à 12:11, Nikita Popov nikita.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

Am Di., 7. Mai 2019 um 12:11 Uhr schrieb Nikita Popov nikita.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

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

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

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.

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

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 :)

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

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

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