Posté par jseb .
Évalué à 3 (+1/-0).
Dernière modification le 26 octobre 2024 à 15:52.
Intéressant, je ne connaissais pas ces fonctions.
En shell, j'utilise la var dollar-dollar qui n'est pas prédictible facilement, sauf si un virus est déjà à l'écoute des process (dans ce cas, $$ est le moindre des problèmes).
J'avoue que c'est pour éviter les collisions que j'utilise $$ , pas pour une histoire de prédictibilité.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
Posté par jseb .
Évalué à 2 (+0/-0).
Dernière modification le 26 octobre 2024 à 19:40.
Les arguments avancés contre $$ sont en général (j'ai fait une recherche pour ne pas en oublier):
1) Incohérences et collisions : Si un script utilise $$ pour nommer un fichier temporaire, chaque exécution aura un nom de fichier différent (car le PID change pour chaque exécution). Cela peut provoquer des incohérences si le script s'attend à retrouver ce fichier par la suite.
-> je n'utilise pas $$ directement , je le stocke dans une variable temporaire.
2) Sécurité et vulnérabilité aux attaques : Utiliser $$ dans le nom de fichier peut rendre le script vulnérable aux attaques par liens symboliques. Un attaquant peut deviner le PID du processus et créer un lien symbolique pointant vers Dieu sait quoi.
-> il est vrai, mais mktemp ne protégera pas davantage (voir plus loin)
3) Problèmes de nettoyage : Si le script ne se termine pas correctement, le fichier temporaire créé avec $$ pourrait rester sur le disque. En cas de redémarrage ou de nouvelle exécution du script, un fichier temporaire précédent pourrait être confondu avec celui de la nouvelle exécution, surtout si le PID se reproduit après un certain temps.
-> j'efface toujours $TMP en sortie. Si par le plus grand des hasards mon script plantait, était relancé et que j'avais fait un tour du compteur des PID pour retomber sur le même nom de fichier (si j'arrive à ça, je crois que je vais tenter un loto), ma première écriture dans le fichier va le tronquer si il existait déjà (la première écriture est une redirection simple avec > ).
Maintenant, voyons le cas de mktemp qui est censé compliquer la vie de l'attaquant et être « plus sécurisé ».
Voici un script shell qui ne fait pas grand chose, à part créer un fichier temporaire et passer ensuite son temps à d'obscurs traitements inclusifs.
Posté par Nicolas-info .
Évalué à 3 (+3/-0).
Dernière modification le 26 octobre 2024 à 20:00.
La sécurité ne repose pas sur le secret du nom du fichier, mais sur l'appel système open : avec les bons paramètres le noyau DOIT créer le fichier, et REFUSE d'ouvrir un fichier existant. C'est la mécanique qui garantit que le propriétaire du fichier est bien celui de l'appelant.
PS : cette mécanique est utile en programmation pure Unix pour implémenter un mutex entre processus.
L'attaquant ne peut pas prendre les droits sur le fichier. Soit il les avait parce qu'il a créé lui-même le fichier : alors l'appel à `open échoue. Soit tu obtiens les droits et là il ne peut plus les prendre (c'est l'objectif du sticky bit dans le cas d'un répertoire partagé).
Le nom aléatoire c'est juste pour éviter les collisions. Ça joue, mais plus à la marge sur la sécurité.
$TMPDIR est une variable d'environnement. Elle contient le chemin d'un répertoire persistant, comme son nom ne l'indique pas, pour des fichiers de travail.
Si, et seulement si, elle n'est pas valorisée alors faute de mieux les fonctions mk*temp doivent se rabattre sur /tmp. Fondamentalement c'est un fallback.
Conclusions : valorisez $TMPDIR vers un espace privé. Problème réglé.
Dans le même ordre d'idée j'ai jamais trop bien compris la politique des distros avec le umask.
Tout à fait et merci pour les explications complémentaires.
À ma connaissance dans les distributions actuelles les variables $TMPDIR ou $TEMP ne sont pas défnies. Beaucoup d'outils vont utiliser par défaut /tmp (et aussi /var/tmp pour systemd).
Pour les scripts il peut être pertinent d'utiliser $XDG_RUNTIME_DIR (/run/user/$UID) qui est un répertoire accessible uniquement à l'utilisateur, monté en tmpfs.
** We can’t remove sticky bit support from the kernel** as long as there’s a global /tmp, even if it is sometimes hidden by an overlay.
Pourquoi veut-il faire ça ? Le sticky bit sur un répertoire est très utile, utilisé ailleurs et bien suffisant dans beaucoup de cas d'utilisation. De plus il me semble que si on supprime le support du sticky bit dans Linux, celui-ci ne serait plus posix compatible.
Il me semble bien que souvent, la partition/tmp est plus petite qu'une tique et plus volatile que l'ether1. Des logiciels comme Blender (un merveilleux logiciel de 3D libre ❤️) ou Nuke (un logiciel de compositing propriétaire 🥺) par exemple, s'en servent pour l'enregistrement automatique des scènes ouvertes. Sauf qu'une scène Blender ou Nuke, ça peut être assez volumineux, et donc peut saturer le /tmp rapidement.
Si on ajoute que la solution vite-faite-mal-faite-mais-efficace à cette saturation qui provoque des problèmes est le reboot de la machine, et bien les fichiers de sauvegardes automatiques sont perdus2.
Magique non ?
toute ressemblance avec une balade en forêt serait fortuite ↩
Pour ce genre de logiciel et de besoin on peut prendre le temps de configurer sa machine selon ses besoins !
Cela évite aussi que, par défaut, chaque logiciel commence à écrire ses fichiers temporaires un peu partout sur le disque avec comme conséquence de devoir gérer la persistance de ces fichiers dans chaque application.
Posté par Voltairine .
Évalué à 1 (+0/-0).
Dernière modification le 28 octobre 2024 à 09:55.
La plupart du temps il n'y a pas de partition dédiée pour /tmp. Et si elle existe c'est un choix réfléchi de l'utilisateur. Le montage sur disque ou en tmpfs est aussi un choix délibéré de l'utilisateur. Donc c'est un faux problème.
Au cas où, c'est bien pour cela que les logiciels devraient utiliser $XDG_RUNTIME_DIR pour stocker leurs fichiers temporaires. C'est d'ailleurs ce qu'ils font en général.
# mkstemp / mkdtemp
Posté par jseb . Évalué à 3 (+1/-0). Dernière modification le 26 octobre 2024 à 15:52.
Intéressant, je ne connaissais pas ces fonctions.
En shell, j'utilise la var dollar-dollar qui n'est pas prédictible facilement, sauf si un virus est déjà à l'écoute des process (dans ce cas, $$ est le moindre des problèmes).
J'avoue que c'est pour éviter les collisions que j'utilise $$ , pas pour une histoire de prédictibilité.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: mkstemp / mkdtemp
Posté par Voltairine . Évalué à 3 (+2/-0). Dernière modification le 26 octobre 2024 à 17:08.
Tu devrais (re)lire la doc. C'est une façon de faire assez ancienne et peu sûre.
Si tu vraiment besoin de fichier temporaire utilise mktemp qui est sécurisé.
[^] # Re: mkstemp / mkdtemp
Posté par jseb . Évalué à 2 (+0/-0). Dernière modification le 26 octobre 2024 à 19:40.
Les arguments avancés contre $$ sont en général (j'ai fait une recherche pour ne pas en oublier):
1) Incohérences et collisions : Si un script utilise $$ pour nommer un fichier temporaire, chaque exécution aura un nom de fichier différent (car le PID change pour chaque exécution). Cela peut provoquer des incohérences si le script s'attend à retrouver ce fichier par la suite.
2) Sécurité et vulnérabilité aux attaques : Utiliser $$ dans le nom de fichier peut rendre le script vulnérable aux attaques par liens symboliques. Un attaquant peut deviner le PID du processus et créer un lien symbolique pointant vers Dieu sait quoi.
3) Problèmes de nettoyage : Si le script ne se termine pas correctement, le fichier temporaire créé avec $$ pourrait rester sur le disque. En cas de redémarrage ou de nouvelle exécution du script, un fichier temporaire précédent pourrait être confondu avec celui de la nouvelle exécution, surtout si le PID se reproduit après un certain temps.
Maintenant, voyons le cas de mktemp qui est censé compliquer la vie de l'attaquant et être « plus sécurisé ».
Voici un script shell qui ne fait pas grand chose, à part créer un fichier temporaire et passer ensuite son temps à d'obscurs traitements inclusifs.
Ce qui donne:
Mais pendant ce temps …
Et voilà.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: mkstemp / mkdtemp
Posté par Nicolas-info . Évalué à 3 (+3/-0). Dernière modification le 26 octobre 2024 à 20:00.
La sécurité ne repose pas sur le secret du nom du fichier, mais sur l'appel système open : avec les bons paramètres le noyau DOIT créer le fichier, et REFUSE d'ouvrir un fichier existant. C'est la mécanique qui garantit que le propriétaire du fichier est bien celui de l'appelant.
PS : cette mécanique est utile en programmation pure Unix pour implémenter un mutex entre processus.
[^] # Re: mkstemp / mkdtemp
Posté par jseb . Évalué à 2 (+0/-0).
Ok mais en quoi cela protège t-il d'une attaque par substitution ?
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: mkstemp / mkdtemp
Posté par Nicolas-info . Évalué à 2 (+2/-0).
L'attaquant ne peut pas prendre les droits sur le fichier. Soit il les avait parce qu'il a créé lui-même le fichier : alors l'appel à `open échoue. Soit tu obtiens les droits et là il ne peut plus les prendre (c'est l'objectif du sticky bit dans le cas d'un répertoire partagé).
Le nom aléatoire c'est juste pour éviter les collisions. Ça joue, mais plus à la marge sur la sécurité.
[^] # Re: mkstemp / mkdtemp
Posté par David Demelier (site web personnel) . Évalué à 2 (+0/-0).
Clairement pas, c'est le meilleur moyen de faire un TOCTOU. En plus la fonction a été retiré de POSIX.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: mkstemp / mkdtemp
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Dans le contexte je pense qu'il est clair qu'il parle de la commande
mktempd(1)et pas de la fonctionmktempd(3).La commande n'a pas besoin de la fonction pour exister, elle peut utiliser
mkdtemp(3)ou un simple open avecO_CREAT | O_EXCL.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mkstemp / mkdtemp
Posté par Voltairine . Évalué à 1 (+0/-0).
Effectivement il s'agit de la commande mktemp des outils GNU. C'est expliqué dans l'article et j'ai donné le lien vers la doc GNU.
# Petite précision
Posté par Nicolas-info . Évalué à 2 (+2/-0).
$TMPDIR est une variable d'environnement. Elle contient le chemin d'un répertoire persistant, comme son nom ne l'indique pas, pour des fichiers de travail.
Si, et seulement si, elle n'est pas valorisée alors faute de mieux les fonctions mk*temp doivent se rabattre sur /tmp. Fondamentalement c'est un fallback.
Conclusions : valorisez $TMPDIR vers un espace privé. Problème réglé.
Dans le même ordre d'idée j'ai jamais trop bien compris la politique des distros avec le umask.
[^] # Re: Petite précision
Posté par Voltairine . Évalué à 2 (+1/-0).
Tout à fait et merci pour les explications complémentaires.
À ma connaissance dans les distributions actuelles les variables $TMPDIR ou $TEMP ne sont pas défnies. Beaucoup d'outils vont utiliser par défaut /tmp (et aussi /var/tmp pour systemd).
Pour les scripts il peut être pertinent d'utiliser $XDG_RUNTIME_DIR (/run/user/$UID) qui est un répertoire accessible uniquement à l'utilisateur, monté en tmpfs.
# Il y a quand même un truc qui me fait bondir dans son commentaire
Posté par totof2000 . Évalué à 5 (+3/-0).
Pourquoi veut-il faire ça ? Le sticky bit sur un répertoire est très utile, utilisé ailleurs et bien suffisant dans beaucoup de cas d'utilisation. De plus il me semble que si on supprime le support du sticky bit dans Linux, celui-ci ne serait plus posix compatible.
[^] # Re: Il y a quand même un truc qui me fait bondir dans son commentaire
Posté par Luc-Skywalker . Évalué à 4 (+2/-0).
En plus, ça m'a pris des années et des années pour comprendre, à peu près, comment ça marche et à quoi ça sert.
"Si tous les cons volaient, il ferait nuit" F. Dard
# Et la taille
Posté par cg . Évalué à 1 (+0/-1).
Il me semble bien que souvent, la partition
/tmpest plus petite qu'une tique et plus volatile que l'ether1. Des logiciels comme Blender (un merveilleux logiciel de 3D libre ❤️) ou Nuke (un logiciel de compositing propriétaire 🥺) par exemple, s'en servent pour l'enregistrement automatique des scènes ouvertes. Sauf qu'une scène Blender ou Nuke, ça peut être assez volumineux, et donc peut saturer le /tmp rapidement.Si on ajoute que la solution vite-faite-mal-faite-mais-efficace à cette saturation qui provoque des problèmes est le reboot de la machine, et bien les fichiers de sauvegardes automatiques sont perdus2.
Magique non ?
toute ressemblance avec une balade en forêt serait fortuite ↩
pure fiction 😅 ↩
[^] # Re: Et la taille
Posté par Jérôme FIX (site web personnel) . Évalué à 2 (+1/-0).
Cela se paramètre: aussi bien pour la taille de /tmp que pour le répertoire de destination dans blender (fichiers temporaire, autosaves, ..).
https://docs.blender.org/manual/en/latest/advanced/blender_directory_layout.html#temp-dir
Pour ce genre de logiciel et de besoin on peut prendre le temps de configurer sa machine selon ses besoins !
Cela évite aussi que, par défaut, chaque logiciel commence à écrire ses fichiers temporaires un peu partout sur le disque avec comme conséquence de devoir gérer la persistance de ces fichiers dans chaque application.
[^] # Re: Et la taille
Posté par Voltairine . Évalué à 1 (+0/-0). Dernière modification le 28 octobre 2024 à 09:55.
La plupart du temps il n'y a pas de partition dédiée pour /tmp. Et si elle existe c'est un choix réfléchi de l'utilisateur. Le montage sur disque ou en tmpfs est aussi un choix délibéré de l'utilisateur. Donc c'est un faux problème.
Au cas où, c'est bien pour cela que les logiciels devraient utiliser $XDG_RUNTIME_DIR pour stocker leurs fichiers temporaires. C'est d'ailleurs ce qu'ils font en général.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.