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. Alexander -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
