Logo journal du hacker middle
  1. 21
  1.  

  2. 3

    Merci pour le partage, c’est très intéressant !

    Voila ce qui arrive quand on développe sur une machine sensible. Je te conseille de créer une machine virtuelle développement et de développer dessus. C’est chiant mais cela évite ce genre de déboire.

    Une bonne leçon :)

    1. 2

      Je te conseille de créer une machine virtuelle développement et de développer dessus.

      Sur FreeBSD les environnements jail sont bien adaptés pour ces séparations. Ils n’utilisent que peu de ressources (comme des containers) mais ils sont conçus avec la sécurité à l’esprit.

      1. 1

        Une VM par projet c’est un peu lourd, des conteneurs c’est un peu plus réaliste.

        1. 2

          @mirabellette @nikaro quand j’ai commencé à développer, on ne parlait pas de « conteneurs » et c’était les débuts de qemu … rien à voir avec l’actuel kvm. :) Donc j’ai commencé en bordel (et en auto-didacte ; ce qui n’est pas sans lien). Et j’ai eu le tord de ne jamais revoir cette organisation pro/perso/assos.

          C’est mésaventure me donne l’occasion de reposer les choses à plat avec un nouveau modèle de menaces que j’avais ignoré jusque lors. Je précisera ces choix d’organisation dans un futur billet une fois que tout ceci se sera un peu tassé.

          1. 2

            Ne jamais mélanger les environnements ;)

            A titre d’exemple, j’ai une machine pro et une machine perso et quand je fais du perso sur la vm du pro, ce que je limite au maximum, je le fais sur des choses safe avec un vpn avec une machine dédiée au vpn.

            1. 2

              Cette approche limite le risque qu’une problème côté pro atteigne des éléments perso, et inversement. Mais si tu as un projet pro corrompu, tous les autres le sont potentiellement. C’est là où je préfère l’approche “conteneurs”, en plus de pouvoir permettre une gestion plus fine des outils et de leurs versions.

              Perso je fonctionne avec le principe de “devcontainer”[1], inspiré de ce qui se fait dans VSCode[2].


              [1] https://git.sr.ht/~nka/devc

              [2] https://code.visualstudio.com/docs/remote/remote-overview

              1. 1

                C’est en partie un positionnement juste, mais en partie le témoin d’une situation hautement problématique je pense.

                Pour faire une analogie, qui aurait l’idée de dire qu’il faut systématiquement conteneuriser Debian au motif qu’il n’en n’a pas audité le code ? Et sur quoi ? Parce que rapidement il va y avoir un pb de récursivité. (hurd?)

      2. 2

        Je ne suis pas un immense fan de Docker de manière générale, mais c’est ce genre de problèmes qui pourraient m’encourager à l’utiliser lorsque je développe des logiciels. Après faut fait gaffe de ce côté là aussi, on pourrait certainement se retrouver également avec des images vérolées…

        1. 2

          Clairement. Et plein de gens faisant du docker en root, c’est juste pire et plus délicat à détecter. :)

        2. 2

          S’il y a eu un accès distant, les frappes du clavier ou la visualisation de l’écran ont peut-être été enregistrées. Donc le mot de passe du trousseau de clés Firefox a pu être compromis, ainsi que le chiffrement GPG (clé privée récupérée et phrase de passe aussi). Il vaut mieux révoquer et changer tout cela. Il vaut mieux aussi repartir d’un nouveau système d’exploitation installé à neuf.

          1. 1

            Tout à fait. Je l’ai honnêtement zappé lors de la rédaction et je me demande si ce n’est pas une réaction d’autodéfense de mon cerveau. À dire vrai, j’ai rédigé cet article et l’ai à peine relu (il est truffé de coquilles) : ça m’a permit de canaliser la tempête dans mon cerveau et de réfléchir façon canard en plastique, au lieu de m’agiter ou désespérer.

          2. 1

            Donc on ne peut pas faire confiance à PyPi sur lequel n’importe qui peut mettre n’importe quoi. Qu’on se le tienne pour dit, à une époque où on trouve beaucoup de tutos nous recommandant de faire pip ci, pip ça sans vérifier l’origine des paquets en question.

            1. 1

              Tu peux faire confiance aux paquets que tu connais, il n’y a pas beaucoup plus de risque à faire pip install requests que apt install python-requests. Par contre installer des paquets inconnus… c’est une toute autre histoire.

              1. 1

                J’ai pris le temps d’ouvrir un thread ici si ça vous intéresse : https://discuss.python.org/t/improving-risks-and-consequences-against-pytosquatting-on-pypi/5090

                1. 1

                  il n’y a pas beaucoup plus de risque à faire pip install

                  En tout cas apt install python-request au 31 juillet 2020 n’aurait produit pas le même résultat.