[spip-dev] Protection du password mysql

Bonsoir,

Amené depuis quelques jours à m'interroger sur la protection d'un serveur,
je me demande s'il ne serait pas utile de mieux protéger le password mysql
dans SPIP (contenu en clair dans le fichier ecrire/inc_connect.php3). Ne
faudrait-il pas, par exemple, inclure dans la procédure d'instalation de
SPIP un chmod 600 sur ecrire/inc_connect.php3 ?

FS

Amené depuis quelques jours à m'interroger sur la protection d'un serveur,
je me demande s'il ne serait pas utile de mieux protéger le password mysql
dans SPIP (contenu en clair dans le fichier ecrire/inc_connect.php3). Ne
faudrait-il pas, par exemple, inclure dans la procédure d'instalation de
SPIP un chmod 600 sur ecrire/inc_connect.php3 ?

Non, malheureusement (du moins dans la plupart des cas). Car c'est le
serveur web (apache, www-data) qui est l'utilisateur "exécutant" les
scripts, indépendamment du répertoire en question.

-- Fil

On peut arranger ça: pour ma part, tous les fichiers de Spip ont pour proprio
moi-meme et pour groupe celui du serveur Web; ensuite on chmod à 660 pour
les fichiers, et 770 pour les répertoires et les éventuels exécutables.

esj

Si il y a des volontaires, ça mériterait certainement une doc sur
spip-contrib détaillée (comment identifier le owner et le groupe, la
fonction du chmod 640, le setup des dossiers ecrire, data, IMG et cache,
etc.). Moi-même je suis préoccupé par ce sujet mais ne connais pas assez ce
type de gestion de fichier pour l'expliquer correctement.

J'ajouterais aussi un avertissement de ne pas renommer le fichier
inc_connect.php3 avec une autre extension (pour un backup par exemple) ce
qui permettrait à quelqu'un de lire le fichier directement si il y a accès.

Cordialement,

Thierry Gagnon,
Studio Eau Moirée
http://thierrygagnon.com/

-----Message d'origine-----

Sur ce point les créateurs de SPIP pourraient-ils nous dire pourquoi ils ne
créent pas ce fichier plutot dans le répertoire data, qui a l'avantage
d'être protégé par .htaccess ? Ca permettrait du coup de rendre Read-only
le répertoire écrire (et son pere) ce qui limiterait les risques de squelettes
en PHP écrivant n'importe où.

esj

      Emmanuel

Sur ce point les créateurs de SPIP pourraient-ils nous dire pourquoi ils
ne créent pas ce fichier plutot dans le répertoire data, qui a l'avantage
d'être protégé par .htaccess ? Ca permettrait du coup de rendre Read-only
le répertoire écrire (et son pere) ce qui limiterait les risques de
squelettes en PHP écrivant n'importe où.

Réponse en deux temps :
1) héritage historique (mais gérable)
2) le répertoire data/ est réputé être effaçable sans trop de dégâts

Tout ça ne fournit pas une objection violente à ta proposition, donc.

-- Fil

C'est un argument. On pourrait le créer avec un chmod 440 ça signalerait
le danger.

esj

Deux petites choses :

>On peut arranger ça: pour ma part, tous les fichiers de Spip ont pour >proprio
>moi-meme et pour groupe celui du serveur Web; ensuite on chmod à 660 >pour
>les fichiers, et 770 pour les répertoires et les éventuels exécutables.

A première vue ce genre de chose (propriétaire du fichier/dossier = apache) me parait uniquement gérable sur un serveur avec un accès telnet / ssh ce qui n'est pas le cas d ela plus part des hébergements mutualisé. A moins que vous connaissiez un client ftp qui puisse faire çà.

Pour ma part, quand je développe en php, je préfère proteger mes fichiers inclus par un "deny from all" dans un .htaccess.

slap

Effectivement, les commandes de changements de proprio ou de groupe exigent d'etre l'administrateur de sa machine, ou que celui-ci donne accès à ces commandes (en
général en les restreignant à des répertoires bien précis). On peut aussi envoyer
un mail à l'administrateur pour lui demander de le faire: en général il ne refuse pas qu'on l'aide à sécuriser sa machine!

La technique du .htacces evite en effet la lecture de l'extérieur, mais elle n'évite
pas qu'un script écrit par un co-hébergé vienne farfouiller chez vous de l'intérieur.
C'est d'ailleurs toute la raison d'être des virtual-host d'Apache, et aussi la raison
qui pousse les administrateurs à interdire en écriture les répertoires contenants des
scripts, voire tous les répertoires du système, toute écriture devant se faire par un
SGBD. J'ai réécrit ainsi le système de cache de Spip entre autres pour cette raison,
et je préconise de faire de meme pour les accès en écriture qui reste, afin de mettre
toutes les sources en lecture seule, ce qui est le plus sur et ne demande aucune commande
privilégiée.

esj

      Emmanuel