C'est aussi ce qui était possible sur twitter via des blocklists, et ça a aussi fait rager des twittos, car "on se retrouve sur une blocklist sans savoir pourquoi".
Et par exemple, tu trouves des articles qui critiquent le concept parce que les terroristes l'utilisent.
Ou d'ouvrir un 2eme compte sur une instance QAnon.
Il y a des solutions, et plus je lit les discussions sur les bans, les modérations, ici et et ailleurs, maintenant et par le passé) et les personnes non fachos impliquées, plus j'ai le sentiment que c'est pas le principe qui dérange, mais bien la vexation personnelle qui leur est infligé.
Et on pourrait se dire que c'est pas grave, mais il y a aussi des personnes qui ne supportent pas ça du tout, cf les discussions autour du Rejection Sensitive Dysphoria. Le syndrome en lui même est pas forcément bien établi, et semble être controversé au sein des personnes concernés comme j'ai pu le voir en cherchant sur le sujet, mais si une partie de la population semble en souffrir, il y a sans doute quelque chose à creuser.
Et si on rajoute à ça un certain manque de retenue (car bon, les gens qui râlent sur le fait de se faire bannir, y en a aussi qui sont des rageux de classe mondiale), on se retrouve avec des gens extrêmement motivés pour tenter de rationaliser leurs inconforts via des raisonnements qui fleurent parfois la mauvaise foi, et avec qui je pense que la discussion est sans doute impossible.
Tu peux pas parler d'un point A si en vérité, c'est un point B inconscient qui coince et que la personne ne se rends pas compte que ce point B existe, et s'oppose via des émotions fortes à une discussion posé (émotion forte comme la colère, mais pas que).
Sauf erreur de ma art, c'est du bruteforce via des boitiers spécifiques qui vont simuler le fait d'être un clavier et qui vont relancé le tel au bon moment.
Du coup, ça devient surtout une question de timing (e.g., combien de temps avant que ça casse), et de coût vu qu'il faut le boitier, donc de la paperasse pour l'opérer, donc les flics doivent pas le faire systématiquement. Et que les dits boitiers sont pas gratuits.
C'est quand même assez souvent des questions de pognon.
1 mois, ça peut être tendu. Si il faut attendre que le fournisseur fasse le patch puis valide ça (voir attende un autre correctif pour faire 1 release), puis que tu fasses pareil via prod/prepod/etc la mise à jour, et que ça doit tomber dans une fenêtre spécifique pour un reboot, je peux voir comment ça peut coincer.
Par exemple, le département info chez nous avait une fenêtre ou on ne touche à rien sur certains serveurs, juste avant la fin du trimestre. Donc 3 semaines avant, et 15 jours après, il y a pas de reboot sur certains services sauf demande spécifique autorisé par plusieurs directeurs.
C'est facile de louper les questions de timezone surtout sur un pays qui n'est pas le tien.
Ensuite, dans un monde idéal, on devrait faire plus rapidement les mises à jours, mais parfois, ça arrive.
Il suffit de garder ça dans le journal, mais d'avoir rsyslog qui va aussi faire le tri et écrire dans un fichier à part vu que c'est ce qui est voulu (et à mon sens, c'est pas une préoccupation de l'appli, mais du déploiement, donc ça doit être en dehors de l'appli).
Ça me parait plus générique et flexible que d'avoir en effet des fichiers de logs spécifiques pour chaque application.
Donc tu parles d'un cas ou il n'y a pas un buffer overflow (ou autre détournement bas niveau), donc je ne peux pas avoir de l’exécution de code complète dans l'espace mémoire du programme, mais je peux avoir un exec/system arbitraire sur un programme qui existe déjà sur le disque ?
Par exemple, le programme passe des variables mal échappées venant de dehors.
Si c'est le cas, ça veut dire qu'il y a déjà un appel à exec/system. Et si tu as un exec/system dans le programme principal, tu as une dépendance vers un autre binaire, donc il faut la gérer.
Suivant le type de binaire, le raisonnement n'est pas le même. Si c'est 2 binaires statiques qui s'appellent, oui, tu peux en effet réussir à éviter d'avoir un gestionnaire de paquet dans le conteneur final. Mais je pense que c'est assez rare, et la question se pose de pourquoi ne pas mettre tout dans 1 seul binaire, ou dans 2 conteneurs séparés.
Si un des 2 programmes est fourni ailleurs ou n'est pas statique, par exemple via ta distro (exemple, tu lances imageMagick), alors tu va sans doute hériter d'un gestionnaire de paquet dans le conteneur pour installer le binaire et ses éventuels dépendances, et tu peux pas utiliser "FROM scratch" + "COPY from" facilement.
Mais du coup, si tu as dnf/apt/pip dans le conteneur et une faille qui permet d’exécuter un programme arbitraire mais qui doit exister, il suffit d'installer un paquet vérolé pour exécuter du code (en l'absence d'autre mesures de protection).
Par exemple, "pip install --user monpaquetpasverolé".
Et si tu utilises system (en tout cas en python), il y a des chances que ça tire aussi un shell pour son fonctionnement que tu ne peux pas retirer, ce qui donne plein de primitives funs (cat/echo, etc).
Il y a des outils qui permettent d'assembler des conteneurs sans avoir de gestionnaire de paquets à l'intérieur (e.g. apko, si je comprends bien), mais ça reviens à changer un peu tout le fonctionnement (et sans doute de distro).
Et n'oublions pas aussi que si tu as python/ruby/perl/node dans le conteneur pour lancer le programme ruby/perl/python/node, tu as aussi defacto de quoi lancer des onliners, donc je pense qu'un ménage visant à retirer les dépendances ne va pas aider pour la sécurité si tu as un interpréteur que tu peux pas retirer.
Je suis assez surpris de ce commentaire lapidaire (et j'imagine le -1 qui vient avec).
Je suppose que le titre du lien ne plaît pas, mais j'ai comme habitude de reprendre le titre du site et de ne pas éditorialiser (sauf quand ça rentre pas), et soyons franc, c'est assez clair sur ce que le site veut transmettre, je ne pense pas que j'aurais fait mieux (sauf à traduire)
Ensuite, peut être que tu estimes que ça n'a pas sa place sur Linuxfr. Mais vu qu'il y a eu déjà 3 liens en rapport avec Twitter, je suppose que c'est pas le cas.
Et je pense qu'une coalition de 60 associations, dont un bon paquet d'assez importante dans la lutte contre l’extrémisme et l’extrême droite US, c'est pas négligeable.
Le lien que tu donnes ne dit pas d’où ça vient (mais en même temps, dockerhub est pas terrible pour ça). L'avantage des registres de Gitlab et Github, c'est que tu as une idée rapide d'où vient le code.
Intéressant. J'aurais un peu peur de choses comme les chargements dynamiques (ctypes) et les os.exec en tout genre, mais je suppose qu'il suffit de tester.
En node, l'exemple que j'ai, c'est ethercalc, dont le conteneur pèse 1G. J'ai pas le sentiment que ça soit justifier pour un tableur web.
Je vous demande donc de m'excuser pour cet acte d'obscurantisme
bien indépendant de ma volonté.
Je vous en sais gré.
Et en vrai, il n'y a pas de shell.
Supposons qu'un attaquant arrive à avoir la capacité d’exécuter du code dans le processus du conteneur (genre, un buffer overflow classique sans protection).
Il est vrai que le plus simple est de lancer un shell surtout si c'est ce qui traîne dans les exploits publiques, ou une commande.
Mais en pratique de nos jours, il y a des kits tout fait pour contourner ce genre de limitation (exemple metasploit ). Donc le bénéfice est la en théorie (genre, ça va coincer des débutants qui prennent un truc tout fait), mais en pratique, ça se contourne sans trop de moyens.
Si c'est simple de builder et de faire le ménage (exemple en go ou en rust), ouais, ça vaut le coup.
Par contre, je me prendrais pas forcément la tête pour nettoyer un truc en python ou en node au nom de la sécurité car l'effort risque d'être trop grand pour un bénéfice pas ouf (si on reste que sur la sécurité).
L'effet collatérale est que cela minimise la surface d'attaque
et doit probablement améliorer la sécurité.
J'ai des réserves. La surface d'attaque dépend de ce que tu exposes, et donc de l'application principal du conteneur (en supposant 1 conteneur == 1 process).
Avoir gcc et ImageMagick dans le conteneur ne va rien impacter si ton process ne les utilisent pas, car les attaquants ne vont pas pouvoir y toucher. On peut sans doute trouver des cas tordus, mais ça me semble être l'exception plus que la régle.
Ne pas activer des fonctionnalités que tu n'utilise pas va réduire la surface d'attaque mais ça n'est pas pareil. Et retirer les composants que tu n'utilise pas va réduire les alertes des scanners (qui sont un peu con quand même), mais ça ne réduit pas la surface d'attaque mais juste sa perception.
Ensuite, les autres raisons (réduire la bande passante et le stockage) sont largement suffisantes pour moi, il n'y a pas besoin de ressortir la sécurité à tout bout de champ car ça ne fait qu'obscurcir ce qui est important et ce qui l'est moins à ce niveau.
il donne la parole à toute la planète, pour le meilleur et pour
le pire.
Toute la planète qui a un accès internet et de la familiarité avec la technologie.
Je veux bien que Twitter donne la parole à beaucoup de monde, mais ça reste une bulle restreint à une partie de la population (indépendamment de savoir si la bulle en question est statistiquement représentative sur plusieurs axes autres comme l'age, le sexe, etc).
Mais donc si je donne mon numéro de téléphone à Meta, puis que j'en change, il se passe quoi pour la personne qui récupère le numéro aprés ?
Meta est en tort parce que j'ai pas dit que c'est plus le mien, ou on suppose que Meta doit vérifier tout les 3 mois que c'est encore valable pour ne pas être dans l'illégalité ?
Et je rappelle à toute fin utile qu'il y a aussi des cas ou il n'y a pas besoin du consentement dans le RGPD (les cas b à f du point 1 de l'article 6).
Personnellement je trouve Mastodon très bien comme ça et,
franchement ne pas avoir la même fange que sur Twitter me va
tout à fait.
Alors, je suis assez curieux de savoir ce que tu appelles la même fange, parce je comprends bien que Twitter pose souci, mais comme j'ai pas de compte, je ne sais pas ce que ça recouvre exactement.
Par exemple, si je me trompe pas, une partie des disputes ou des interactions vigoureuses sont une question d'asymétrie dans l'interface. Si je voit un message d'un compte, je ne vois pas les 300 réponses que ce compte voit, et ma réponse va se rajouter alors que je me dit que je vais juste participer (c'est sans doute pour ça qu'on voit 5 fois la même blague dans certains threads, car le compte qui réponds ne voit pas les 4 autres).
Et de ce que je vois de Mastodon, c'est pareil. Je vois les toots de mon chef, mais pas le fil sauf si je vais voir spécifiquement le fil. Il y a donc pas de raisons autre que le manque de visibilité pour éviter ce souci. Et le manque de visibilité est lié en parti à la taille réduite d'un serveur moyen.
De même, la question de la visibilité est souvent imputé à l'Algorithme. Si ton message est populaire alors plus de gens vont le voir, et bad things happen. Mais le mécanisme est fondamentalement la aussi via la fédération. Si on te suit et qu'on interagit depuis un autre serveur, alors la discussion va être visible pour plus de gens, avec ce que ça implique comme risque de débordement.
La seule différence est que pour le moment, le réseau n'a pas passé la taille ou ça arrive assez souvent pour être un problème, mais est ce que ça ne va pas arriver avec le fait d'avoir plus de monde ?
Bah, ton serveur est connecté aux autres, donc tes messages apparaissent pour les gens qui s'abonnent à ton flux, et tu n'as que les gens à qui tu t'es abonné.
Ou tu veux ne pas voir les messages des gens auquel tu n'es pas abonné, mais que les gens voient les tiens sans avoir besoin de le demander ?
pas d'indicateurs, mais ça peut se faire du coté du client
pas de notifications (ça, je suppose que ça va pas être rajouté vu que ça doit être coté serveur)
pas de quote tweets. Je comprends l'argument, mais c'est aussi trompeur, car si ton but est d'afficher quelqu'un, suffit de le faire avec un screenshot. Donc j'aurais tendance à demander à voir.
pas de recherche intégral par défaut. Ce qui a mon sens n'est qu'une question de temps avant que quelqu'un indexe les serveurs.
Je suis dubitatif sur les 4 fonctions en questions, car Twitter n'a pas rajouté ça pour faire joli, et je doute que les besoins initiaux aient disparus, au moins pour le dernier. La capacité à fouillé le passé pour le harcèlement est aussi la capacité à fouiller pour voir ce qui se dit sur un sujet, et je pense que c'est un besoin qui peut être légitime pour se renseigner sur un sujet.
Sur openshift, chaque conteneur tourne dans un contexte selinux séparé (en utilisant MCS ), et sur ma Fedora, les conteneurs tournent aussi via une politique SELInux qui bloque l’accès au fs (ce qui fait que je doit changer le label des fichiers pour donner accès). Il y a quelques articles sur https://github.com/containers/container-selinux
Donc si jamais un process arrive à contourner les limitations des namesapces suite à une faille, il reste encore les permissions SELinux pour éviter de faire trop de choses.
Et Openshift par défaut bloque le fait de lancer un conteneur en temps que root, en mappant root vers autre chose automatiquement via les userns.
Il faut donc comprendre « officielle à docker » et non «
officielle au projet conteneurisé »…
Pour la défense de Docker, ça a pu changer depuis que l'article a été posté. Je ne connais pas assez Debian pour savoir.
Mais oui, c'est un peu le souci. Je trouve que l'approche de Fedora consistant a publier son propre registre intéressante, vu que tu sais que c'est fait par le projet vu que le domaine corresponds.
Je ne veux pas reconstruire les images à partir du dockerfile,
ce sont des images externes que j'utilise, que je n'ai pas
créées moi-même. Je veux un moyen de mettre à jour les
distributions des images présentes sur dockerhub
C'est sans doute mort. Les devs de logiciel se sont lancés sur docker en se disant "ça va éviter de faire le taf des distributions", mais c'est une connerie, ça évite pas les distributions du tout, ça obscurcit le tout.
Les conteneurs sont un outil et un format d'image pour distribuer des logiciels. Mais il n'y a pas de solution technique pour la question de la curation de contenu, et c'est ce qui coince ici.
Fedora a tenté de pousser ça, des conteneurs basés sur Fedora utilisant les paquets et avec des standards et une gestion des versions. Ça n'a pas trop décollé que je sache.
Et Dockerhub vise plus à avoir tout le monde pour des questions de croissances que de devoir faire un choix, donc tu as effectivement plein de trucs douteux.
Alors pour ça, j'ai un certain nombre de choses, car la sécurité, c'est vaste (tm)
Primo, j'expose pas les conteneurs directement, mais j'ai un proxy devant. Ça permet d'éviter les soucis liés à de la crypto pas à jour (bien que je pense que ça soit rarement applicable en pratique), et ça m'assure des logs. Ça permet aussi d'éviter les soucis dans le gestion du protocole HTTP en utilisant une pile éprouvé (en l’occurrence, apache httpd ou HAProxy).
Ensuite, j'utilise SELinux. Au taf, c'est directement dans la plateforme (Openshift), chez moi, c'est directement dans l'OS, les conteneurs ne tournent pas en root autant que possible. Le but est d'éviter les sorties du conteneur trop facile en cas d'execution dans le conteneur.
Ensuite, je prends pas n'importe quel image, et je fait mes propres images ou mes propres déploiements.
J'essaye de partir d'images de distros en vérifiant que c'est bien officiel, avec l'orga derrière et pas juste un dev.
L'exemple de Debian est un bon cas, car je ne connais pas la situation maintenant, mais avant, c'était un peu bizzare.
J'essaye donc de faire mes images et d'automatiser la recompilation via une CI, en utilisant les paquets de la distro autant que possible.
L'exemple que j'ai, c'est un dépôt github qui recompile les images toutes les semaines et qui changent automatiquement la version de base de Fedora:
Donc je sais que si je déploie un site sur hugo ou zola, la CI qui recompile le site en prenant mon conteneur va utiliser la dernière stable du logiciel qui tourne sur la dernière Fedora automatiquement (ou avec grosso modo 1 semaine de délai). Il faut juste que je clique un bouton tout les 6 mois, ou que je fasse un commit pour pas que github coupe la CI (et j'imagine, à terme, que je nettoie le dépôt).
J'évite les images des projets qui utilise node ou python comme base parce que je ne sais pas ce qu'il y a dedans ou à quoi m'attendre. Parfois, je prends des images pour tester (par exemple, grist), ou pour des trucs que j'estime mineur et difficile à exploiter (par exemple, ethercalc), mais pour la production, je passe plus de temps à faire gaffe.
Et c'est pas tant la sécurité qui me chagrine (car ça reste assez rare) que les incompatibilités qui peuvent arriver (l'exemple que j'ai est sur un blog qui est en panne, mais c'était une histoire d'userspace Ubuntu qui ne marche pas sur une Fedora, et qui casse de façon subtil).
Par contre, systemd a éliminé la chiadée de scripts d'init
qu'il fallait constamment maintenir, par exemple.
Ou les bugs impossible à corriger sans réimplementer systemd.
Je n'ai plus le lien, mais il y avait une race condition (je crois) dans le script bind de Debian du au fonctionnement de named (qui utilise les signaux pour s'eteindre), race condition impossible à éviter sans l'usage des cgroups.
Mais on a largement commentés systemd y a 7 ans, il faut vraiment lire les archives.
Ansible fait partie de la seconde catégorie pour moi, et n'est
peut-être pas vraiment utilisé par les communautés BSD. Mais le
support en question dépend plus d'Ansible que des BSD.
Visiblement oui, il n'y a pas eu beaucoup d'usage d'Ansible.
Ensuite, c'est mon point. L'adéquation d'un OS pour le serveur, c'est aussi lié à la qualité de son écosystème, et pour le logiciel libre, c'est directement lié au fait qu'assez de personnes l'utilisent pour ça.
Et ce que j'ai vu, c'est que des choses que j'avais supposé comme de base sur un système Linux (avoir un moyen d'installer un serveur automatiquement, avoir des images cloud officiels, avoir un support basique pour des outils populaires) ne le sont pas forcément.
Et pour en revenir au point de base, si ça n'était qu'une question de hardware, ça irait, parce qu'on peut s'en sortir avant des achats judicieux ou de l'occase. Ça coûte un peu d'argent si tu dois changer ton matos, mais on s'en sort.
Sortir 50€ pour une carte wifi qui marche, c'est chiant, mais ça va.
Par contre, quand c'est du logiciel, l'investissement pour faire marcher est différent, et plus coûteux.
[^] # Re: Concernant la censure
Posté par Misc (site web personnel) . En réponse au journal Mastodonte contre oiseau bleu : bouquet de liens. Évalué à 5.
C'est aussi ce qui était possible sur twitter via des blocklists, et ça a aussi fait rager des twittos, car "on se retrouve sur une blocklist sans savoir pourquoi".
Et par exemple, tu trouves des articles qui critiquent le concept parce que les terroristes l'utilisent.
[^] # Re: Auto-hébergement
Posté par Misc (site web personnel) . En réponse au journal Mastodonte contre oiseau bleu : bouquet de liens. Évalué à 5.
Ou Gotosocial. Même si c'est encore en alpha, c'est utilisable et prometteur.
[^] # Re: Concernant la censure
Posté par Misc (site web personnel) . En réponse au journal Mastodonte contre oiseau bleu : bouquet de liens. Évalué à 6.
Ou plus simplement via des flux RSS/Atoms.
Ou d'ouvrir un 2eme compte sur une instance QAnon.
Il y a des solutions, et plus je lit les discussions sur les bans, les modérations, ici et et ailleurs, maintenant et par le passé) et les personnes non fachos impliquées, plus j'ai le sentiment que c'est pas le principe qui dérange, mais bien la vexation personnelle qui leur est infligé.
Et on pourrait se dire que c'est pas grave, mais il y a aussi des personnes qui ne supportent pas ça du tout, cf les discussions autour du Rejection Sensitive Dysphoria. Le syndrome en lui même est pas forcément bien établi, et semble être controversé au sein des personnes concernés comme j'ai pu le voir en cherchant sur le sujet, mais si une partie de la population semble en souffrir, il y a sans doute quelque chose à creuser.
Et si on rajoute à ça un certain manque de retenue (car bon, les gens qui râlent sur le fait de se faire bannir, y en a aussi qui sont des rageux de classe mondiale), on se retrouve avec des gens extrêmement motivés pour tenter de rationaliser leurs inconforts via des raisonnements qui fleurent parfois la mauvaise foi, et avec qui je pense que la discussion est sans doute impossible.
Tu peux pas parler d'un point A si en vérité, c'est un point B inconscient qui coince et que la personne ne se rends pas compte que ce point B existe, et s'oppose via des émotions fortes à une discussion posé (émotion forte comme la colère, mais pas que).
[^] # Re: on n'est pas sorti de l'auberge…
Posté par Misc (site web personnel) . En réponse au lien Le refus de communiquer le code de déverrouillage d’un téléphone portable peut constituer un délit. Évalué à 4.
Sauf erreur de ma art, c'est du bruteforce via des boitiers spécifiques qui vont simuler le fait d'être un clavier et qui vont relancé le tel au bon moment.
Du coup, ça devient surtout une question de timing (e.g., combien de temps avant que ça casse), et de coût vu qu'il faut le boitier, donc de la paperasse pour l'opérer, donc les flics doivent pas le faire systématiquement. Et que les dits boitiers sont pas gratuits.
C'est quand même assez souvent des questions de pognon.
[^] # Re: tz database
Posté par Misc (site web personnel) . En réponse au journal Passage Heure d'hiver : SFR a oublié ?. Évalué à 3.
1 mois, ça peut être tendu. Si il faut attendre que le fournisseur fasse le patch puis valide ça (voir attende un autre correctif pour faire 1 release), puis que tu fasses pareil via prod/prepod/etc la mise à jour, et que ça doit tomber dans une fenêtre spécifique pour un reboot, je peux voir comment ça peut coincer.
Par exemple, le département info chez nous avait une fenêtre ou on ne touche à rien sur certains serveurs, juste avant la fin du trimestre. Donc 3 semaines avant, et 15 jours après, il y a pas de reboot sur certains services sauf demande spécifique autorisé par plusieurs directeurs.
C'est facile de louper les questions de timezone surtout sur un pays qui n'est pas le tien.
Ensuite, dans un monde idéal, on devrait faire plus rapidement les mises à jours, mais parfois, ça arrive.
# Sinon, pour les logs
Posté par Misc (site web personnel) . En réponse au journal Douze facteurs dans ta tronche. Évalué à 6.
Il suffit de garder ça dans le journal, mais d'avoir rsyslog qui va aussi faire le tri et écrire dans un fichier à part vu que c'est ce qui est voulu (et à mon sens, c'est pas une préoccupation de l'appli, mais du déploiement, donc ça doit être en dehors de l'appli).
Ça me parait plus générique et flexible que d'avoir en effet des fichiers de logs spécifiques pour chaque application.
[^] # Re: FROM scratch
Posté par Misc (site web personnel) . En réponse au journal Comment sécurisez-vous les images docker externes ?. Évalué à 3. Dernière modification le 06 novembre 2022 à 12:31.
Donc tu parles d'un cas ou il n'y a pas un buffer overflow (ou autre détournement bas niveau), donc je ne peux pas avoir de l’exécution de code complète dans l'espace mémoire du programme, mais je peux avoir un exec/system arbitraire sur un programme qui existe déjà sur le disque ?
Par exemple, le programme passe des variables mal échappées venant de dehors.
Si c'est le cas, ça veut dire qu'il y a déjà un appel à exec/system. Et si tu as un exec/system dans le programme principal, tu as une dépendance vers un autre binaire, donc il faut la gérer.
Suivant le type de binaire, le raisonnement n'est pas le même. Si c'est 2 binaires statiques qui s'appellent, oui, tu peux en effet réussir à éviter d'avoir un gestionnaire de paquet dans le conteneur final. Mais je pense que c'est assez rare, et la question se pose de pourquoi ne pas mettre tout dans 1 seul binaire, ou dans 2 conteneurs séparés.
Si un des 2 programmes est fourni ailleurs ou n'est pas statique, par exemple via ta distro (exemple, tu lances imageMagick), alors tu va sans doute hériter d'un gestionnaire de paquet dans le conteneur pour installer le binaire et ses éventuels dépendances, et tu peux pas utiliser "FROM scratch" + "COPY from" facilement.
Mais du coup, si tu as dnf/apt/pip dans le conteneur et une faille qui permet d’exécuter un programme arbitraire mais qui doit exister, il suffit d'installer un paquet vérolé pour exécuter du code (en l'absence d'autre mesures de protection).
Par exemple, "pip install --user monpaquetpasverolé".
Et si tu utilises system (en tout cas en python), il y a des chances que ça tire aussi un shell pour son fonctionnement que tu ne peux pas retirer, ce qui donne plein de primitives funs (cat/echo, etc).
Il y a des outils qui permettent d'assembler des conteneurs sans avoir de gestionnaire de paquets à l'intérieur (e.g. apko, si je comprends bien), mais ça reviens à changer un peu tout le fonctionnement (et sans doute de distro).
Et n'oublions pas aussi que si tu as python/ruby/perl/node dans le conteneur pour lancer le programme ruby/perl/python/node, tu as aussi defacto de quoi lancer des onliners, donc je pense qu'un ménage visant à retirer les dépendances ne va pas aider pour la sécurité si tu as un interpréteur que tu peux pas retirer.
[^] # Re: ouin ouin
Posté par Misc (site web personnel) . En réponse au lien Stop Toxic Twitter. Évalué à 10.
Je suis assez surpris de ce commentaire lapidaire (et j'imagine le -1 qui vient avec).
Je suppose que le titre du lien ne plaît pas, mais j'ai comme habitude de reprendre le titre du site et de ne pas éditorialiser (sauf quand ça rentre pas), et soyons franc, c'est assez clair sur ce que le site veut transmettre, je ne pense pas que j'aurais fait mieux (sauf à traduire)
Ensuite, peut être que tu estimes que ça n'a pas sa place sur Linuxfr. Mais vu qu'il y a eu déjà 3 liens en rapport avec Twitter, je suppose que c'est pas le cas.
https://linuxfr.org/users/ysabeau/liens/4-fonctionnalites-de-twitter-que-mastodon-ferait-mieux-de-ne-pas-avoir
https://linuxfr.org/users/spacefox/liens/dirigeant-toxique-une-definition
https://linuxfr.org/users/spacefox/liens/le-milliardaire-elon-musk-a-pris-le-controle-de-twitter-et-licencie-des-dirigeants
Et je pense qu'une coalition de 60 associations, dont un bon paquet d'assez importante dans la lutte contre l’extrémisme et l’extrême droite US, c'est pas négligeable.
[^] # Re: FROM scratch
Posté par Misc (site web personnel) . En réponse au journal Comment sécurisez-vous les images docker externes ?. Évalué à 4.
Ah, je me suis arrêté à celui dans le docker-compose.
Le lien que tu donnes ne dit pas d’où ça vient (mais en même temps, dockerhub est pas terrible pour ça). L'avantage des registres de Gitlab et Github, c'est que tu as une idée rapide d'où vient le code.
[^] # Re: Sécu
Posté par Misc (site web personnel) . En réponse au journal Comment sécurisez-vous les images docker externes ?. Évalué à 3.
Un autre projet intéressant est https://github.com/chainguard-dev/apko
[^] # Re: FROM scratch
Posté par Misc (site web personnel) . En réponse au journal Comment sécurisez-vous les images docker externes ?. Évalué à 5.
Intéressant. J'aurais un peu peur de choses comme les chargements dynamiques (ctypes) et les os.exec en tout genre, mais je suppose qu'il suffit de tester.
En node, l'exemple que j'ai, c'est ethercalc, dont le conteneur pèse 1G. J'ai pas le sentiment que ça soit justifier pour un tableur web.
[^] # Re: FROM scratch
Posté par Misc (site web personnel) . En réponse au journal Comment sécurisez-vous les images docker externes ?. Évalué à 4.
Je vous en sais gré.
Supposons qu'un attaquant arrive à avoir la capacité d’exécuter du code dans le processus du conteneur (genre, un buffer overflow classique sans protection).
Il est vrai que le plus simple est de lancer un shell surtout si c'est ce qui traîne dans les exploits publiques, ou une commande.
Mais en pratique de nos jours, il y a des kits tout fait pour contourner ce genre de limitation (exemple metasploit ). Donc le bénéfice est la en théorie (genre, ça va coincer des débutants qui prennent un truc tout fait), mais en pratique, ça se contourne sans trop de moyens.
Si c'est simple de builder et de faire le ménage (exemple en go ou en rust), ouais, ça vaut le coup.
Par contre, je me prendrais pas forcément la tête pour nettoyer un truc en python ou en node au nom de la sécurité car l'effort risque d'être trop grand pour un bénéfice pas ouf (si on reste que sur la sécurité).
[^] # Re: FROM scratch
Posté par Misc (site web personnel) . En réponse au journal Comment sécurisez-vous les images docker externes ?. Évalué à 6.
J'ai des réserves. La surface d'attaque dépend de ce que tu exposes, et donc de l'application principal du conteneur (en supposant 1 conteneur == 1 process).
Avoir gcc et ImageMagick dans le conteneur ne va rien impacter si ton process ne les utilisent pas, car les attaquants ne vont pas pouvoir y toucher. On peut sans doute trouver des cas tordus, mais ça me semble être l'exception plus que la régle.
Ne pas activer des fonctionnalités que tu n'utilise pas va réduire la surface d'attaque mais ça n'est pas pareil. Et retirer les composants que tu n'utilise pas va réduire les alertes des scanners (qui sont un peu con quand même), mais ça ne réduit pas la surface d'attaque mais juste sa perception.
Ensuite, les autres raisons (réduire la bande passante et le stockage) sont largement suffisantes pour moi, il n'y a pas besoin de ressortir la sécurité à tout bout de champ car ça ne fait qu'obscurcir ce qui est important et ce qui l'est moins à ce niveau.
[^] # Re: 4 fonctions
Posté par Misc (site web personnel) . En réponse au lien 4 fonctionnalités de Twitter que Mastodon ferait mieux de ne pas avoir. Évalué à 6.
Toute la planète qui a un accès internet et de la familiarité avec la technologie.
Je veux bien que Twitter donne la parole à beaucoup de monde, mais ça reste une bulle restreint à une partie de la population (indépendamment de savoir si la bulle en question est statistiquement représentative sur plusieurs axes autres comme l'age, le sexe, etc).
[^] # Re: Et si FB ne l'a pas, il l'aura...
Posté par Misc (site web personnel) . En réponse au lien Facebook a-t-il votre numéro de téléphone ? Vérifiez et supprimez. Évalué à 8.
Mais donc si je donne mon numéro de téléphone à Meta, puis que j'en change, il se passe quoi pour la personne qui récupère le numéro aprés ?
Meta est en tort parce que j'ai pas dit que c'est plus le mien, ou on suppose que Meta doit vérifier tout les 3 mois que c'est encore valable pour ne pas être dans l'illégalité ?
Et je rappelle à toute fin utile qu'il y a aussi des cas ou il n'y a pas besoin du consentement dans le RGPD (les cas b à f du point 1 de l'article 6).
[^] # Re: 4 fonctions
Posté par Misc (site web personnel) . En réponse au lien 4 fonctionnalités de Twitter que Mastodon ferait mieux de ne pas avoir. Évalué à 7.
Alors, je suis assez curieux de savoir ce que tu appelles la même fange, parce je comprends bien que Twitter pose souci, mais comme j'ai pas de compte, je ne sais pas ce que ça recouvre exactement.
Par exemple, si je me trompe pas, une partie des disputes ou des interactions vigoureuses sont une question d'asymétrie dans l'interface. Si je voit un message d'un compte, je ne vois pas les 300 réponses que ce compte voit, et ma réponse va se rajouter alors que je me dit que je vais juste participer (c'est sans doute pour ça qu'on voit 5 fois la même blague dans certains threads, car le compte qui réponds ne voit pas les 4 autres).
Et de ce que je vois de Mastodon, c'est pareil. Je vois les toots de mon chef, mais pas le fil sauf si je vais voir spécifiquement le fil. Il y a donc pas de raisons autre que le manque de visibilité pour éviter ce souci. Et le manque de visibilité est lié en parti à la taille réduite d'un serveur moyen.
De même, la question de la visibilité est souvent imputé à l'Algorithme. Si ton message est populaire alors plus de gens vont le voir, et bad things happen. Mais le mécanisme est fondamentalement la aussi via la fédération. Si on te suit et qu'on interagit depuis un autre serveur, alors la discussion va être visible pour plus de gens, avec ce que ça implique comme risque de débordement.
La seule différence est que pour le moment, le réseau n'a pas passé la taille ou ça arrive assez souvent pour être un problème, mais est ce que ça ne va pas arriver avec le fait d'avoir plus de monde ?
[^] # Re: Ce que Mastodon devrait procurer au minimum
Posté par Misc (site web personnel) . En réponse au lien 4 fonctionnalités de Twitter que Mastodon ferait mieux de ne pas avoir. Évalué à 6. Dernière modification le 04 novembre 2022 à 18:56.
Bah, ton serveur est connecté aux autres, donc tes messages apparaissent pour les gens qui s'abonnent à ton flux, et tu n'as que les gens à qui tu t'es abonné.
Ou tu veux ne pas voir les messages des gens auquel tu n'es pas abonné, mais que les gens voient les tiens sans avoir besoin de le demander ?
# 4 fonctions
Posté par Misc (site web personnel) . En réponse au lien 4 fonctionnalités de Twitter que Mastodon ferait mieux de ne pas avoir. Évalué à 10.
Donc:
pas d'indicateurs, mais ça peut se faire du coté du client
pas de notifications (ça, je suppose que ça va pas être rajouté vu que ça doit être coté serveur)
pas de quote tweets. Je comprends l'argument, mais c'est aussi trompeur, car si ton but est d'afficher quelqu'un, suffit de le faire avec un screenshot. Donc j'aurais tendance à demander à voir.
pas de recherche intégral par défaut. Ce qui a mon sens n'est qu'une question de temps avant que quelqu'un indexe les serveurs.
Je suis dubitatif sur les 4 fonctions en questions, car Twitter n'a pas rajouté ça pour faire joli, et je doute que les besoins initiaux aient disparus, au moins pour le dernier. La capacité à fouillé le passé pour le harcèlement est aussi la capacité à fouiller pour voir ce qui se dit sur un sujet, et je pense que c'est un besoin qui peut être légitime pour se renseigner sur un sujet.
[^] # Re: Ce que Mastodon devrait procurer au minimum
Posté par Misc (site web personnel) . En réponse au lien 4 fonctionnalités de Twitter que Mastodon ferait mieux de ne pas avoir. Évalué à 4.
Une solution simple, c'est d'avoir son propre serveur, ça se fait facilement avec gotosocial.
[^] # Re: SELinux et co, faire mes propres images
Posté par Misc (site web personnel) . En réponse au journal Comment sécurisez-vous les images docker externes ?. Évalué à 4.
Sans doute, mais à quel niveau ?
Sur openshift, chaque conteneur tourne dans un contexte selinux séparé (en utilisant MCS ), et sur ma Fedora, les conteneurs tournent aussi via une politique SELInux qui bloque l’accès au fs (ce qui fait que je doit changer le label des fichiers pour donner accès). Il y a quelques articles sur https://github.com/containers/container-selinux
Donc si jamais un process arrive à contourner les limitations des namesapces suite à une faille, il reste encore les permissions SELinux pour éviter de faire trop de choses.
Et Openshift par défaut bloque le fait de lancer un conteneur en temps que root, en mappant root vers autre chose automatiquement via les userns.
Pour la défense de Docker, ça a pu changer depuis que l'article a été posté. Je ne connais pas assez Debian pour savoir.
Mais oui, c'est un peu le souci. Je trouve que l'approche de Fedora consistant a publier son propre registre intéressante, vu que tu sais que c'est fait par le projet vu que le domaine corresponds.
[^] # Re: Titre
Posté par Misc (site web personnel) . En réponse au journal Comment sécurisez-vous les images docker externes ?. Évalué à 7.
Vaguement, des choses comme
https://fedoramagazine.org/community-container-images-available-for-applications-development/
Le logiciel s'appelle osbs, et c'est du coté de Fedora cloud, mais je trouve pas trop de doc et/ou de discussion.
L'approche que tu proposes marcherais, mais j'ai peur que tu tombes assez vite dans des cas ou ça marche pas, vu que tu supposes:
que les logiciels sont installés via le gestionnaire de paquet natif (quid de pip install)
que la distribution est encore maintenu (eg, quid d'un conteneur basé sur une version EOL)
que la distribution lors de sa mise à jour ne va pas casser la compatibilité quelque part
que l'image a un gestionnaire de paquet dispo en premier lieu (il y a sans doute des images ultra minimalistes sans ça)
Ensuite, peut être qu'on parle de cas mineurs.
[^] # Re: Titre
Posté par Misc (site web personnel) . En réponse au journal Comment sécurisez-vous les images docker externes ?. Évalué à 10.
C'est sans doute mort. Les devs de logiciel se sont lancés sur docker en se disant "ça va éviter de faire le taf des distributions", mais c'est une connerie, ça évite pas les distributions du tout, ça obscurcit le tout.
Les conteneurs sont un outil et un format d'image pour distribuer des logiciels. Mais il n'y a pas de solution technique pour la question de la curation de contenu, et c'est ce qui coince ici.
Fedora a tenté de pousser ça, des conteneurs basés sur Fedora utilisant les paquets et avec des standards et une gestion des versions. Ça n'a pas trop décollé que je sache.
Et Dockerhub vise plus à avoir tout le monde pour des questions de croissances que de devoir faire un choix, donc tu as effectivement plein de trucs douteux.
# SELinux et co, faire mes propres images
Posté par Misc (site web personnel) . En réponse au journal Comment sécurisez-vous les images docker externes ?. Évalué à 8.
Alors pour ça, j'ai un certain nombre de choses, car la sécurité, c'est vaste (tm)
Primo, j'expose pas les conteneurs directement, mais j'ai un proxy devant. Ça permet d'éviter les soucis liés à de la crypto pas à jour (bien que je pense que ça soit rarement applicable en pratique), et ça m'assure des logs. Ça permet aussi d'éviter les soucis dans le gestion du protocole HTTP en utilisant une pile éprouvé (en l’occurrence, apache httpd ou HAProxy).
Ensuite, j'utilise SELinux. Au taf, c'est directement dans la plateforme (Openshift), chez moi, c'est directement dans l'OS, les conteneurs ne tournent pas en root autant que possible. Le but est d'éviter les sorties du conteneur trop facile en cas d'execution dans le conteneur.
Ensuite, je prends pas n'importe quel image, et je fait mes propres images ou mes propres déploiements.
J'essaye de partir d'images de distros en vérifiant que c'est bien officiel, avec l'orga derrière et pas juste un dev.
L'exemple de Debian est un bon cas, car je ne connais pas la situation maintenant, mais avant, c'était un peu bizzare.
J'essaye donc de faire mes images et d'automatiser la recompilation via une CI, en utilisant les paquets de la distro autant que possible.
L'exemple que j'ai, c'est un dépôt github qui recompile les images toutes les semaines et qui changent automatiquement la version de base de Fedora:
https://github.com/mscherer/various_containers/blob/main/.github/workflows/build_docker.yml
Donc je sais que si je déploie un site sur hugo ou zola, la CI qui recompile le site en prenant mon conteneur va utiliser la dernière stable du logiciel qui tourne sur la dernière Fedora automatiquement (ou avec grosso modo 1 semaine de délai). Il faut juste que je clique un bouton tout les 6 mois, ou que je fasse un commit pour pas que github coupe la CI (et j'imagine, à terme, que je nettoie le dépôt).
J'évite les images des projets qui utilise node ou python comme base parce que je ne sais pas ce qu'il y a dedans ou à quoi m'attendre. Parfois, je prends des images pour tester (par exemple, grist), ou pour des trucs que j'estime mineur et difficile à exploiter (par exemple, ethercalc), mais pour la production, je passe plus de temps à faire gaffe.
Et c'est pas tant la sécurité qui me chagrine (car ça reste assez rare) que les incompatibilités qui peuvent arriver (l'exemple que j'ai est sur un blog qui est en panne, mais c'était une histoire d'userspace Ubuntu qui ne marche pas sur une Fedora, et qui casse de façon subtil).
[^] # Re: Si on repart aux sources...
Posté par Misc (site web personnel) . En réponse au journal Les problèmes d’un desktop sans systemd ?. Évalué à 7.
Ou les bugs impossible à corriger sans réimplementer systemd.
Je n'ai plus le lien, mais il y avait une race condition (je crois) dans le script bind de Debian du au fonctionnement de named (qui utilise les signaux pour s'eteindre), race condition impossible à éviter sans l'usage des cgroups.
Mais on a largement commentés systemd y a 7 ans, il faut vraiment lire les archives.
[^] # Re: Je pose la question dans l'autre sens
Posté par Misc (site web personnel) . En réponse au journal Les problèmes d’un desktop sans systemd ?. Évalué à 4.
Visiblement oui, il n'y a pas eu beaucoup d'usage d'Ansible.
Ensuite, c'est mon point. L'adéquation d'un OS pour le serveur, c'est aussi lié à la qualité de son écosystème, et pour le logiciel libre, c'est directement lié au fait qu'assez de personnes l'utilisent pour ça.
Et ce que j'ai vu, c'est que des choses que j'avais supposé comme de base sur un système Linux (avoir un moyen d'installer un serveur automatiquement, avoir des images cloud officiels, avoir un support basique pour des outils populaires) ne le sont pas forcément.
Et pour en revenir au point de base, si ça n'était qu'une question de hardware, ça irait, parce qu'on peut s'en sortir avant des achats judicieux ou de l'occase. Ça coûte un peu d'argent si tu dois changer ton matos, mais on s'en sort.
Sortir 50€ pour une carte wifi qui marche, c'est chiant, mais ça va.
Par contre, quand c'est du logiciel, l'investissement pour faire marcher est différent, et plus coûteux.