On Tue, May 7, 2019 at 9:05 PM Stanislav Malyshev <smalys...@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
