Bug#499191: Possible security issues
Stefan Fritsch wrote:
>> If a user is allowed to create a php script that will be executed
>> as www-data, he can just go read everyone else's data (like a
>> config.php which includes passwords to databases etc), because
>> everyone else's data must be readable by www-data to get served by
>> apache in this setup.
> You are just considering pure web servers. On a machine that has a web
> server running but is also used for other things, users' home
> directories will contain many things that are not readable by the
> user www-data. If you have some insecure cgi script that allows to
> read arbitrary files, every local user would be able to read
> ~/.ssh/id_rsa of every other local user. This is not possible with
> the current, tighter suexec.
I wasn't just considering web servers. On a shell server, regular users
can't execute suexec (only www-data can). I'm only considering the case
where www-data is a trusted user (as in, regular users can't execute
things as www-data).
You're right though that if there's an insecure cgi, that allows to read
any file, then you've got a problem. Whether this cgi is in the users
docroot, or in the cgi_docroot I'm proposing, that doesn't matter.
Instead of having each user install their own modified copies of some
cgi, I prefer doing it myself in one central place.
>> Because of that, I don't think there are many setups allowing
>> script execution as www-data, but yes, in such a case there is a
>> side-effect with my suggestion, that most admins would not suspect.
> It's rather easy to get such a setup:
> aptitude install apache2 libapache2-mod-php5
> a2enmod userdir
> The default mod_php config allows it. Probably this should be changed.
Yeah I know. It's easy to setup, performant (no suexec overhead), but
horrible security wise.