Chapitre 10 Cas d’usage : travailler sur un document sensible
10.1 Contexte
Après avoir pris un nouveau départ, l’ordinateur utilisé pour mener ce projet à bien a été équipé d’un système chiffré. Bien. Survient alors le besoin de travailler sur un projet particulier, plus « sensible », par exemple :
- un tract doit être rédigé ;
- une affiche doit être dessinée ;
- un livre doit être maquetté puis exporté en PDF ;
- une fuite d’informations doit être organisée pour divulguer les affreuses pratiques d’une entreprise ;
- un film doit être monté et gravé sur DVD.
Dans tous ces cas, les problèmes à résoudre sont à peu près les mêmes.
Comme il serait trop pénible d’augmenter globalement, de nouveau, le niveau de sécurité de l’ordinateur, il est décidé que ce projet particulier doit bénéficier d’un traitement de faveur.
10.1.1 Conventions de vocabulaire
Par la suite, nous nommerons :
- les fichiers de travail : l’ensemble des fichiers nécessaires à la réalisation de l’œuvre (les images ou rushes utilisés comme bases, les documents enregistrés par le logiciel utilisé, etc.) ;
- l’œuvre : le résultat final (tract, affiche, etc.).
En somme, la matière première, et le produit fini.
10.2 Évaluer les risques
Tentons maintenant de définir les risques auxquels exposent le travail sur un document sensible.
10.2.1 Que veut-on protéger ?
Appliquons au cas présent les catégories définies lorsque nous parlions d’évaluation des risques :
- confidentialité : éviter qu’un œil indésirable ne découvre trop aisément l’œuvre et/ou les fichiers de travail ;
- intégrité : éviter que ces documents ne soient modifiés à notre insu ;
- accessibilité : faire en sorte que ces documents restent accessibles quand on en a besoin.
Ici, accessibilité et confidentialité sont prioritaires.
Accessibilité, car l’objectif principal est tout de même de réaliser l’œuvre. S’il fallait se rendre au pôle Nord pour ce faire, le projet risquerait fort de tomber à l’eau (glacée).
Et pour ce qui est de la confidentialité, tout dépend de la publicité de l’œuvre. Voyons donc ça de plus près.
10.2.1.1 Œuvre à diffusion restreinte
Si le contenu de l’œuvre n’est pas complètement public, voire parfaitement secret, il s’agit de dissimuler à la fois l’œuvre et les fichiers de travail.
10.2.1.2 Œuvre diffusée publiquement
Si l’œuvre a vocation à être publiée, la question de la confidentialité se ramène à celle de l’anonymat.
C’est alors, principalement, les fichiers de travail qui devront passer sous le tapis : en effet, les découvrir sur un ordinateur incite fortement à penser que ses propriétaires ont réalisé l’œuvre… avec les conséquences potentiellement désagréables que cela peut avoir.
Mais ce n’est pas tout : si l’œuvre, ou ses versions intermédiaires, sont stockées sur cet ordinateur (PDF, etc.), leur date de création est très probablement enregistrée dans le système de fichiers et dans des métadonnées. Le fait que cette date soit antérieure à la publication de l’œuvre peut aisément amener des adversaires à tirer des conclusions gênantes quant à sa généalogie.
10.2.2 Contre qui veut-on se protéger ?
Reprenons les menaces décrites dans le cas d’usage « un nouveau départ » : l’ordinateur utilisé pour réaliser l’œuvre peut être dérobé par de quelconques flics ou lors d’un cambriolage.
10.3 Quel système d’exploitation privilégier pour travailler sur le document ?
10.3.1 Décider des logiciels nécessaires
La première question qui se pose est : quels logiciels seront utilisés pour ce projet ?
Si les logiciels nécessaires fonctionnent sous GNU/Linux, continuons la lecture de ce chapitre pour étudier les options qui s’offrent à nous.
Si ces logiciels ne marchent que sous Windows (ou Mac OS), ça vaut le coup de chercher si des logiciels similaires sont disponibles sous Debian GNU/Linux. S’ils existent, les tester pour voir s’ils semblent fonctionnels pour ce projet.
Si vraiment seuls des logiciels Windows sont satisfaisants, c’est dommage. Mais nous proposons tout de même un chemin praticable qui permet de limiter la casse. Allons donc voir à quoi ressemble cette méthode, en ignorant les paragraphes suivants, qui sont consacrés à GNU/Linux.
10.3.2 Utiliser un système live amnésique pour laisser le moins de traces possible
On pourrait imaginer configurer finement un système Debian chiffré pour qu’il conserve le moins de traces possible de nos activités sur le disque dur. Le problème de cette approche, c’est qu’elle est de type « liste bloquée ». Nous en avons expliqué les limites : quel que soit le temps consacré, quelle que soit l’expertise mise au travail, même avec une compréhension particulièrement poussée des entrailles du système d’exploitation, on oublierait toujours une petite option bien cachée, il resterait toujours des traces indésirables auxquelles on n’avait pas pensé.
Un chapitre est consacré à l’installation d’un système Debian chiffré, mais l’ensemble des méthodes pour limiter les traces n’y est pas développé. Heureusement, certains systèmes live amnésiques fonctionnent sur le principe de la « liste autorisée » : tant qu’on ne le demande pas explicitement, aucune trace n’est laissée sur le disque dur.
En envisageant uniquement le critère « confidentialité », le système live bat donc l’autre à plate couture. En revanche, si son principal atout est d’être amnésique, cela peut présenter parfois un inconvénient. Ainsi, dans le cas où notre système live préféré ne fournit pas un logiciel indispensable au projet, il faut l’installer à chaque démarrage, ce qui peut fort heureusement être fait de manière automatique.
Si l’utilisation d’un système live est ainsi la solution la plus sûre, c’est aussi la solution la moins difficile à mettre en place au vu de la difficulté que représenterait l’installation d’un système Debian ne laissant que peu de traces. Dans la partie suivante, nous étudierons donc une politique de sécurité basée sur cette solution.
À noter qu’il est aussi possible d’installer un système Debian dans une machine virtuelle afin de satisfaire des besoins similaires, mais cette solution est moins adaptée et ne sera donc pas détaillée ici. On peut trouver de la documentation en ligne, même s’il est important de prendre pour Debian les mêmes précautions de compartimentation que celles développées dans le chapitre consacré à la création d’une machine virtuelle Windows.
10.4 Travailler sur un document sensible… sur un système live
Après avoir présenté le contexte dans le début de ce cas d’usage et décidé d’utiliser un système live, il reste à mettre cette solution en place… et à étudier ses limites.
10.4.1 Télécharger et installer le système live
Tous les systèmes live ne sont pas particulièrement destinés à des pratiques « sensibles ». Il importe donc de choisir un système spécialement conçu pour (tenter de) ne laisser aucune trace sur le disque dur de l’ordinateur sur lequel il est utilisé. Ce guide choisit de privilégier et de documenter le système live Tails.
Si l’on ne dispose pas encore d’une copie de la dernière version du système live Tails, suivre la recette pour télécharger et installer un système live « discret ».
Une fois notre périphérique Tails installé sur notre clé, on peut, si on veut, créer un espace de stockage chiffré pour enregistrer certains de nos documents ou réglages. Pour cela, se munir du système live précédemment installé et le démarrer. Suivre ensuite la recette pour créer et configurer un volume persistant dans Tails.
10.4.2 Installer un éventuel logiciel additionnel
Si l’on a besoin d’utiliser un logiciel qui n’est pas installé dans Tails et que l’on ne veut pas le réinstaller à chaque fois, suivre la recette pour installer un logiciel additionnel persistant dans Tails.
10.4.3 Utiliser le système live
Chaque fois que l’on souhaite travailler sur notre document, il suffit de se munir de la clé contenant notre système live et sa persistance chiffrée pour démarrer dessus. On doit alors activer le volume persistant.
10.4.4 Supprimer les données
Une fois notre projet terminé et imprimé ou publié en ligne, on peut éventuellement archiver le projet. Il nous faut ensuite supprimer le volume persistant qui contient les données.
10.4.5 Ce n’est pas fini
Il reste à nettoyer les métadonnées et à étudier les limites de notre approche.
10.5 Travailler sur un document sensible… sous Windows
Après avoir présenté le contexte dans le début de ce cas d’usage et, malgré tous les problèmes que pose l’utilisation de Windows, essayons maintenant de limiter un peu la casse.
10.5.1 Point de départ : une passoire et une boîte de rustines desséchées
Partons d’un ordinateur muni, de la façon la plus classique qui soit, d’un disque dur sur lequel Windows est installé. Nous ne nous appesantirons pas sur cette situation, la première partie de cet ouvrage ayant abondamment décrit les multiples problèmes qu’elle pose. Une passoire, en somme, pleine de trous de sécurité.
On peut donc imaginer coller quelques rustines sur cette passoire145. Faisons-en rapidement le tour.
Un disque dur, ça se démonte et ça se cache. Certes. Mais il y a les périodes où l’on s’en sert, parfois plusieurs jours ou semaines d’affilée. Cette rustine est basée sur deux hypothèses quelque peu osées :
- Nous avons de la chance. Il suffit en effet que l’accident (perquisition, cambriolage, etc.) survienne au mauvais moment pour que toute la confidentialité désirée soit réduite à néant.
- Notre discipline est parfaitement rigoureuse. En effet, si l’on oublie, ou qu’on ne prend pas le temps, d’aller « ranger » le disque dur quand on n’en a plus besoin, et que l’accident survient à ce moment-là, c’est perdu, fin de la partie.
Par ailleurs, des outils existent pour chiffrer des données sous Windows. Quelle que soit la confiance qu’on leur accorde, il n’en reste pas moins qu’ils s’appuient obligatoirement sur les fonctions offertes par la boîte noire qu’est Windows. On ne peut donc que s’en méfier, et, dans tous les cas, Windows, lui, aura accès à nos données en clair, et personne ne sait ce qu’il pourrait bien en faire.
Pour conclure ce petit tour dans la cour des miracles douteux, ajoutons que la seule « solution » possible dans le cas présent serait une approche de type liste bloquée, dont l’inefficacité a déjà été expliquée précédemment
Il est maintenant temps de passer aux choses sérieuses.
10.5.2 Seconde étape : enfermer Windows dans un compartiment (presque) étanche
Ce qui commence à ressembler à une solution sérieuse, ce serait de faire fonctionner Windows dans un compartiment étanche, dans lequel on ouvrirait, quand c’est nécessaire et en connaissance de cause, une porte pour lui permettre de communiquer avec l’extérieur de façon strictement limitée.
En d’autres termes, mettre en place une solution basée sur une logique de type liste autorisée : rien ne pourrait entrer dans Windows ou en sortir a priori, et à partir de cette règle générale, on autorise des exceptions, au cas par cas, en réfléchissant à leur impact.
La virtualisation146 permet de mettre en place ce type de systèmes. C’est un ensemble de techniques matérielles et logicielles qui permettent de faire fonctionner, sur un seul ordinateur, plusieurs systèmes d’exploitation, séparément les uns des autres, (presque) comme s’ils fonctionnaient sur des machines physiques distinctes.
Il est ainsi relativement facile, de nos jours, de faire fonctionner Windows à l’intérieur d’un système GNU/Linux, en lui coupant, par la même occasion, tout accès au réseau — et en particulier, en l’isolant d’Internet.
Attention : il est conseillé de lire l’intégralité de ce chapitre avant de se précipiter sur les recettes pratiques ; la description de l’hypothèse qui suit est assez longue, et ses limites sont étudiées à la fin de ce chapitre, où des contre-mesures sont envisagées. Il serait quelque peu dommage de passer quatre heures à suivre ces recettes, avant de se rendre compte qu’une tout autre solution serait, en fait, plus adéquate.
Commençons par résumer l’hypothèse proposée.
L’idée est donc de faire fonctionner Windows dans un compartiment a priori étanche, à l’intérieur d’un système Debian chiffré tel que celui qui a pu être mis en place à la suite de la lecture du cas d’usage précédent. Ce qui servira de disque dur à Windows, c’est en fait un gros fichier stocké sur le disque dur de notre système Debian chiffré.
10.5.2.1 Installer le Gestionnaire de machines virtuelles
Il nous faut donc tout d’abord suivre la recette pour installer le Gestionnaire de machines virtuelles. Ce logiciel nous servira à lancer Windows dans un compartiment étanche.
10.5.2.2 Installer un Windows « propre » dans le Gestionnaire de machines virtuelles
Préparons une image de disque virtuel propre : pour cela, suivre la recette pour installer un Windows virtualisé. Cette recette explique comment installer Windows dans le Gestionnaire de machines virtuelles en lui coupant, dès le départ, tout accès au réseau.
À partir de ce moment-là, on qualifie Windows de système invité par le système Debian chiffré, qui, lui, est le système hôte.
10.5.2.3 Installer les logiciels nécessaires dans le Windows « propre »
Autant installer, dès maintenant, dans le Windows « propre », tout logiciel non compromettant147 nécessaire à la réalisation des œuvres préméditées : ça évitera de le refaire au début de chaque nouveau projet… et ça évitera, souhaitons-le ardemment, d’utiliser une image Windows « sale » pour un nouveau projet, un jour où le temps presse.
Vu que le Windows invité n’a pas le droit de sortir de sa boîte pour aller chercher lui-même des fichiers, il est nécessaire de lui faire parvenir depuis « l’extérieur » les fichiers d’installation des logiciels nécessaires.
Une telle opération sera aussi utile, par la suite, pour lui envoyer toutes sortes de fichiers, et nous y reviendrons. Pour l’heure, vu que nous sommes en train de préparer une image de Windows « propre », servant de base à chaque nouveau projet, ne mélangeons pas tout, et contentons-nous de lui envoyer uniquement ce qui est nécessaire à l’installation des logiciels non compromettants souhaités.
Créons, sur le système hôte, un dossier nommé Logiciels Windows, et copions-y uniquement les fichiers nécessaires à l’installation des logiciels souhaités.
Puis partageons ce dossier avec le Windows invité. Pour cela, suivre la recette pour partager un dossier avec un système virtualisé.
Et en ce qui concerne l’installation des logiciels à l’intérieur du Windows invité : toute personne suffisamment accro à Windows pour lire ces pages est, sans aucun doute, plus compétente que celles qui écrivent ces lignes.
Attention : une fois cette étape effectuée, il est impératif de ne rien faire d’autre dans ce Windows virtualisé.
10.5.2.4 Prendre un instantané du Windows « propre »
Prenons maintenant un instantané de la machine virtuelle propre qui vient d’être préparée. C’est-à-dire : sauvegardons son état dans un coin. Par la suite, cet instantané servira de base de départ pour chaque nouveau projet.
Il faut donc suivre la recette pour prendre un instantané d’une machine virtuelle.
10.5.2.5 Nouveau projet, nouveau départ
Mettons qu’un nouveau projet nécessitant l’utilisation de Windows débute ; voici la marche à suivre :
- On restaure l’instantané de la machine virtuelle contenant l’installation de Windows propre.
- La machine virtuelle peut maintenant être démarrée dans son compartiment étanche. Elle servira exclusivement pour le nouveau projet, et devient désormais une machine virtuelle sale.
- Au sein de cette nouvelle machine virtuelle sale, une nouvelle utilisatrice Windows est créée. Le nom qui lui est attribué doit être différent à chaque fois qu’un nouveau projet est ainsi démarré, et cette utilisatrice servira exclusivement pour ce nouveau projet. Ceci, parce que les logiciels tendent à inscrire le nom de l’utilisatrice active dans les métadonnées des fichiers qu’ils enregistrent, et qu’il vaut mieux éviter de rendre possibles de fâcheux recoupements.
Les détails techniques de la première étape sont expliqués dans la recette pour restaurer l’état d’une machine virtuelle à partir d’un instantané. En ce qui concerne la création d’une nouvelle utilisatrice sur la version de Windows utilisée, la personne lisant ces page est une fois encore certainement à même de la trouver du côté du Panneau de configuration.
Maintenant que nous avons un compartiment étanche, voyons comment y ouvrir des portes sélectivement, en fonction des besoins.
10.5.2.5.2 Comment faire sortir des fichiers du Windows embastillé ?
Le Windows invité n’a pas le droit, par défaut, de laisser de traces en dehors de son compartiment étanche. Mais presque inévitablement vient le temps où il est nécessaire d’en faire sortir des fichiers, et, à ce moment-là, il nous faut l’autoriser explicitement. Par exemple :
- pour emmener à la boîte-à-copies, ou à l’imprimerie, un fichier PDF exporté ;
- pour projeter, sous forme de DVD, le film fraîchement réalisé.
Pour cela, on va exporter ces fichiers vers un dossier vide, dédié à cet usage, et stocké sur un volume chiffré qui peut être :
- une clé USB chiffrée, qu’on active sous Debian en tapant la phrase de passe correspondante ;
- le disque dur de la Debian chiffrée qui fait ici office de système hôte.
Ce dossier dédié sera partagé avec le Windows invité. Insistons sur les mots vide et dédié : Windows pourra lire et modifier tout ce que ce dossier contient, et il serait dommageable de lui permettre de lire des fichiers, quand on a seulement besoin d’exporter un fichier.
Si l’on a besoin de graver un DVD, ou pourra ensuite le faire à partir de Debian.
Afin d’éviter de se mélanger les pinceaux et de limiter la contagion, il est recommandé de :
- créer un seul dossier d’exportation par projet ;
- nommer ce dossier de façon aussi explicite que possible ; par exemple : Dossier où Windows peut écrire ;
- ne jamais partager d’autres dossiers que celui-ci avec le Windows invité, mis à part le dossier d’importation que le paragraphe précédent préconise.
Les recettes pour partager un dossier avec un système virtualisé et pour chiffrer une clé USB expliquent comment procéder pratiquement.
10.5.2.6 Quand le projet est terminé
Quand ce projet est terminé, il faut faire le ménage, mais avant toute chose :
- l’œuvre résultante est exportée sur le support approprié (papier, DVD, etc.), en s’aidant du paragraphe précédent, qui explique comment faire sortir des fichiers du Windows invité ;
- les fichiers de travail sont, si nécessaire, archivés (le cas d’usage suivant traitant, quelle coïncidence, de la question).
Puis vient l’heure du grand ménage, qui éliminera du système hôte le plus possible de traces du projet achevé :
- l’image de disque virtuel est restaurée à son état « propre » grâce à la recette pour restaurer l’état d’une machine virtuelle à partir d’un instantané ;
- après avoir vérifié, une dernière fois, que tout ce qui doit être conservé a bien été archivé ailleurs, les dossiers partagés avec Windows sont effacés « pour de vrai » ;
- les traces laissées sur le disque dur sont effacées « pour de vrai ».
10.5.2.7 Encore un nouveau projet ?
Si un nouveau projet survient, nécessitant lui aussi d’utiliser Windows, ne réutilisons pas le même Windows sale. Retournons plutôt à l’étape « nouveau projet, nouveau départ ».
10.5.3 Troisième étape : attaques possibles et contre-mesures
L’hypothèse que nous venons de décrire est basée sur l’utilisation, comme système hôte, d’une Debian chiffrée. Toutes les attaques concernant cette Debian chiffrée sont donc applicables à la présente solution. Il est maintenant temps d’étudier les attaques praticables contre ce système.
10.5.3.1 Traces laissées sur notre Debian chiffrée
La plupart des traces les plus évidentes de ce projet sont séparées du reste du système : tous les fichiers de travail sont stockés dans le fichier contenant l’image de disque virtuel. Le nom de la machine virtuelle, sa configuration ainsi que ses périodes d’utilisation laisseront par contre d’autres traces sur notre système Debian.
10.5.3.1.1 Si la catastrophe arrive pendant la réalisation du projet
Le disque dur de l’ordinateur utilisé contient les fichiers de travail à l’intérieur de l’image de disque virtuel.
10.5.3.1.2 Si la catastrophe arrive plus tard
L’image de disque virtuel étant convenablement nettoyée lorsque le projet est achevé, si la catastrophe (céder face à la loi, découverte d’un problème dans le système cryptographique) arrive après coup, les traces résiduelles sur le disque dur seront moins évidentes, et moins nombreuses, que si l’on avait procédé de façon ordinaire.
Même si la catastrophe arrive après la fin du projet, c’est-à-dire après le nettoyage conseillé ici, il serait malvenu de se sentir immunisée, car comme le début de ce cas d’usage l’explique, l’inconvénient majeur de la méthode décrite ici est qu’elle est basée sur le principe de liste bloquée, principe abondamment décrié en ces pages… et il restera donc toujours des traces indésirables, auxquelles on n’avait pas pensé, sur le disque dur de l’ordinateur utilisé, en plus de celles qu’on connaît bien désormais : journaux, mémoires vive et « virtuelle », sauvegardes automatiques.
Si, malgré ces soucis, l’hypothèse que nous venons de décrire semble être un compromis acceptable, il est maintenant nécessaire de se renseigner sur les limites partagées par toutes les solutions envisagées dans ce cas d’usage.
Sinon, creusons un peu.
10.5.3.2 Aller plus loin
Admettons qu’une des attaques décrites à partir de la troisième étape du cas d’usage « un nouveau départ » semble crédible. Si elle réussissait, le contenu du disque dur chiffré du système hôte serait lisible, en clair, par l’attaquante. Or nos fichiers de travail sont, rappelons-le, contenus dans l’image de disque virtuel utilisée par notre Windows invité… qui est un bête fichier stocké sur le disque dur du système hôte. Ces fichiers de travail, ainsi que toute trace enregistrée par les logiciels utilisés dans Windows, deviennent alors lisibles par l’attaquante.
Nous allons envisager deux pistes permettant de limiter les dégâts. L’une est de type « liste bloquée », l’autre est de type « liste autorisée ».
10.5.3.2.1 Stocker l’image de disque virtuel en dehors du disque du système hôte
Une idée est de stocker hors du disque dur du système hôte l’image de disque virtuel utilisée par le système Windows invité. Par exemple, sur un disque dur externe chiffré. Ainsi, même si le disque du système hôte est déchiffré, nos fichiers de travail restent inaccessibles… pourvu que le disque dur externe qui les contient ne soit pas à la portée de l’adversaire à ce moment-là.
Cette approche est de type « liste bloquée », avec tous les problèmes que ça pose. Les fichiers de travail et le système Windows ne sont pas enregistrés sur le disque dur du système hôte. Mais il ne faut pas oublier que ces données seront utilisées par le Gestionnaire de machines virtuelles, qui lui fonctionne sur le système hôte. Comme le chapitre « traces à tous les étages » l’explique, diverses traces subsisteront donc, inévitablement, sur le disque dur interne de l’ordinateur utilisé.
Pour suivre cette piste :
- se renseigner sur les limites partagées par toutes les solutions envisagées dans ce cas d’usage ;
- se reporter à la recette permettant de chiffrer un disque dur externe.
10.5.3.2.2 Utiliser un système live comme système hôte
Le pendant de cette approche « liste bloquée » est une solution de type « liste autorisée », conjuguant l’utilisation d’un système live et le stockage de l’image de disque virtuel sur un disque dur externe chiffré.
Pour suivre cette piste :
- se renseigner sur les limites partagées par toutes les solutions envisagées dans ce cas d’usage ;
- se reporter à la recette permettant de chiffrer un disque dur externe, et à celle qui explique comment utiliser un système live.
10.6 Nettoyer les métadonnées du document terminé
Une fois notre document terminé, on l’exportera dans un format adapté à l’échange de documents — par exemple un PDF pour imprimer un texte, un fichier AVI ou MKV pour publier une vidéo sur Internet, etc.
Considérons qu’on publie notre document sans prendre de plus amples précautions. Des adversaires à qui il déplairait vont probablement commencer par télécharger le document en quête d’éventuelles métadonnées qui le rapprocheraient des personnes qui l’ont réalisé.
Malgré les précautions qu’on a déjà prises, il est bon de nettoyer les éventuelles métadonnées présentes.
10.7 Limites communes à ces politiques de sécurité
Toute politique de sécurité étudiée dans ce cas d’usage est vulnérable à un certain nombre d’attaques, indépendamment de l’utilisation d’un système live ou de l’infâme Windows.
Les angles d’attaque du chapitre nouveau départ étudient certaines des attaques imaginables, relevant plus ou moins de la science-fiction, selon l’époque, le lieu, les protagonistes et les circonstances. Le moment est venu de les relire d’un œil nouveau.
Par ailleurs, la partie « problématiques » de ce tome abordait, de façon relativement générale, de nombreux modes de surveillance, qu’il peut être bon de réétudier à la lumière de la situation concrète qui nous occupe ; nommons en particulier les questions d’électricité, champs magnétiques et ondes radio, ainsi que les effets des divers mouchards.
Pour plus d’informations, voir la page Wikipédia, 2020, Virtualisation.↩︎
Par exemple, si l’on souhaite cacher le fait qu’on fabrique des films, avoir des logiciels de montage vidéo peut être compromettant.↩︎
10.5.2.5.1 Comment envoyer des fichiers au Windows embastillé ?
Vu que le Windows invité n’a pas le droit de sortir de sa boîte pour aller chercher lui-même des fichiers, il peut être nécessaire de lui en faire parvenir depuis « l’extérieur », par exemple :
Nous avons déjà vu comment procéder, mais c’était dans un cas très particulier : l’installation de nouveaux logiciels dans un Windows « propre » invité. Partager des fichiers avec un Windows « sale » requiert davantage de réflexion et de précautions, que nous allons maintenant étudier.
La façon de faire est légèrement différente, en fonction du support sur lequel se trouvent, à l’origine, les fichiers à importer (CD, DVD, clé USB, dossier présent sur le disque dur du système chiffré), mais les précautions d’usage sont les mêmes :
Afin d’éviter de se mélanger les pinceaux, il est recommandé de :
Des explications pratiques sont données dans la recette pour envoyer des fichiers au système virtualisé.