hi,
One of the last reminding so called "security" feature is open_basedir.
On Windows f.e. it is very easy to create application pool with the
right users/permissions settings (IIS) or only permissions settings
(Apache). It is not possible to create one user per host on Apache
using mod_php but I think it is acceptable as it is mostly used as
development server or dedicated apps.
On linux, fcgi/fpm with linux permissions systems allow pretty much
the same. And my solutions exist for a per user/application isolation
system.
I think it is not worth the effort to keep maintaining something that
will never be as safe as system level permissions.
What do you think about removing it in php 6? Thoughts?
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
hi,
One of the last reminding so called "security" feature is open_basedir.
On Windows f.e. it is very easy to create application pool with the
right users/permissions settings (IIS) or only permissions settings
(Apache). It is not possible to create one user per host on Apache
using mod_php but I think it is acceptable as it is mostly used as
development server or dedicated apps.On linux, fcgi/fpm with linux permissions systems allow pretty much
the same. And my solutions exist for a per user/application isolation
system.I think it is not worth the effort to keep maintaining something that
will never be as safe as system level permissions.What do you think about removing it in php 6? Thoughts?
I'am obviously +1.
This param is not needed any more, it's been very easy to abuse it and
it's removal
will lead to many places of code cleaning :-)
Julien
One of the last reminding so called "security" feature is open_basedir.
On Windows f.e. it is very easy to create application pool with the
right users/permissions settings (IIS) or only permissions settings
(Apache). It is not possible to create one user per host on Apache
using mod_php but I think it is acceptable as it is mostly used as
development server or dedicated apps.On linux, fcgi/fpm with linux permissions systems allow pretty much
the same. And my solutions exist for a per user/application isolation
system.I think it is not worth the effort to keep maintaining something that
will never be as safe as system level permissions.What do you think about removing it in php 6? Thoughts?
Managing security on servers that one has full access to is not the main
target of open_basedir? It has a useful place when working with shared
hosting? While on-line storage costs are going down, sharing code across
a few sites while maintaining maintaining a level of isolation between
specific content is not easy to achieve in other ways?
The usage I'm seeing is that open_basedir provides access to the site
files and a shared set of resources used across several sites. This is
probably not the best way of doing things but is one documented on
several hosting packages. The examples I could link to require a private
login :( Just a pointer to something that provides an alternative
resolution would obviously be acceptable. With many of these facilities
it's not simply removing something but much more important to provide
education on the alternatives?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
2014-06-17 11:30 GMT+02:00 Lester Caine lester@lsces.co.uk:
One of the last reminding so called "security" feature is open_basedir.
On Windows f.e. it is very easy to create application pool with the
right users/permissions settings (IIS) or only permissions settings
(Apache). It is not possible to create one user per host on Apache
using mod_php but I think it is acceptable as it is mostly used as
development server or dedicated apps.On linux, fcgi/fpm with linux permissions systems allow pretty much
the same. And my solutions exist for a per user/application isolation
system.I think it is not worth the effort to keep maintaining something that
will never be as safe as system level permissions.What do you think about removing it in php 6? Thoughts?
Managing security on servers that one has full access to is not the main
target of open_basedir?
In my experiene it only leads to a false sense of security. I've seen it
more than once, that people just set a value there and believed, that they
are now safe. On the other hand they wonder, why many things were broken,
so they loosen the restrictions again.
It has a useful place when working with shared
hosting?
I'd recommend a using VMs, or container instead.
While on-line storage costs are going down, sharing code across
a few sites while maintaining maintaining a level of isolation between
specific content is not easy to achieve in other ways?
Composer?
The usage I'm seeing is that open_basedir provides access to the site
files and a shared set of resources used across several sites. This is
probably not the best way of doing things but is one documented on
several hosting packages. The examples I could link to require a private
login :( Just a pointer to something that provides an alternative
resolution would obviously be acceptable. With many of these facilities
it's not simply removing something but much more important to provide
education on the alternatives?--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk--
Hi all,
On Tue, Jun 17, 2014 at 6:34 PM, Sebastian Krebs krebs.seb@gmail.com
wrote:
In my experiene it only leads to a false sense of security. I've seen it
more than once, that people just set a value there and believed, that they
are now safe. On the other hand they wonder, why many things were broken,
so they loosen the restrictions again.
I agree that many users do not understand what it does and what it's for.
It's a fail safe feature that should not be trusted.
open_basedir should not be trusted, but it does not mean
it's useless just like antivirus softwares. Security features
do not have to be perfect to be useful.
I'm -1 for removing open_basedir.
If there are users who misunderstand what it's for, we
should improve our documentation. IMHO.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
On Tue, Jun 17, 2014 at 6:34 PM, Sebastian Krebs krebs.seb@gmail.com
wrote:In my experiene it only leads to a false sense of security. I've seen it
more than once, that people just set a value there and believed, that they
are now safe. On the other hand they wonder, why many things were broken,
so they loosen the restrictions again.I agree that many users do not understand what it does and what it's for.
It's a fail safe feature that should not be trusted.
open_basedir should not be trusted, but it does not mean
it's useless just like antivirus softwares. Security features
do not have to be perfect to be useful.I'm -1 for removing open_basedir.
If there are users who misunderstand what it's for, we
should improve our documentation. IMHO.
BTW, even though I think open_basedir is useful for better security,
I also think it's good to encourage users to use better alternatives,
selinux, etc. open_basedir is lazy protection, but it's easy to use.
Many users disable selinux or like completely.
I tends to vote -1 for this, but if there is vote, I would vote 0.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
I think it is not worth the effort to keep maintaining something that
will never be as safe as system level permissions.What do you think about removing it in php 6? Thoughts?
I don't see big maintenance issues. Most stream operations use PHP
streams which encapsulate that. Now there are 25 extensions directly
referring to open_basedir. From a quick look it seems that in all of
those cases we'd have to replace the open_basedir check by resolving
using VCWD (which open_basedir checks do implicitly[1]) which is
required by TSRM, thus we wouldn't win anything there.
Secondly, yes, this is not secure and not safe (and luckily not called
safe_basedir) but it is a mitigation against easy exploitation of
programming bugs and as such serves a purpose even when not protecting
against truly malicious people, especially ones with script execution
privileges.
johannes
[1] In some cases there might be bugs due to missing extra VCWD which i
didn't check now might be worth checking by somebody interested in TSRM
Hi!
On Windows f.e. it is very easy to create application pool with the
right users/permissions settings (IIS) or only permissions settings
(Apache). It is not possible to create one user per host on Apache
using mod_php but I think it is acceptable as it is mostly used as
development server or dedicated apps.
This is not exactly true. Setups running multiple apps on mod_php/Apache
are numerous.
That said, open_basedir is not really a security feature meant to stop
somebody with code execution access on the server. It's more of a
safeguard feature - i.e. if somebody forgets to add check to some fopen,
so that it may venture outside app space, open_basedir allows to
implement such checks on a certain group of functions. I think it is a
useful function, even though its framing in a security context makes it
look like it does something that it can not do. It's like filters - very
useful is some context but if you think you just slap a filter on your
insecure code and get security=On then you're mistaken.
So I don't think we need to remove this. I don't see a lot of
maintenance problem with it as long as we use streams properly (and we
should anyway) and we make it very clear what this tool actually does.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi,
One of the last reminding so called "security" feature is open_basedir.
On Windows f.e. it is very easy to create application pool with the
right users/permissions settings (IIS) or only permissions settings
(Apache). It is not possible to create one user per host on Apache
using mod_php but I think it is acceptable as it is mostly used as
development server or dedicated apps.On linux, fcgi/fpm with linux permissions systems allow pretty much
the same. And my solutions exist for a per user/application isolation
system.I think it is not worth the effort to keep maintaining something that
will never be as safe as system level permissions.What do you think about removing it in php 6? Thoughts?
I think you have a very narrow view of how this feature is used.
Security and code quality is about layers. This is a useful layer that
helps verify that an application, or even a subset of an application, is
only able to access a given set of directories. If something tries to
access a file outside of the defined scope, we get an error and we know
there is a bug in the code. I, and many companies out there, rely quite
heavily on this feature to catch mistakes. And yes, there are ways of
getting around it at the PHP-level if you deliberately craft your PHP
code to do so, but that doesn't make the feature any less useful to all
the people using it to catch non-deliberate mistakes.
-Rasmus
I think you have a very narrow view of how this feature is used.
Security and code quality is about layers. This is a useful layer that
helps verify that an application, or even a subset of an application, is
only able to access a given set of directories. If something tries to
access a file outside of the defined scope, we get an error and we know
there is a bug in the code. I, and many companies out there, rely quite
heavily on this feature to catch mistakes. And yes, there are ways of
getting around it at the PHP-level if you deliberately craft your PHP
code to do so, but that doesn't make the feature any less useful to all
the people using it to catch non-deliberate mistakes.
It gives a false sense of safety, and that alone for me is a good
enough reason to remove it. it is not as bad as safe_mode but simply
not good.
That being said I have no issue with keeping it besides the lost
opportunity to get rid of an old bad decision.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
I think you have a very narrow view of how this feature is used.
Security and code quality is about layers. This is a useful layer that
helps verify that an application, or even a subset of an application, is
only able to access a given set of directories. If something tries to
access a file outside of the defined scope, we get an error and we know
there is a bug in the code. I, and many companies out there, rely quite
heavily on this feature to catch mistakes. And yes, there are ways of
getting around it at the PHP-level if you deliberately craft your PHP
code to do so, but that doesn't make the feature any less useful to all
the people using it to catch non-deliberate mistakes.It gives a false sense of safety, and that alone for me is a good
enough reason to remove it. it is not as bad as safe_mode but simply
not good.
Only to people who don't understand how it works. Let's treat our
audience like grown ups, please.
-Rasmus
Only to people who don't understand how it works. Let's treat our
audience like grown ups, please.
Sure ;)
--
Pierre
@pierrejoye | http://www.libgd.org
Hi!
It gives a false sense of safety, and that alone for me is a good
enough reason to remove it. it is not as bad as safe_mode but simply
not good.
If you use it right, it does not. Every security feature would give you
false sense of safety if you use it wrong - but that alone is not the
reason to not have it at all, if it has legitimate uses. IMO
open_basedir does.
That being said I have no issue with keeping it besides the lost
opportunity to get rid of an old bad decision.
Bad decision was to brand open_basedir as security function that allows
defense against attacker with PHP code execution rights. It is obvious
we can not deliver on this promise. However, it does not mean that used
differently - e.g. as a safeguard in your own code to not access things
that you don't want this code to access by mistake - it can not be used.
I think it can.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
It gives a false sense of safety, and that alone for me is a good
enough reason to remove it. it is not as bad as safe_mode but simply
not good.If you use it right, it does not. Every security feature would give you
false sense of safety if you use it wrong - but that alone is not the
reason to not have it at all, if it has legitimate uses. IMO
open_basedir does.That being said I have no issue with keeping it besides the lost
opportunity to get rid of an old bad decision.Bad decision was to brand open_basedir as security function that allows
defense against attacker with PHP code execution rights. It is obvious
we can not deliver on this promise. However, it does not mean that used
differently - e.g. as a safeguard in your own code to not access things
that you don't want this code to access by mistake - it can not be used.
I think it can.
This exact example is easily done using system features.
Anyway, we have different views and that's why I started to this
thread, to know other views :)
I will still create a RFC to get an official result on that as all the
users I talked to, as well as security people, consider this feature
as a problem.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Bad decision was to brand open_basedir as security function that allows
defense against attacker with PHP code execution rights. It is obvious
we can not deliver on this promise. However, it does not mean that used
differently - e.g. as a safeguard in your own code to not access things
that you don't want this code to access by mistake - it can not be used.
I think it can.
This exact example is easily done using system features.Anyway, we have different views and that's why I started to this
thread, to know other views :)I will still create a RFC to get an official result on that as all the
users I talked to, as well as security people, consider this feature
as a problem.
I keep being told 'If you don't like it you don't have to use it' but if
you remove something that I like I have little choice. As indicated this
is NOT a security feature, but simply a ring fence which DOES pick up
silly mistakes like copying code from one branch or site to another
without correcting the paths. Something which is difficult to find in
the IDE often, but sticks out like a saw thumb in the run level.
If you can explain how to provide that ring fence another way then I'd
be happy to conciser it, but this does have a use other than some
additional magic bullet for security. It simply prevents access cross
path where a user does have valid access rights to all of the paths.
Given the right wrapper in the deployment it works well ... if you don't
like it simply switch it off ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
-1
Even when you use a dedicated user per vhost, a defense in depth strategy
where you additionally restrict the to not access /tmp or /etc seems right.*
Note containers/VM are not always available. chroot + bind mounts would
be able to provide that restriction, but it is a messy setup, both in
folder
structure and in polluting the mounts.
AppArmor can be an alternative (assuming you have that LSM in your kernel)
although you may need some trickery, as (IMHO) you can't having have a
profile with different paths depending on the uid (and goog luck on
restricting
things like the php error log).
I think you should provide -for a few of those alternatives- a recipe of
"translating"
an open_basedir to provide the same restriction. I suspect it will be
quite hard to
do (without requiring more server features -sometimes an upgrade-),
specially
when you start facing requisites like "don't allow enumerating the other
accounts
on this host".
- Obviously, this can only work if the user can't exec outside of the
php process.
PS: I also disagree with the statement «mod_php but I think it is
acceptable
as it is mostly used as development server», but it may be considered
‘right’ to
remove open_basedir even without that premise.