Journal Lancer un programme sans accès au réseau, merci les espaces de noms réseaux

Posté par . Licence CC by-sa.
Tags :
32
4
mar.
2019

Bonjour nal,

Ça faisait des années que j'aurais aimé faire ça sans vraiment chercher : parfois on lance un programme auquel on ne fait pas trop confiance, et particulièrement on aimerait qu'il n'aille rien cracher sur le net dès qu'on le lance.

Et je suis tombé sur une solution vitefé :

$ ip netns add no_net
$ ip netns exec no_net /bin/sh
sh# su -l <user> # histoire de pas lancer le truc en root

# pour info
$ ip netns exec no_net ip a
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
$ ip netns exec no_net ping 127.0.0.1
connect: Le réseau n'est pas accessible

J'ai pas encore eu le temps de fouiller plus que ça, mais j'imagine qu'on peut faire pleins de trucs sympa avec ces netns.

hors sujet mais comment ça, le correcteur orthographique ne reconnait pas «nal» !?

  • # Deux autres pistes

    Posté par . Évalué à 10 (+11/-0).

    Tu peux essayer les deux commandes suivantes : unshare et firejail.

    Par exemple, je les utilises pour lire des courriels html depuis mutt en évitant les requêtes sur le net:
    - unshare -r -n w3m
    - firejail --noprofile --net=none firefox

    Il y a plein d'autres options comme par exemple présenter un système de fichier minimal, ne monter qu'une liste définie de répertoires dans ton home, changer les serveurs DNS ou les protocoles réseaux autorisés…

    • [^] # Re: Deux autres pistes

      Posté par . Évalué à 9 (+7/-0).

      L'intérêt des namespaces c'est qu'il n'y a pas d'hypothèse de base, c'est juste linux et la commande ip devrait être dispo dans la majorité des installations minimales car c'est elle qui déprécie ifconfig si je ne m'abuse.

  • # Flatpak

    Posté par . Évalué à -1 (+3/-5).

    Sinon Flatpak est conçu pour ça

    • [^] # Re: Flatpak

      Posté par (page perso) . Évalué à 2 (+1/-0).

      Dans Flatpak, on peut déclarer les permissions de son application dans le manifeste.

      Après, je ne connaissais pas mais apparemment il y a moyen en CLI de faire flatpak permission-remove. Après, comment ça s'utilise en pratique ? (chaque portail a sa table ok mais un exemple pratique sans avoir à creuser la terminologie serait bienvenu dans la doc :D).

  • # Sinon il y a systemd

    Posté par (page perso) . Évalué à 10 (+9/-0).

    On peut aussi utiliser systemd pour isolé un service/une commande :

    http://0pointer.net/blog/ip-accounting-and-access-lists-with-systemd.html

    • [^] # Re: Sinon il y a systemd

      Posté par (page perso) . Évalué à 1 (+0/-0). Dernière modification le 05/03/19 à 10:50.

      Anecdote amusante à ce sujet : sur mon serveur auto-hébergé, je suis probablement un des rares individus de la planète à faire tourner son serveur web (nginx) sans accès au réseau !

      Depuis qu’une backdoor a failli s’installer sur mon serveur il y a quelques années via une faille d’Exim dans Debian (je n’y ai échappé que parce que j’avais monté ma partition noexec), je suis devenu un peu parano au niveau sécurité… Mais il y a encore pire que moi :-D

      • [^] # Re: Sinon il y a systemd

        Posté par . Évalué à 4 (+2/-0).

        faire tourner son serveur web (nginx) sans accès au réseau !

        Mmmhhh… tu peux expliquer ton utilisation ? Parce que là, je ne vois pas l'utilité…

        • [^] # Re: Sinon il y a systemd

          Posté par (page perso) . Évalué à 5 (+4/-0).

          Nginx a 3 sections de configuration :

          • une pour le contenu HTTP, en écoute sur (je simplifie) /run/http ;
          • une pour le contenu HTTPS, en écoute sur /run/https ;
          • une pour le contenu HTTPS accédé depuis une IP de confiance ou une IP ayant port-knocké le bon « mot de passe », en écoute sur /run/https+.

          Sur la DMZ, nftables gère le port-knocking et redirige sur un port interne spécifique en cas de port-knock réussi ; j’ai donc 3 ports HTTP(S), sur lesquels haproxy est en écoute.

          Outre la gestion de quelques subtilités (type tunnel), haproxy se contente en gros de rediriger le traffic HTTP sur /run/http, le traffic HTTPS sur /run/https, etc. (je ne détaille pas les divers paramétrages systemd)

          Ainsi :

          • haproxy a accès au réseau mais à aucun contenu,
          • nginx a accès au contenu (non-sensible) mais pas au réseau,
          • pour le contenu sensible, nginx doit faire appel a un service back-end hors DMZ, par exemple Nextcloud qui tourne sur un uwsgi.
          • [^] # Re: Sinon il y a systemd

            Posté par . Évalué à 6 (+4/-0).

            haproxy a accès au réseau mais à aucun contenu,

            J'ai peut-être mal compris, mais dans l'absolu ton haproxy est sur la même machine dans le même namespace fichier que nginx, non ? Tu as mis des droits spécifiques ? Parce que sinon, si ton but est d'isoler de failles dans le logiciel, ils ont le même accès au contenu…

            nginx a accès au contenu (non-sensible) mais pas au réseau,

            Heu… il reçoit les même trames que s'il était en direct donc même exposition de code, et si ton but c'est de te protéger de ce qu'il pourrait faire sur le réseau s'il été troué, y as-tu mis un namespace réseau séparé comme l'indique le journal ?

            pour le contenu sensible, nginx doit faire appel a un service back-end hors DMZ, par exemple Nextcloud qui tourne sur un uwsgi.

            Hors DMZ, mais accessible depuis celle-ci, non ?

            Bref, je ne suis pas sûr que toutes tes complications aient un quelconque effet sur la menace « problème de sécu d'un de mes logiciels ». Encore une fois, je pense que l'important est de bien savoir de quoi on se protège :-)

            Note que je ne suis pas un aficionado du « tout blindé » : je cherche à montrer qu'au contraire, se compliquer la vie comme ça ne change au fond pas forcément beaucoup les choses (après, oui, je sais qu'une couche de bête sécurité par l'obscurité est souvent un moyen malheureusement efficace pour 80% des cas).

            • [^] # Re: Sinon il y a systemd

              Posté par (page perso) . Évalué à 3 (+2/-0).

              Tout d’abord, je te remercie pour ton commentaire nuancé et constructif :-)

              Je voulais juste donner une anecdote amusante sur l’absence de réseau (avec un lien pour les plus curieux), et non m’étendre sur les détails, qui sont un peu hors-sujet, mais bon… je vais essayer de donner quelques précisions… Il faut par contre garder à l’esprit que c’est un projet en cours (non achevé).

              De base, dans ma DMZ, à quelques exceptions près, l’accès sortant à Internet est bloqué. Et ce, par un paramétrage nftables qu’aucun service systemd n’a le droit d’altérer.

              — Du côté de HAProxy, en cible, il y aura une isolation de namespace filesystem (comme un chroot) donc aucun accès à du contenu. À ce jour, il n’y a que de la protection par l’obscurité : HAProxy ne « sait » tout simplement pas où sont les rares données accessibles en DMZ (mais ça n’est pas si difficile à deviner). Comme tu l’as souligné, ça apporte un certain degré de sécurité mais ce n’est pas idéal…

              => En cas de faille permettant de faire exécuter par HAProxy un binaire quelconque, ce dernier n’aura sur le principe rien à communiquer avec l’extérieur, et s’il pourra peut-être recevoir des requêtes, il ne pourra en revanche pas en émettre.

              — Du côté de Nginx, seules les sockets-Unix exposées servent à communiquer avec l’extérieur : recevoir des requêtes et y répondre. C’est le résultat d’un effort en cours pour retirer tous les accès réseau à Nginx ; à ce stade, je devrais pouvoir prochainement mettre en place une véritable isolation par namespace réseau, ce qui est ma cible.

              => En cas de faille permettant de faire exécuter par Nginx un binaire quelconque, ce dernier ne pourra pas utiliser le réseau, et n’aura de toute façon que peu de données accessibles.

              — Php-fpm m’ennuie davantage… l’accès au réseau est restreint de manière similaire, mais il est plus délicat de mettre en place des restrictions sans aller jusqu’à ségréguer les applications PHP…

              Hors DMZ, mais accessible depuis celle-ci, non ?

              Oui, dans la « SafeZone » (hors-DMZ), on a accès aux données sensibles. Le point important est surtout que les logiciels qui y sont, et sont donc plus sensibles, ne sont pas directement exposés sur Internet : Nginx (en DMZ) agit en proxy et limite les possibilités de créer des paquets sur-mesure pour déclencher des bugs. Ça n’est pas entièrement sûr, mais ça l’est davantage qu’un accès direct ou par simple redirection de port.

              Bref, tu as l’air de déjà le savoir : la sécurité n’est pas un interrupteur qu’on active ; c’est un millefeuille où chaque couche participe… et est insuffisante. Le choix du « nombre de feuilles » au millefeuille est un équilibre à trouver entre le risque, le coût de mise en œuvre et le coût d’une faille.
              Comme je fais ce projet dans un but d’apprentissage en plus de son utilité immédiate, pour ma part, tant que ça reste 100% automatisé (ansible), ça me va ;-)

              • [^] # Re: Sinon il y a systemd

                Posté par . Évalué à 2 (+0/-0).

                Merci pour les détails, tu sembles effectivement avoir déjà pris en compte les faiblesses que je pointais.

                Cependant, ça m'a l'air d'être une conf très complexe et qui doit nécessiter un temps de maintenance assez gros. Perso, pour le gain (éviter de potentielles failles dans des logiciels dans lesquels normalement j'ai à peu près confiance, bien mis à jour), je trouve que ça ne vaut pas le coup.

                • [^] # Re: Sinon il y a systemd

                  Posté par (page perso) . Évalué à 2 (+1/-0).

                  « Chacun voit midi à sa porte », comme on dit (heure d’hiver ou d’été, je laisse chacun décider :-p )

                  Pour ma part, sachant qu’une faille logicielle a déjà failli m’atteindre, sur un logiciel en lequel j’avais pleinement confiance (exim), sur une distribution en laquelle j’avais pleinement confiance (Debian stable + màj. securité), et sachant que derrière il y a toute ma vie en scan (revenus, impôts, etc.), en mails, etc., je mets du coup la barre assez haut.

                  • [^] # Sécurité

                    Posté par . Évalué à 2 (+0/-0).

                    Peut-être places-tu mal ta confiance.

                    Exim, c’est un serveur mail monolithique. De ce fait, on sait depuis longtemps qu’il n’est pas vraiment plus sûr que Sendmail 8 (même s’il a l’avantage sur lui d’être humainement configurable), qui a défrayé la chronique dans les années 1990 en alignant les failles majeures.

                    Qmail et Postfix ont été créés (en 1995 et 1998) avec une structure de mini-serveurs séparés pour séparer les privilèges et assurer la sécurité du système. Je conseille Postfix.

                    Avec la faille spécifique sur OpenSSL et la vulnérabilité récemment découverte sur APT, Debian n’est clairement pas la distribution qui a le meilleur historique au niveau sécurité (et on ne peut pas vraiment espérer mieux de ses dérivées ; elles ont peut-être échappé la la faille sur OpenSSL, mais pas à celle d’APT).

                    Pour la sécurité, je privilégierais Fedora ou CentOS pour SELinux activé par défaut (vu la complexité de sa configuration), et Postfix comme serveur mail. Quoique systemd soit aussi une source de failles. Mais éviter systemd voudrait dire utiliser Devuan, une dérivée de Debian, ou Void Linux, une distribution avec peu de mainteneurs. À moins de passer à OpenBSD.

                    ¯ : macron (typographie), petit signe diacritique, qui prétend ne pencher ni à gauche ni à droite, mais se place nettement au dessus des vraies lettres, qu’il considère avec mépris.

                    • [^] # Re: Sécurité

                      Posté par (page perso) . Évalué à 3 (+0/-0). Dernière modification le 09/03/19 à 16:08.

                      Les chiffres le montrent, il vaut mieux utiliser les dérivées ça réduit les failles (ou pas).

                      Debian
                       There are 9781 CVE entries that match your search. 
                      Red Hat
                       There are 10358 CVE entries that match your search. 
                      Ubuntu
                       There are 6529 CVE entries that match your search. 
                      CentOS
                       There are 18 CVE entries that match your search. 
                      

                      (source https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=%s )

                      Ensuite chaque admin sys a toujours ses préférences sur la distribution de son cœur (souvent celle qu'il connaît depuis longtemps), mais souvent peu d'arguments pour une distribution de son cerveau (percée significative quelconque et inégalée par telle ou telle distribution ?). Il a aussi tendance à dire « X est nul parce que » plutôt que « Y est bien parce que », ou « y a des trous dans X » (alors qu'il y en a aussi dans Y). Perso je kiffe les Debian (mais je dois aussi gérer des Ubuntu et des CentOS), mais Qubes OS ou Tails (ou CLIP-OS soyons fous) semblent attrayantes par exemple (mais probablement pas pour le même usage au final).

                      • [^] # Re: Sécurité

                        Posté par . Évalué à 2 (+0/-0). Dernière modification le 09/03/19 à 18:40.

                        Les chiffres le montrent, il vaut mieux utiliser les dérivées ça réduit les failles (ou pas).

                        La différence entre Red Hat et CentOS montre bien qu’on ne peut pas se fier aux chiffres. Qui plus est, ceux-ci ne permettent pas de comparer l’importance des failles qu’ils concernent.

                        Les distributions ont pas mal de failles qui viennent de l’amont (et même du matériel !). Après, elles ont un certain nombre de failles propres, généralement petites.
                        Cela dit, te souviens-tu sur les autres distributions (que Debian et dérivées), dans les quelques années passées, d’aussi grosses failles spécifiques que celles que j’ai citées ?

                        Ensuite chaque admin sys a toujours ses préférences sur la distribution de son cœur (souvent celle qu'il connaît depuis longtemps)

                        Je n’aime pas trop Debian, mais pas plus ce qu’est devenu Fedora. Et mon choix actuel ne se porte sur aucune des deux. Mais il ne fait pas passer la sécurité devant les autres critères, alors que là, je n’envisage que cette question.

                        Il a aussi tendance à dire « X est nul parce que » plutôt que « Y est bien parce que », ou « y a des trous dans X » (alors qu'il y en a aussi dans Y).

                        SELinux déjà configuré ne te semble pas un argument ? Après, peut-être que d’autres distributions en fournissent déjà une configuration fonctionnelle, je ne sais pas. Si tu en sais plus que moi sur SELinux sous Debian, n’hésite pas à nous éclairer.
                        Avec Fedora, Red Hat et CentOS, on en est sûr que SELinux est fonctionnel, parce qu’il est activé par défaut.

                        Après, mon avis personnel, c’est qu’il aurait dû être possible de faire SELinux sans une syntaxe aussi absconse et une manipulation aussi lourde. De ce fait, je ne l’utilise pas. Si je voulais l’utiliser, je me poserais la question d’essayer de le faire fonctionner sur ma distribution, ou de repasser sur Fedora ou CentOS pour au moins partir d’une configuration de base parfaitement fonctionnelle, afin de m’ennuyer le moins possible à régler ce truc.

                        Pour le reste, concernant Fedora et Red Hat, si elles s’accrochent encore à Sendmail 8, la première chose à faire est bien sûr de le remplacer par Postfix (curieusement, la dernière CentOS que j’ai essayée le choisissait par défaut, contrairement à la Fedora de l’époque).

                        Une autre considération intéressante concernant la sécurité, c’est la rapidité de prise en charge des failles amont.

                        La prise en charge de Spectre/Meltdown a été assez révélatrice à ce niveau. openSUSE (que je n’utilise pas non plus) s’est montrée particulièrement réactive à ce niveau, alors qu’Ubuntu a été plutôt à la traîne, étant quasiment la seule distribution majeure à ma connaissance à ne sortir un correctif qu’à la date de divulgation initialement prévue de ces failles. Red Hat a un peu fait bande à part, en étant prévenue plus vite, et en fournissant des correctifs d’Intel que ni les autres distributions ni le noyau officiel n’ont finalement retenus, semble-t-il pour des questions de performance.

                        Ubuntu a aussi privilégié la stabilité sur la sécurité en revenant sur les correctifs de firmware au moment où l’on s’est aperçu que ceux d’Intel posaient des problèmes de stabilité sur certains de leurs processeurs, et en attendant d’avoir du recul avant de remettre leur version ultérieure. D’autres distributions ne sont pas revenues en arrière (Arch Linux), ou ont remis la version ultérieure des correctifs quasiment immédiatement sans attendre d’avoir du recul dessus. C’est un choix.

                        Je n’ai pas fait le choix de la sécurité comme priorité absolue (d’ailleurs, j’utilise Xubuntu sur une de mes machines…), mais si je le faisais, je n’utiliserais ni Debian, ni une de ses dérivées.

                        ¯ : macron (typographie), petit signe diacritique, qui prétend ne pencher ni à gauche ni à droite, mais se place nettement au dessus des vraies lettres, qu’il considère avec mépris.

                        • [^] # Re: Sécurité

                          Posté par (page perso) . Évalué à 3 (+0/-0). Dernière modification le 09/03/19 à 19:10.

                          Remarque: j'étais évidemment ironique avec les chiffres sur les CVE (d'ailleurs la doc dit explicitement de ne pas le faire. The CVE search was designed to help identify specific vulnerabilities and exposures, and not to find sets of problems that share common attributes such as operating systems. Therefore, you should not search CVE by operating system because your results will be incomplete.)

                          Si tu en sais plus que moi sur SELinux sous Debian, n’hésite pas à nous éclairer.

                          https://wiki.debian.org/SELinux

                          The Debian packaged Linux kernels have SELinux support compiled in, but disabled by default. To enable it, see the Setup Notes.

                          Il y a encore trop de logiciels demander de désactiver SELinux en première étape ou sans support (comme le code LinuxFr.org par exemple) pour que ça soit généralisable partout. Les autres distributions auraient-elles peur delaisser un tel avantage à RedHat/IBM en se créant une dépendance sur SELinux ? (y a déjà Systemd déjà…)

                          Côté sécurité, je citerais aussi les efforts https://reproducible-builds.org/who/ (et y a pas CentOS/RedHat dedans).
                          La responsabilité des grosses failles peut aussi être compliquée (pas trop dans les cas précités pour Debian) : faut-il attribuer les failles Systemd à Red Hat? Ou celles de sudo ou openssh à OpenBSD ?

                          • [^] # Re: Sécurité

                            Posté par (page perso) . Évalué à 3 (+0/-0).

                          • [^] # Re: Sécurité

                            Posté par . Évalué à 2 (+0/-0).

                            Il y a encore trop de logiciels demander de désactiver SELinux en première étape ou sans support (comme le code LinuxFr.org par exemple) pour que ça soit généralisable partout.

                            Je sais. Je l’ai moi-même désactivé sur des CentOS ou Fedora…
                            Il faudrait avoir le temps et la motivation de faire soi-même la configuration pour les logiciels non pris en charge.
                            D’un autre côté, sur une machine cliente de base, il y a probablement moins de difficultés que sur un serveur avec des services maison. Et puis j’ai cru comprendre que la couverture s’est améliorée avec le temps. Au pire, si je me rappelle bien, il y a le mode targeted, qui n’est pas restrictif avec les logiciels non pris en charge.

                            La responsabilité des grosses failles peut aussi être compliquée (pas trop dans les cas précités pour Debian) : faut-il attribuer les failles Systemd à Red Hat? Ou celles de sudo ou openssh à OpenBSD ?

                            La question de la responsabilité est secondaire : à partir du moment où les principales distributions ont systemd, sudo et OpenSSH (remarque : j’ai une Arch Linux sans sudo…), aucune n’a d’avantage sur les autres à ce niveau.
                            C’est sur les différences qu’il faut choisir. Une bibliothèque de remplacement plus robuste qu’OpenSSL, par exemple, peut être un critère.

                            Au delà de Linux, il y a peut-être un avantage pour OpenBSD : pas de systemd, forcément le premier système à avoir les correctifs d’OpenSSH, le temps qu’ils consacrent à auditer leur code, mais à l’inverse un inconvénient par rapport aux distributions commerciales : ils ne sont pas prévenus à l’avance en cas de faille matérielle comme Spectre.

                            De toute façon, quelle que soit la distribution, on a toujours intérêt à choisir les services qui sont plus sûrs de par leur architecture : Postfix plutôt qu’Exim ou Sendmail, Dovecot plutôt qu’un autre serveur IMAP, Unbound plutôt que Bind si on n’a besoin que d’un résolveur récursif… Si l’architecture des services accessibles à distance ne laisse quasiment aucune chance d’obtenir quoique ce soit, on peut être plus serein pour le reste. Bon, si on a besoin de services web, ce sera plus difficile…

                            ¯ : macron (typographie), petit signe diacritique, qui prétend ne pencher ni à gauche ni à droite, mais se place nettement au dessus des vraies lettres, qu’il considère avec mépris.

                            • [^] # Re: Sécurité

                              Posté par . Évalué à 2 (+0/-0).

                              Tu mélange des choix plutôt incongrus avec des trucs plus intéressants… Ce qui est important pour la sécurité d'une distribution c'est son processus de qualité. Ont-t'ils des gens qui ne sont là que pour la sécurité ? Que font-t'ils ? Quel est le temps de propagation des fix upstream ? Y a t'il des audits réguliers ? C'est des sujets bien plus objectifs que de choisir au doigts mouillé si une faille plus ou moins médiatisée. L’absence de faille est un leurre. Si un logiciel n'a jamais eu de faille, comment savoir ce qu'il va se passer quand il y en aura une ? Est-ce que la fierté des mainteneurs ne les empêchera pas de l'annoncer ? Est-ce qu'il y a un bug bounty sur le logiciel ou la distribution ?

                              Les processus humains sont objectivement comparables et c'est bien.

                              Une bibliothèque de remplacement plus robuste qu’OpenSSL, par exemple, peut être un critère.

                              Pourquoi pour OpenSSL et pas OpenSSH, le shell par défaut ou je ne sais quoi d'autres. Tu montre des arguments très emprunt du marketing classique (systemd, openssl,…). C'est dangereux de faire des choix qu'on espère fiables sur des bases aussi fragiles. Pour OpenSSL la façon de l'utiliser peut avoir un impact. Par exemple OpenBSD n'a pas attendu la fameuse faille pour ne pas laisser OpenSSL décoder les certificats ASN1 si je ne m'abuse. Pour être un peu plus fiable avec ton approche par logiciel au doigt mouillé il faudrait lister tous les paquets installé et regarder les différences ce qui n'est pas vraiment tenable

                              • [^] # Re: Sécurité

                                Posté par (page perso) . Évalué à 4 (+1/-0).

                                Sur l'équipe sécurité Debian, présentation à Pass The Salt 2018: https://2018.pass-the-salt.org/files/talks/01-debian-security-team.pdf

                                Il faut aussi garder en tête que toutes les distributions ne corrigent pas toutes les CVE sur toutes les versions (faute de temps notamment), par exemple les infos Debian/Ubuntu (uniquement parce que je sais les retrouver plus vite que sur les RedHat/CentOS, et j'ai pris openssh au hasard, j'avais fait précédemment l'expérience avec httpd/apache2) :

                                • Debian https://security-tracker.debian.org/tracker/source-package/openssh

                                  • 8 jessie oldstable 1:6.7p1-5+deb8u7 (5 CVE non patchées dont deux mineures) // fin support LTS en juin 2020
                                  • 9 stretch stable 1:7.4p1-10+deb9u6 (1 CVE non patchée mineure) // fin du support normal en juin 2022
                                  • 10 buster testing 1:7.9p1-9 (1 CVE non patchée mineure) // fin du support normal en juin 2024
                                  • sid unstable 1:7.9p1-9 (1 CVE non patchée mineure)
                                • Ubuntu https://people.canonical.com/~ubuntu-security/cve/pkg/openssh.html

                                  • 12.04 Precise/e 9 CVE non patchées dont 7 mineures) // fin du support en avril 2017
                                  • 14.04 Trusty 6.6p1-2ubuntu2.13 (0 CVE non patché) // fin du support en avril 2019
                                  • 16.04 Xenial 1:7.2p2-4ubuntu2.8 (0 CVE non patché) // fin du support en avril 2021
                                  • 18.04 Bionic 1:7.6p1-4ubuntu0.3 (0 CVE non patché) // fin du support en avril 2028
                                  • 18.10 Cosmic 1:7.7p1-4ubuntu0.3 (0 CVE non patché) // non LTS, fin du support en avril 2019
                                  • 19.04 Disco 1:7.9p1-9 (1 CVE en cours de traitement) // non LTS, fin du support en octobre 2019
  • # J'ai plus simple !

    Posté par . Évalué à 6 (+4/-0).

    ou sinon on peut débrancher le réseau :)

    Ou encore mieux, débrancher la machine et faire une ballade.

    Blague à part, si on a pas confiance dans une appli au niveau de sa discrétion, je n'aurai pas confiance du tout, et une escalade de privilège peut se faire sans accès réseau et donc sortir quand même.
    J'ajouterai qu'aujourd'hui si l'appli est sous X, elle va pouvoir écouter les évènements notamment les mouvements de souris ou les frappes de touche…

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: J'ai plus simple !

      Posté par . Évalué à 3 (+1/-0).

      Même une machine isolé n'est pas a l’abri d'une fuite … par sa DEL du disque dur.
      https://www.sciencesetavenir.fr/high-tech/drones/un-ordinateur-pirate-par-la-led-du-disque-dur_111014

      • [^] # Re: J'ai plus simple !

        Posté par . Évalué à 3 (+1/-0).

        Oui en théorie on peut même espionner une machine en monitorant sa température et il suffit pour le pirate de faire plus ou moins travailler le proc, on peut aussi le faire sur la conso énergétique ou via les hauts parleurs.

        En pratique c'est déjà plus compliqué que choper une recette d'élévation de privilège et l'intégrer à un programme.

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: J'ai plus simple !

          Posté par (page perso) . Évalué à 2 (+1/-0).

          En pratique c'est déjà plus compliqué que choper une recette d'élévation de privilège et l'intégrer à un programme.

          Qui est aussi plus compliqué que juste ouvrir une socket et balancer des données dessus. Trouver une faille exploitable sur un système à jour n'est pas si facile que ça. Avec sa solution, il se protège d'un large spectre de vol de données. Il peut en plus, selon les cas, combiner ça à un chroot, un utilisateur dédié, etc …

          • [^] # Re: J'ai plus simple !

            Posté par . Évalué à 3 (+1/-0).

            Trouver une faille exploitable sur un système à jour n'est pas si facile que ça.

            Pas tant que ça, la principale étant l'écoute des évènements, laisser un processus résident s'appelant bash, écoutant clavier/souris jusqu'à attendre un sudo/su/dzdo… ou une saisie ne correspondant à rien (mot de passe), est relativement simple.

            Que ton keylogger n'ait pas l'accès au réseau, c'est pas dramatique, il finira par chopper les bons mots de passe pour sortir; voir mieux si tu n'as pas pensé à utiliser un utilisateur spécifique, une modification du .profile ou .bashrc peut faire des miracles.

            Notes bien la blague de débrancher le câble réseau ne fonctionne pas non plus, le processus pirate n'ayant qu'à attendre.

            Évidemment, on pourra après fermeture du programme s'assurer que tous ses processus soient bien arrêtés qu'il n'a pas ajouté des truc dans le at ou la cron (at.deny est ton ami)…

            Mais on commence à devoir configurer tout un tas de trucs dans tous les sens, une machine virtuelle (pour éviter le keylogger), ou mieux, dédiée, commence à devenir plus simple ;)

            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

      • [^] # Re: J'ai plus simple !

        Posté par . Évalué à 2 (+1/-0).

        Ainsi, la première étape consiste à implanter physiquement un virus dans la machine cible.

        bon à partir de là…

  • # La méthode la plus sûre

    Posté par . Évalué à 2 (+1/-1).

    ..c'est quand même l'utilisation d'une machine virtuelle pour tester ton appli. Avec désactivation de l'interface réseau au niveau Virtualbox.

    • [^] # Re: La méthode la plus sûre

      Posté par (page perso) . Évalué à 2 (+0/-0).

      https://www.google.com/amp/s/www.zdnet.fr/amp/actualites/une-zero-day-sur-virtualbox-et-pas-mal-de-grognements-39876125.htm

      Le plus sur est de l'installer sur une machine dédié sans câble réseau.

      Pour avoir encore plus de sécurité je propose que chaque programme d'une distribution tourne sur une machine dédié avec chacun son clavier, souris, écran et réseau ou non selon le programme.

    • [^] # Re: La méthode la plus sûre

      Posté par (page perso) . Évalué à 2 (+1/-0).

      C’est en tout cas plus compliqué. En quoi est-ce plus sûr ?

      Je comprends bien qu’en l’absence de carte réseau virtualisée l’OS invité n’en dispose plus et donc n’a plus, en théorie, de réseau.
      Finalement, c’est un peu la même chose avec les espaces de nommage réseau.

      Il me semble en fait que tu pars du principe qu’un programme malveillant pourra contourner l’isolation de son espace de nommage (et donc accéder à l’espace de nommage réseau de l’hôte), mais qu’une telle chose est impossible dans une VM… Il me semblait pourtant que des programmes malveillants avaient été observés, qui contournaient l’isolation de la VM pour accéder à l’hôte.

      Plus de détails m’intéressent, si tu as des liens.

      • [^] # Re: La méthode la plus sûre

        Posté par . Évalué à 1 (+0/-1).

        C’est en tout cas plus compliqué.

        Bof, c'est facile d'installer Virtualbox et de poper une machine virtuelle à partir d'une iso, ça prend 1h à tout péter, ensuite tu peux faire des templates. Ou encore utiliser Vagrant.

        En quoi est-ce plus sûr ?

        Tu as un environnement 100% isolé pas seulement au niveau réseau. Si le programme se met à scanner ton disque ou charger un rootkit, aucun risque pour ton hôte.

        Et puis tu peux très bien avoir une VM Windows ou d'une autre distribution.

        • [^] # Re: La méthode la plus sûre

          Posté par . Évalué à 4 (+2/-0).

          Tu as un environnement 100% isolé[…]

          Non. Tu as un environnement largement plus isolé, mais tu n'es pas à l'abri d'une faille de l'hyperviseur.

          Juste pour rappeler que le risque 0 n'existe pas.

          • [^] # Re: La méthode la plus sûre

            Posté par . Évalué à 1 (+0/-1).

            Une faille qui permet à une VM de déborder sur l'hôte, c'est exceptionnel, hein, c'est pas tous les jours et heureusement.

            • [^] # Re: La méthode la plus sûre

              Posté par (page perso) . Évalué à 2 (+1/-0).

              C'est pas tous les jours mais ça arrive quand même assez régulièrement (O(1 fois par an)). Après, c'est hautement improbable qu'un malware générique (qui ne vise pas spécifiquement cet utilisateur en sachant qu'il utilise ce type de VM) embarque de quoi utiliser ce genre de faille. Ça demanderait beaucoup de boulot pour peu de gains comparé au nombre de gens qui lanceront juste le bouzin sans aucune précaution.

            • [^] # Re: La méthode la plus sûre

              Posté par . Évalué à 2 (+1/-1).

              Quand c'est pas l'hyperviseur, ça peut tout simplement être l'administrateur qui l'a mal configuré (par exemple en laissant trop de ressources ou en partageant une partie du disque).

              Se dire « j'ai cliqué sur Virtualbox, donc c'est sécurisé, j'ai plus besoin de réfléchir », c'est potentiellement très dangereux.
              L'impression de sécurité c'est, amha, le mal absolu.

              Encore une fois on est d'accord que c'est largement plus sûr que les namespaces linux ou les jails bsd.

              • [^] # Re: La méthode la plus sûre

                Posté par . Évalué à 2 (+0/-0).

                Quand c'est pas l'hyperviseur, ça peut tout simplement être l'administrateur qui l'a mal configuré (par exemple en laissant trop de ressources ou en partageant une partie du disque).

                Heu… pour un virtualbox local sur ta machine, l'administrateur c'est toi, et par défaut il n'y a aucun partage de ressource.

                • [^] # Re: La méthode la plus sûre

                  Posté par . Évalué à 2 (+0/-0).

                  administrateur c'est toi

                  C'est bien ce qui est dangereux.

                  aucun partage de ressource

                  Je ne m'en suis pas servi récemment, mais j'ai déjà vu des installations fraîches avec le partage du tampon (c'est pratique de pouvoir faire des copier/coller).

                  Encore une dernière fois : tu peux utiliser les trucs les plus sécurisés du monde, si tu ne fais pas attention il existe toujours un risque. L'important c'est de savoir juger ce risque par rapport à tes craintes.

                  • [^] # Re: La méthode la plus sûre

                    Posté par . Évalué à 2 (+0/-0).

                    Je ne m'en suis pas servi récemment, mais j'ai déjà vu des installations fraîches avec le partage du tampon (c'est pratique de pouvoir faire des copier/coller).

                    Ce n'est pas activé par défaut, en plus je crois que cela nécessite l'installation des tools virtualbox dans le guest, ce qui n'est pas fait non plus par défaut.

                    Je parle du ratio sécurité/complexité, bien entendu qu'aucune solution n'est parfaite.

        • [^] # Re: La méthode la plus sûre

          Posté par (page perso) . Évalué à 7 (+5/-0).

          Si le programme se met à scanner ton disque ou charger un rootkit, aucun risque pour ton hôte.

          Dans ce cas, mets le dans un mount namespace. Et si tu as peur qu’il puisse voir tes autres process, mets le dans un PID namespace. Et si tu veut lui donner un autre hostname, mets le dans un hostname namespace.

          Bref, mets le dans Docker ou LXC.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.