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.
J'ai 7 process avec systemd comme prefixe sur mon portable dans ps fax.
J'ai 114 threads dans le kernel qui apparaissent dans ps fax
Il est intéressant de voir qu'on suppose que les devs du kernel savent ce qu'ils font, mais pas les devs des distros ou les devs systemd vu que 7, c'est trop, mais 114, ç'est pas du tout un signe de complexité croissante dans le kernel.
Par comparaison, la machine FreeBSD dans ma chambre a 27 threads kernel, et 33 sur le même hardware dans le salon sous OpenWRT.
Alors bien sur, d'un coté, c'est un portable, et de l'autre, 2 Rpi 1, donc il y a moins de hardware. Mais logiquement, si on veux réduire la complexité, c'est pas forcément au niveau de l'OS qu'il faut commencer.
En quoi est-ce la faute des BSD ? Ansible fait partie de
l'installation de base ? Non, donc là, c'est plutôt du côté
d'Ansible qu'il faut regarder.
Mon point n'est pas qu'il y a un bug (ça arrive), mais que la communauté autour des BSD me semble trop petite car sinon, les bugs auraient été trouvé plus tôt. Et de ce point découle le fait que l'affirmation "c'est mieux" ne me parait pas se vérifier dans les chiffres.
L'écosystème compte aussi un peu.
Pourquoi ? Les trois fonctionnent très bien ? Perso, il y a 15
ans environ, j'étais passé d'IPFilter à PF sans aucun souci et
sans rien installer de supplémentaire, juste une config noyau
parce qu'à l'époque, je construisais mes noyaux.
Mais le point n'est pas de savoir si ça marche ou pas. Le point est que si il y a 3 firewalls, c'est parce que le ménage n'a pas été fait. Il y a sans doute des bonnes raisons (compat, manque de ressources, etc), mais ça veut dire aussi que tout comme Linux, les noyaux de NetBSD et FreeBSD ont des vieux trucs qui traînent, et que ce n'est pas comme j'ai entendu plusieurs fois "sur FreeBSD, on pense d'abord et ensuite on ajoute quand c'est bon". Le fait d'avoir la même fonction 3 fois me laisse à croire que les 2 premières n'étaient pas assez bonnes, un point normal surtout pour des bénévoles mais omis dans le discours.
Et mon point n'est pas que les BSD sont mauvais, ou que ça soit un souci d'avoir 3 firewalls. Ça tourne correctement, la communauté fait avec ce qu'elle a comme ressources, et clairement, il y a moins de monde payé pour coder que sur les distros Linux, donc c'est assez impressionnant de réussir à maintenir l'OS.
Mais j'ai trop souvent l'impression qu'on invente des qualités la ou il n'y a rien.
C'est un peu ce que je retient de la présentation de 2017 que j'ai collé explique. C'est pas que les BSD sont mieux écrit que Linux qui fait qu'il y a moins de CVE. C'est qu'il y a moins de monde qui trouve car il y a moins de monde qui cherche.
Et hélas, c'est sans doute pareil pour les soucis autre que les failles de sécurités, ce qui me fait relativiser beaucoup les affirmations sur le fait que ça soit mieux.
Si c'était que le hardware, ça passerait encore. Mais même sur le serveur, les BSDs sont un peu à la ramasse.
Par exemple, j'ai du corriger quelques bugs pour Ansible sur NetBSD et FreeBSD (la détection du système de paquet, ce genre de chose) parce que je devais être le premier à m'en servir.
Automatiser l'installation d'un OpenBSD ou de NEtBSD m'a toujours donné l'impression d'être un bricolage (e.g., pas de preseed/kickstart à l'époque).
Et l'intégration, c'est un peu de la propagande, n'importe qui ayant utilisé de façon un peu poussé voit bien que ça ne corresponds pas vraiment à la réalité.
Par exemple, il y a 3 firewalls sur NetBSD (PF, NPF, IP Filter) et FreeBSD (PF, IPFW et IPFILTER). Ce n'est pas un souci, mais c'est pas ce que j'appelle de l'intégration.
Et de même, l'idée que "les BSDs sont mieux écrit", ça me parait être surtout le signe qu'il y a moins de monde, cf une présentation de 2017 toujours valable.
C'est assez triste, car je pense qu'il est important que des alternatives à Linux existent, mais pour avoir tenter l'aventure, c'est quand même aller contre le courant.
Mais il est vrai que je trouve que ce système d’initialisation
gère un peu trop de chose sans qu’on le sache. Dernier exemple
en date : (m)locate. J’ai découvert par hasard il y a peu que
le rafraîchissement de la base de données était gérée via un
timer systemd. (J’avoue que je m’étais jamais posé la
question).
C'était sans doute un cron avant, ou anacron (vu que le cron qui rafraichi à 3h du mat, quand tu éteint la machine, c'est pas terrible).
Mais du coup, je pige pas le souci, ta distro a choisi d'utiliser systemd pour lancer une tache périodique (sans doute parce qu'un timer permet aussi de limiter les I/O), mais comme tu le dis, tu ne t'es jamais posé la question, c'est peut être parce que ça n'a pas une grande importance ?
Surtout que vixie-cron, le programme que la plupart des distros utilisent, a été écrit en 1987, avec sa dernière release en 2004:
que des logiciels vont continuer à changer d’heure sur la base
d’une TZ Database obsolète…
Pas plus que ce qui arrive maintenant avec des dates de changements qui changent au dernier moment.
Par exemple, le gouvernement du Chili a annoncé le 9 août que le changement d'heure se fait le 11 septembre, et pas le 4 septembre.
Celui d'Égypte fait ça aussi, et je pense que le pays tient le record pour le moment, avec 3 jours de délai entre le changement prévu et le changement (ou plutôt, non changement) effectif.
[^] # 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.
[^] # Re: Une mode ?
Posté par Misc (site web personnel) . En réponse au journal Les problèmes d’un desktop sans systemd ?. Évalué à 8.
Je ne dirait pas qu'Alsa a suffit pendant un moment. On avait aRts et ESD il y a 20 à 25 ans parce que justement Alsa et OSS n'étaient pas suffisant.
[^] # Re: Il dit qu'il ne voit pas le rapport
Posté par Misc (site web personnel) . En réponse au journal Les problèmes d’un desktop sans systemd ?. Évalué à 10.
J'ai 7 process avec systemd comme prefixe sur mon portable dans ps fax.
J'ai 114 threads dans le kernel qui apparaissent dans ps fax
Il est intéressant de voir qu'on suppose que les devs du kernel savent ce qu'ils font, mais pas les devs des distros ou les devs systemd vu que 7, c'est trop, mais 114, ç'est pas du tout un signe de complexité croissante dans le kernel.
Par comparaison, la machine FreeBSD dans ma chambre a 27 threads kernel, et 33 sur le même hardware dans le salon sous OpenWRT.
Alors bien sur, d'un coté, c'est un portable, et de l'autre, 2 Rpi 1, donc il y a moins de hardware. Mais logiquement, si on veux réduire la complexité, c'est pas forcément au niveau de l'OS qu'il faut commencer.
[^] # 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é à 8.
Mon point n'est pas qu'il y a un bug (ça arrive), mais que la communauté autour des BSD me semble trop petite car sinon, les bugs auraient été trouvé plus tôt. Et de ce point découle le fait que l'affirmation "c'est mieux" ne me parait pas se vérifier dans les chiffres.
L'écosystème compte aussi un peu.
Mais le point n'est pas de savoir si ça marche ou pas. Le point est que si il y a 3 firewalls, c'est parce que le ménage n'a pas été fait. Il y a sans doute des bonnes raisons (compat, manque de ressources, etc), mais ça veut dire aussi que tout comme Linux, les noyaux de NetBSD et FreeBSD ont des vieux trucs qui traînent, et que ce n'est pas comme j'ai entendu plusieurs fois "sur FreeBSD, on pense d'abord et ensuite on ajoute quand c'est bon". Le fait d'avoir la même fonction 3 fois me laisse à croire que les 2 premières n'étaient pas assez bonnes, un point normal surtout pour des bénévoles mais omis dans le discours.
Et mon point n'est pas que les BSD sont mauvais, ou que ça soit un souci d'avoir 3 firewalls. Ça tourne correctement, la communauté fait avec ce qu'elle a comme ressources, et clairement, il y a moins de monde payé pour coder que sur les distros Linux, donc c'est assez impressionnant de réussir à maintenir l'OS.
Mais j'ai trop souvent l'impression qu'on invente des qualités la ou il n'y a rien.
C'est un peu ce que je retient de la présentation de 2017 que j'ai collé explique. C'est pas que les BSD sont mieux écrit que Linux qui fait qu'il y a moins de CVE. C'est qu'il y a moins de monde qui trouve car il y a moins de monde qui cherche.
Et hélas, c'est sans doute pareil pour les soucis autre que les failles de sécurités, ce qui me fait relativiser beaucoup les affirmations sur le fait que ça soit mieux.
[^] # 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é à 9.
Si c'était que le hardware, ça passerait encore. Mais même sur le serveur, les BSDs sont un peu à la ramasse.
Par exemple, j'ai du corriger quelques bugs pour Ansible sur NetBSD et FreeBSD (la détection du système de paquet, ce genre de chose) parce que je devais être le premier à m'en servir.
Automatiser l'installation d'un OpenBSD ou de NEtBSD m'a toujours donné l'impression d'être un bricolage (e.g., pas de preseed/kickstart à l'époque).
Et l'intégration, c'est un peu de la propagande, n'importe qui ayant utilisé de façon un peu poussé voit bien que ça ne corresponds pas vraiment à la réalité.
Par exemple, il y a 3 firewalls sur NetBSD (PF, NPF, IP Filter) et FreeBSD (PF, IPFW et IPFILTER). Ce n'est pas un souci, mais c'est pas ce que j'appelle de l'intégration.
Et de même, l'idée que "les BSDs sont mieux écrit", ça me parait être surtout le signe qu'il y a moins de monde, cf une présentation de 2017 toujours valable.
C'est assez triste, car je pense qu'il est important que des alternatives à Linux existent, mais pour avoir tenter l'aventure, c'est quand même aller contre le courant.
[^] # Re: Même réflexion ... parfois
Posté par Misc (site web personnel) . En réponse au journal Les problèmes d’un desktop sans systemd ?. Évalué à 10.
C'était sans doute un cron avant, ou anacron (vu que le cron qui rafraichi à 3h du mat, quand tu éteint la machine, c'est pas terrible).
Mais du coup, je pige pas le souci, ta distro a choisi d'utiliser systemd pour lancer une tache périodique (sans doute parce qu'un timer permet aussi de limiter les I/O), mais comme tu le dis, tu ne t'es jamais posé la question, c'est peut être parce que ça n'a pas une grande importance ?
Surtout que vixie-cron, le programme que la plupart des distros utilisent, a été écrit en 1987, avec sa dernière release en 2004:
https://github.com/vixie/cron/blob/master/Documentation/Changelog.md
Maintenant, il y a un dépôt de code publique, mais ça n'a pas été le cas pendant très longtemps.
[^] # Re: tz database
Posté par Misc (site web personnel) . En réponse au journal Passage Heure d'hiver : SFR a oublié ?. Évalué à 5.
Pas plus que ce qui arrive maintenant avec des dates de changements qui changent au dernier moment.
Par exemple, le gouvernement du Chili a annoncé le 9 août que le changement d'heure se fait le 11 septembre, et pas le 4 septembre.
Celui d'Égypte fait ça aussi, et je pense que le pays tient le record pour le moment, avec 3 jours de délai entre le changement prévu et le changement (ou plutôt, non changement) effectif.