On 29/10/2013 10:10, Michael Orlitzky wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/28/2013 04:10 PM, Reindl Harald wrote:
php_admin_value open_basedir /var/www/$domain/$host/
php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp
php_admin_value session.save_path /var/www/$domain/$host/tmp
php_admin_value sys_temp_dir /var/www/$domain/$host/tmp
oh no - do *not* place the sesiondata anywhere inside open_basdir
this is one of the badest things you can do because any otherwise
harmless script bypassed whatever security restriction will be able
to read *any* session data
You have a point, but I wouldn't go as far as to say it's one of the
worst things you can do. If a vulnerable PHP script allows an attacker
to (at least try to) read arbitrary files, then it's possible to read
session data that lies within open_basedir. Note that they can already
read your database credentials out of config.php at that point.
But, if you put the session data under open_basedir, then it's easy to
restrict access to the entire /var/www/example.com hierarchy to the
one user that needs it: www.example.com. In the scenario I described,
I'm able to tell our customers that their websites are "physically"
separated from our other customers.
If there's a vulnerability in someone else's site, the kernel (via
filesystem ACLs) will prevent it from affecting yours. The web user
for example.NET truly cannot even traverse /var/www/example.COM, where
everything important to you is stored. This is robust against Apache,
Ruby, Python, etc. vulnerabilities as well -- not just PHP.
I already mentioned that I don't trust PHP. Our sites would be just as
secure if open_basedir stopped working tomorrow, since the filesystem
ACLs are what we trust to work. So, we trade the potential to read
sessions for that peace of mind. Not trying to downplay your
complaint, just pointing out another POV.
Some time ago, we too, evaluated the pros and cons given our design, and
we too, decided on the lesser evil and keep it under open_basedir, have
done for many many years without problem, of course I'm not so naive to
think it may never one day be a problem for a single host, when running
shared hosting there are always risks, in everything.
