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 rahan . Évalué à 10.
Tu peux essayer les deux commandes suivantes :
unshareetfirejail.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 firefoxIl 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 barmic . Évalué à 9.
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
ipdevrait être dispo dans la majorité des installations minimales car c'est elle qui déprécieifconfigsi je ne m'abuse.# Flatpak
Posté par ff9097 . Évalué à -1.
Sinon Flatpak est conçu pour ça
[^] # Re: Flatpak
Posté par cmal (site web personnel) . Évalué à 1.
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).[^] # Re: Flatpak
Posté par ff9097 . Évalué à 7.
Sinon tenter ça :
flatpak run --unshare=network org.something.App[^] # Re: Flatpak
Posté par cmal (site web personnel) . Évalué à 0.
Merci beaucoup! :)
# Sinon il y a systemd
Posté par GnunuX (site web personnel) . Évalué à 10.
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 Yves (site web personnel) . Évalué à 2. Dernière modification le 05 mars 2019 à 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 benoar . Évalué à 3.
Mmmhhh… tu peux expliquer ton utilisation ? Parce que là, je ne vois pas l'utilité…
[^] # Re: Sinon il y a systemd
Posté par Yves (site web personnel) . Évalué à 5.
Nginx a 3 sections de configuration :
/run/http;/run/https;/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 :
[^] # Re: Sinon il y a systemd
Posté par benoar . Évalué à 5.
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…
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 ?
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 Yves (site web personnel) . Évalué à 3.
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…
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 benoar . Évalué à 1.
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 Yves (site web personnel) . Évalué à 2.
« 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 Arthur Accroc . Évalué à 2.
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.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Sécurité
Posté par Benoît Sibaud (site web personnel) . Évalué à 3. Dernière modification le 09 mars 2019 à 16:08.
Les chiffres le montrent, il vaut mieux utiliser les dérivées ça réduit les failles (ou pas).
(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 Arthur Accroc . Évalué à 2. Dernière modification le 09 mars 2019 à 18:40.
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 ?
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.
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.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Sécurité
Posté par Benoît Sibaud (site web personnel) . Évalué à 3. Dernière modification le 09 mars 2019 à 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.)
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 Benoît Sibaud (site web personnel) . Évalué à 3.
Quelques autres cas de soucis importants (au minimum pour l'image d'un système et de sa sécurité) :
[^] # Re: Sécurité
Posté par Arthur Accroc . Évalué à 2.
Ça date quand même d’une dizaine d’années.
Ça ne concerne pas du code spécifique à ces distributions, mais la sécurité de leurs serveurs.
Ça n’est pas si évident que ça de garantir en permanence la parfaite sécurité d’un serveur, entre les services et les failles constamment trouvées dessus et les utilisateurs ; je ne me permettrais pas de leur jeter la pierre.
Je reste convaincu que d’un point de vue sécurité, mieux vaut quand même une distribution qui n’a pas pour habitude d’ajouter elle-même des failles à celles déjà existantes dans les logiciels qui la composent.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Sécurité
Posté par Arthur Accroc . Évalué à 2.
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 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…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Sécurité
Posté par barmic . Évalué à 2.
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.
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 Benoît Sibaud (site web personnel) . Évalué à 4.
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
Ubuntu https://people.canonical.com/~ubuntu-security/cve/pkg/openssh.html
# J'ai plus simple !
Posté par fearan . Évalué à 6.
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 Mimoza . Évalué à 3.
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 fearan . Évalué à 3.
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 Colin Pitrat (site web personnel) . Évalué à 2.
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 fearan . Évalué à 3.
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 passant·e . Évalué à 2.
Ainsi, la première étape consiste à implanter physiquement un virus dans la machine cible.
bon à partir de là…
Je trolle dès quand ça parle business, sécurité et sciences sociales
# La méthode la plus sûre
Posté par MTux . Évalué à 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 phoenix (site web personnel) . Évalué à 2.
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 MTux . Évalué à 0.
Oui mais moins facile en terme logistique, alors que poper une machine virtuelle c'est rapide.
C'est un peu l'idée derrière flatpak et snap, chaque programme tourne en sandbox.
Mais là je rappelle qu'on parle d'un cas où tu veux tester un truc auquel tu ne fais absolument pas confiance.
[^] # La vraie adresse
Posté par Arthur Accroc . Évalué à 10. Dernière modification le 05 mars 2019 à 20:00.
https://www.zdnet.fr/actualites/une-zero-day-sur-virtualbox-et-pas-mal-de-grognements-39876125.htm
Il y a quelques temps, c’était la mode des raccourcisseurs d’adresses, et on se posait des questions à leur propos.
Maintenant, la mode semble être à utiliser Google — dont on sait qu’il aime amasser les données — comme rallongeur d’adresse. Là, ça me dépasse…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: La méthode la plus sûre
Posté par Yves (site web personnel) . Évalué à 2.
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 MTux . Évalué à 0.
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.
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 barmic . Évalué à 4.
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 MTux . Évalué à 0.
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 Colin Pitrat (site web personnel) . Évalué à 2.
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 MTux . Évalué à 0.
Et du côté des containers il n'y a jamais de faille ?
[^] # Re: La méthode la plus sûre
Posté par barmic . Évalué à 2.
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 MTux . Évalué à 1.
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 barmic . Évalué à 2.
C'est bien ce qui est dangereux.
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 MTux . Évalué à 1.
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 Anonyme . Évalué à 7.
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.
[^] # Re: La méthode la plus sûre
Posté par MTux . Évalué à -2.
Et pour ta VM, tu as juste à cliquer sur "démarrer", ça reste plus simple et mieux isolé.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.