patdef
 373 
|  Posté : 12-05-2006 09:40
Bon, je vais essayer de répondre à tes questions dans le désordre ; attention cependant, je n'ai pas la prétention d'être un expert, et je vais certainement ommettre quelques points, voire dire quelques bétises... (merci de me corriger dans ce cas)
Tout d'abord, une présentation rapide des propriétés des fichiers sous Unix/Linux pour ceux qui ne sont pas au courant (pardon pour les autres)
1) les droits sur un fichier unix sont : lecture, écriture, execution.
2) les droits possible sur un répertoire unix sont : lecture, écriture, traversé
3) ces droits sont affecté à trois catégories d'utilisateurs :
le propriétaire, les membres du groupes, les autres
Remarques :
Un fichier texte peut-etre exécutable. Cela veut dire qu'il existe un interpréteur pour ce fichier. Un peu comme un fichier bat sous ms-dos ou windows. Sauf qu'ici, ce n'est pas l'extension du fichier qui dit si le fichier doit être exécuter par le shell, mais bien sa propriété.
Un répertoire n'est pas exécutable. Mais on a la possibilité d'autoriser ou non la traversé de ce répertoire. On peut par exemple autoriser de traverser un répertoire sans voir son contenu.
En notation octal, les bits de configuration sont dans l'ordre : lecture, écritue, exécution/traversé
Donc
1 = execution/traversé
2 = écriture
3 = execution/traversé + écriture
4 = lecture
5 = lecture + execution/traversé
6 = lecture + écriture
7 = lecture + écriture + execution/traversé
Un fichier ou un répertoire sont affecté à un propriétaire et à un groupe. La notation est dans l'ordre
propriétaire, groupe, autre. Dans la notation couramment présenté sur ce forum, on donne 3 chiffres successifs : xyz.
x correspond aux droits que le propriétaire a sur ce fichier
y correspond aux droits que les membres du groupe ont sur ce fichier
z correspond aux droits des autres utilisateurs sur le fichier
Donc si vous avez bien suivi jusque là, un fichier avec les propriétes 755 est :
accessible en lecture, écriture, exécution pour le propriétaire
accessible en lecture, exécution pour les membres du groupe
accessible en lecture, exécution pour les autres
Dernière précision : de façon générale, un programme a les droits de celui qui lance le programme. Cela afin de garantir la sécurité du système. Pour les serveurs, on utilise des utilisateurs spéciaux. Ces utilisateurs n'ont pas vraiment d'existance, mais permettre de controller les actions de ces programmes. Par exemple, l'utilisateur associé à un serveur Apache peut-être www-data.
Alors, revenons à tes questions :
1er message :
Dans le tuto 2 "transfert d'un site local vers un serveur" on indique en étape 4 les chmod des fichiers à respecter. Il me semble que les chmods indiqués ne sont pas assez stricts en terme de sécurité. Par exemple un chmod 777 sur tous les répertoires et sous-répertoires, un chmod 766 sur pas mal de fichiers (l'administrateur pourrait chnager le chmod juste avant de faire une modif et ne pas permettre l'écriture entre temps), etc...
Des chmods plus stricts ne pourraient-ils pas être une barrière supplémentaire pour les hackers et autres rigolos nuisibles ?
Pourquoi le chmod 744 sur tous les fichiers PHP, et pas 544 ?
Pourquoi un chmod 777 sur les répertoires ?
Un serveur web répond aux requétes des navigateurs web. Dans le cas de npds, les pages sont dynamiques. C'est à dire que leur contenu s'adapte aux diverses requètes à l'instant où ces demandes ont lieu. Cette adaptation est faite par l'intermédiaire de fichier et d'appel à une base de donnée. Il est donc nécessaire de permettre à ce serveur d'accéder à certains fichiers en écriture. Il faut aussi que le serveur puisse créer ses propres fichiers. D'où l'accés en écriture recommandé.
Pourquoi un chmod 766 sur pas mal de fichiers ?
Comme je viens de le dire, le serveur a besoin d'écrire de façon dynamique dans certains fichiers. Ceux sont ces fichiers pour lesquelles ont autorise l'écriture.
Par contre, il n'y a pas d'intérêt a les rendres exécutables pour leur propriétaire. Il n'y a pas d'interpréteur de page php accéssible par le shell sous linux. C'est uniquement le serveur web qui se charge de les interpréter. Donc 666 conviendrait trés bien.
Pourquoi le chmod 744 sur tous les fichiers PHP, et pas 544 ?
Bon, d'abord pourquoi les rendres accessibles en écriture pour le propriétaire du fichier. Bin, pour les éditer pardis ! Mais bon, cela dépend après tout de chacun. C'est sûr que quelqu'un qui n'a nullement l'intention de changer quoi que ce soit à ces fichiers pourrait ce passer de ce droit d'écriture sur ces fichiers. Dans le doute, on conseille donc l'accés en écriture.
On considère cependant que ces fichiers ne doivent pas être modifiée par le serveur web, d'ou l'interdiction d'écriture pour les non propriétaires du fichier.
Pour le droit d'éxécution, même remarque que précédemment.
Des chmods plus stricts ne pourraient-ils pas être une barrière supplémentaire pour les hackers et autres rigolos nuisibles ?
Bin oui et non. On a besoin de créer des fichiers. On ne peut donc pas tout interdire. On concentre donc la protection sur l'interprétation des requêtes envoyés par les navigateurs. C'est les fichiers php qui assurent eux même leur protection, en vérifiant que les ordres qui leurs sont envoyés sont autorisés. L'équipe de sécurité se concentre sur cette tache, d'où peut-être leur raillerie quand à tes remarques.
Autre message :
Je pensais que la protection des fichiers par Unix pouvait interdire à une personne non autorisée de venir les modifier ou supprimer sur un serveur.
Tu pense bien, mais ici le problème vient plus des requêtes exterieur par l'interface web que du serveur lui même. Les serveurs sont pour la plupart peut accessibles. Leur administrateur ont de toute façon tous les droits qu'ils souhaitent, et une personne qui a accés à ses machines de façon frauduleuse à déjà cassé la pluspart de ses protections... Il n'y a plus grand chose à espérer protéger dans ce cas...
Enfin, chaque hébergeur à sa propre politique de gestion de ces machines. On pourrait donc en théorie sécuriser un peu plus parfois les fichiers en autorisant uniquement les membres du groupes du fichier en accés en écriture au fichier. Mais il serait possible que rien ne marche dans certains cas.
Voila, j'espère avoir été assez clair, et n'avoir pas dit trop de conneries... |
