Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105673
MIME-Version: 1.0
References: <CAF+90c-4-R4SYY_AAL679ZYBn2QAZTYAGXH6E6Bz1hYGN=MFcA@mail.gmail.com>
 <ea139574152ce7376946c8e2d45051df@bohwaz.net> <CANUQDCjV3ke8jFmeBEXOzEi5HLQiYwWmC2UUaoOP+t0JGRtg9Q@mail.gmail.com>
 <20190511021217.1aaac8f5@platypus>
In-Reply-To: <20190511021217.1aaac8f5@platypus>
Date: Sat, 11 May 2019 09:53:31 +0200
Message-ID: <CANUQDChJJhhnqkDjmK792U63BViZY3aRpyzKtJjQffBggPmo6w@mail.gmail.com>
To: BohwaZ <php@bohwaz.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] open_basedir?
From: 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 secu=
rity 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, i=
t 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 woul=
d be difficult for the closed-source Oracle library, there really isn't muc=
h 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