Bonjour,
J'ai voulu "protéger" un fichier.php en le donnant à mon utilisateur sudoer, que j'utilise pour administrer la machine.
Sans élévation de droit, il s'agit d'un simple utilisateur lambda.
Je suis étonné de voir que le fichier.php est tout de même interprété. Est-ce normal ?
Bonjour, je pense que oui car le fichier php n'est pas un binaire. Il
a besoin de l'interpréteur PHP qui n'est pas limité aux sudoers. Du
moment que le fichier php est accessible en lecture par
l'interpréteur, il sera interprété et exécuté
Le mer. 2 oct. 2024 Ã 17:42, Bernard Bass
<bernard.bass@visionduweb.com> a écrit :
Bonjour,
J'ai voulu "protéger" un fichier.php en le donnant à mon
utilisateur sudoer, que j'utilise pour administrer la machine.
Sans élévation de droit, il s'agit d'un simple utilisateur lambda.
Je suis étonné de voir que le fichier.php est tout de même interprété.
Est-ce normal ?
J'ai voulu "protéger" un fichier.php en le donnant à mon utilisateur
sudoer, que j'utilise pour administrer la machine.
Sans élévation de droit, il s'agit d'un simple utilisateur lambda.
Je suis étonné de voir que le fichier.php est tout de même interprété.
Est-ce normal ?
Maintenant tu parles de virtual host, ce qui implique Apache..
Il faut éclaircir cela. Comment est appelé ton script ? Via une page web ?
Mais qui execute l'interpréteur ? Avec chmod 000 seul root peut
accéder au fichier. (Sauf bit sticky, que j'ai toujours un léger mal à assimiler)
Ah, tu utilises PHP fpm. Il me semble qu'on spécifier un user distinct d'apache. Il faut vérifier car je ne vais pas souvent jouer avec la
config de PHP fpm.
En tout cas je ne vois toujours pas ce que sudo a à voir avec ton
problème. Il faut que tu explique cette partie là . Peut être que c'est
un aspect inutile ?
Mes fichiers Web .php se trouvent sous le répertoire html :
-rw-rw-r-- propriétaire 33 , groupe 1004.
Normalement, on les met dans le répertoire /var/www/Groupe 1004 c'est qui ? Apache ?
user : www-data groupe : www-data
dans ce mode : -rw- rw- r--
J'ai remis le chmod 400 sur le fichier.
C'est fou que avec un chmod 000 le fichier soit lisible de l'extérieur... Tout comme je pensais vraiment qu'un utilisateur lambda ne pouvait pas executer le fichier.php.
Si je configure php fpm depuis un fichier de conf dans pool.d pour dire
à PHP d'utiliser utilisateurphp,
Alors peut être que utilisateur lamdba ne pourra plus interpréter le
echo bonjour.
J'ai voulu "protéger" un fichier.php en le donnant à mon utilisateur sudoer, que j'utilise pour administrer la machine.
Sans élévation de droit, il s'agit d'un simple utilisateur lambda.
J'ai voulu "protéger" un fichier.php en le donnant à mon utilisateur
sudoer, que j'utilise pour administrer la machine.
Sans élévation de droit, il s'agit d'un simple utilisateur lambda.
Quelle est la finalité de tout ça ?
Ce qui se pratique habituellement c'est de créer un vhost par
site/appli avec la racine
("DocumentRoot" pour Apache, "root" pour Nginx) correctement positionnée.
Le serveur Web se chargera de n'exposer que ce qui se trouve dans le
dossier racine.
Si on veut être un peu plus robuste, on peut créer un PHP FPM dédié
par site/appli.
Si on veut être encore plus robuste, on peut créer un conteneur
(Docker, LXC, autre)
par site/appli.
On peut aussi créer un serveur par site/appli, mais là ça devient
vraiment lourd pour
pas grand-chose.
Si un script est dangereux et ne devrait pas être exploitable Ã
distance, alors il faut
le sortir de la racine ou ajouter une directive spécifique pour que le serveur Web refuse
de servir les requêtes qui arrivent dessus.
Faire en sorte qu'un utilisateur lambda ne puisse pas interpréter php ?
Si d'autres personnes ont des avis sur ce problème, qu'un utilisateur
lambda du serveur puisse interpréter PHP, dans /var/www/ cela me semble étonnant, ou alors, je redécouvre que je n'ai rien compris à l'interprétation de PHP par les utilisateurs de la machine.
Tout le monde peux exécuter l'interpréteur PHP. Et c'est assez logique : interpréter du PHP n'a
rien de dangereux en soi, aucune raison de le limiter.
Sébastien
1 - s'assurer que l'utilisateur qui fait l'exécution php n'ait que les privilèges nécessaires (les droits du fichiers n'interviennent pas ÃCela est OK.
ce stade, sauf qu'il doit être lisible par le moteur php).
2 - limiter la possibilité que le script soit modifié pour faire autre chose que prévu => l'utilisateur du vhost n'a que le droit de le lire,
le droit d'écriture étant réservé à un autre compte utilisé pour faire les mises à jour. C'est sur ce dernier point que les droits du fichier
sont pertinents. Et par principe, je ne le rendrais pas exécutable, puisqu'il ne sera pas exécuté au sens système, maïs interprété par le moteur php (qui - lui - doit être exécutable pour le compte de service concerné).
2 - limiter la possibilité que le script soit modifié pour faire autre chose que prévu => l'utilisateur du vhost n'a que le droit de le lire,
le droit d'écriture étant réservé à un autre compte utilisé pour faire les mises à jour. C'est sur ce dernier point que les droits du fichier
sont pertinents. Et par principe, je ne le rendrais pas exécutable, puisqu'il ne sera pas exécuté au sens système, maïs interprété par le moteur php (qui - lui - doit être exécutable pour le compte de service concerné).
J'ai voulu "protéger" un fichier.php en le donnant à mon utilisateur
sudoer, que j'utilise pour administrer la machine.
Sans élévation de droit, il s'agit d'un simple utilisateur lambda.
Quelle est la finalité de tout ça ?
Faire en sorte qu'un utilisateur lambda ne puisse pas interpréter php ?
Ce qui se pratique habituellement c'est de créer un vhost par
site/appli avec la racine
("DocumentRoot" pour Apache, "root" pour Nginx) correctement
positionnée.
C'est le cas.
Le serveur Web se chargera de n'exposer que ce qui se trouve dans le
dossier racine.
Oui.
Si on veut être un peu plus robuste, on peut créer un PHP FPM dédié
par site/appli.
C'est fait ou en cours d'être fait. Oui.
Si on veut être encore plus robuste, on peut créer un conteneur
(Docker, LXC, autre)
par site/appli.
Totalement surchargé avec cela, trop de besoins d'apprentissage sur l'ensemble, je ne sais gérer Docker et encore moins LXC.
On peut aussi créer un serveur par site/appli, mais là ça devient
vraiment lourd pour
pas grand-chose.
Tout à fait, de 20 ans d'apprentissage nous passons à 35 ans d'apprentissage pour arriver à la conclusion que nous sommes dépassés.
Si un script est dangereux et ne devrait pas être exploitable Ã
distance, alors il faut
le sortir de la racine ou ajouter une directive spécifique pour que
le serveur Web refuse
de servir les requêtes qui arrivent dessus.
Oui cela semble logique :)
Un outil dangereux, on ne le conserve pas !
Mais au final, mon petit echo bonjour fonctionne toujours avec
l'utilisateur lambda ;)
En attente de tester avec un user configuré depuis pool.d
Si d'autres personnes ont des avis sur ce problème, qu'un utilisateur lambda du serveur puisse interpréter PHP, dans /var/www/ cela me
semble étonnant, ou alors, je redécouvre que je n'ai rien compris à l'interprétation de PHP par les utilisateurs de la machine.
On arrête jamais d'oublier qu'on savait qu'on a oublié qu'un jour on a appris qu'on a su et qu'on a oublié ...
J'ai voulu "protéger" un fichier.php en le donnant à mon utilisateur sudoer, que j'utilise pour administrer la machine.
Sans élévation de droit, il s'agit d'un simple utilisateur lambda.
Je suis étonné de voir que le fichier.php est tout de même interprété. Est-ce normal ?
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 491 |
Nodes: | 16 (2 / 14) |
Uptime: | 109:56:47 |
Calls: | 9,684 |
Files: | 13,725 |
Messages: | 6,175,782 |