Bonjour,
J'ai un SSD (identique à mon SSD interne) dans un boîtier USB externe,
et
j'ai envie d'y tester l'installation de QubesOS,
histoire de voir ça en vrai ;-))
Question :
Y-a-t-il des points particuliers à prévoir lors de l'installation UEFI/GPT de l'OS sur le disque externe
pour pouvoir (si l'expérience est concluante) remplacer l'actuel disque interne par le second,
et
pouvoir redémarrer dessus sans plus de formalités ?
Merci.
Système : Installation provisoire sur Disque USB externe
- PengouinPdt
- Contributeur
- Messages : 1343
- Inscription : 23 avr. 2016, 23:37
- Localisation : 47/FR
- Diaspora* : https://framasphere.org/u/hucste
- Contact :
- Status : Hors-ligne
certainement veillez à ce que ton ssd externe ait une petite partition de boot uefi, comme ça lors de l'installation le grub la verra et permettra le démarrage dessus.
(mais c'est une histoire classique cela, actuellement)
(mais c'est une histoire classique cela, actuellement)
PengouinPdt { le seul, le vrai } ~ " Libre as a Pengouin "
- DIY - Debian Sid | Devuan Ceres
----
Ne réponds pas aux PM d'assistance
- DIY - Debian Sid | Devuan Ceres
----
Ne réponds pas aux PM d'assistance
- dezix
- Membre hyper actif
- Messages : 3546
- Inscription : 04 juin 2016, 14:50
- Status : Hors-ligne
Bonjour
Un petit retour sur mon test de Qubes OS
Rappel je suis parvenu à Qubes via la réflexion sur la Sécurisation a posteriori
et
comme Piratebab l'a justement fait remarquer : Cette solution n'est pas vraiment simple
Matériel
Image ISO
Téléchargement => https://www.qubes-os.org/downloads/
Qubes-R4.0.3-x86_64.iso (actuel stable) a été installé et testé.
Qubes-R4.0.4-rc1-x86_64.iso (expérimental) testé (par erreur) avant la version stable
échec à cause du mauvais paramétrage du BIOS ; aurait probablement bien fonctionné aussi.
Installateur (clé usb)
Fait depuis Debian après vérification de l'authenticité ( voir => https://www.qubes-os.org/security/verifying-signatures/ )
avec :
# dd if=Qubes-RX-x86_64.iso of=/dev/sdY status=progress bs=1048576 && sync
Déroulement des tests d'installation
Intel NUC6 est doté de l'UEFI et c'est dans cette configuration que je l'utilise sous Debian.
J'ai mené les premières tentatives avec le SSD monté dans un boîtier externe USB, pour conserver le SSD interne (Debian),
et l'ISO expérimental (1er de la liste et téléchargé par inadvertance).
GrossoModo ça donne :
je n'ai pas testé le mode expert (partitions) ne sachant pas encore le comment du pourquoi.
PROBLÈME
En fait cela n'a pas été aussi immédiat,
car en fin d'install j'ai eu un message d'Avertissement :
J'ai poursuivi en obtenant un système sans GRUB
Voici ce que j'ai eu dans ce SSD externe :
Il y avait donc tout ce qu'il fallait avec:
Je n'ai pas tenté l'installation de GRUB dans un CHROOT
pour ne pas perdre mon temps à batailler avec Xen.
Je vous passe les détails,
mais me rendant alors compte qu'il y avait une version stable, j'ai douté de la version utilisée.
Puis de l'opportunité du montage externe ; j'ai donc refait un autre test en interne,
mais toujours la même chose.
Je suis allé sur L'IRC freenode #qubes
là on m'a conseillé de voir la liste du matériel testé
=> https://www.qubes-os.org/doc/#choosing-your-hardware
mon matos n'y est pas,
puis de passer :
BIOS
en : MODE LEGACY uniquement !
Là ça fonctionne jusqu'au final.
Et ensuite ça boote aussi bien en interne qu'en externe tant que le BIOS reste en Legacy :(
Donc c'est déjà pour moi un 1er inconvénient de taille,
car je n'aime pas trop devoir aller bricoler le BIOS plus le strict nécessaire.
Usage
Le démarrage est lent tant pour Xen (1ère couche qui sous-tend les VM )
que pour la VM dom0 (fedora) qui fourni l'environnement de base et la gestion des VM "utilisateur" (équivalent de VirtualBox )
que pour les VM utilisateur elles-mêmes.
Brute de décoffrage c'est tout de même assez lourdingue.
Par exemple en n'ayant aucune VM utilisateur en fonction,
la dom0 consomme en continu 25% de CPU et une bonne portion de RAM,
beaucoup plus que ma Testing installée et une VBox Debian LXDE exécutant Firefox (page ouverte/statique)
CONCLUSION
L'idée du cloisonnement des usages dans diverses VM plus ou moins sécurisées est excellente,
mais la mise en œuvre doit être perfectible.
Dans le cas présent je lui reproche :
Je ne prétends surtout pas que je suis capable de faire mieux,
et certainement pas aussi sûr et maîtrisé que ce que propose Qubes.
Mais j'espère, qu'il est possible de faire quelque-chose du même genre avec :
Le plus délicat est probablement le système de "Presse-papier" intermédiaire,
c'est une sorte de sas permettant d'échanger des données entre les divers domaines sans les compromettre.
Celui de Qubes est peut-être importable sans trop de difficultés
(je n'ai encore rien recherché à ce sujet)
Cela vous semble-t-il un projet que nous pourrions réaliser ici-même ?
@+
Un petit retour sur mon test de Qubes OS
Rappel je suis parvenu à Qubes via la réflexion sur la Sécurisation a posteriori
et
comme Piratebab l'a justement fait remarquer : Cette solution n'est pas vraiment simple
Matériel
- Machine = Mini PC Intel NUC6
- CPU = SOC Intel-Celeron J3455 => https://www.cpu-world.com/CPUs/Celeron/ ... J3455.html
(Supporte VT-d mais pas EPT qui fait partie des prérequis matériel) - RAM = 8Go DDR3
- Disque = SSD (testé en usb externe et en sata interne)
Image ISO
Téléchargement => https://www.qubes-os.org/downloads/
Qubes-R4.0.3-x86_64.iso (actuel stable) a été installé et testé.
Qubes-R4.0.4-rc1-x86_64.iso (expérimental) testé (par erreur) avant la version stable
échec à cause du mauvais paramétrage du BIOS ; aurait probablement bien fonctionné aussi.
Installateur (clé usb)
Fait depuis Debian après vérification de l'authenticité ( voir => https://www.qubes-os.org/security/verifying-signatures/ )
avec :
# dd if=Qubes-RX-x86_64.iso of=/dev/sdY status=progress bs=1048576 && sync
Déroulement des tests d'installation
Intel NUC6 est doté de l'UEFI et c'est dans cette configuration que je l'utilise sous Debian.
J'ai mené les premières tentatives avec le SSD monté dans un boîtier externe USB, pour conserver le SSD interne (Debian),
et l'ISO expérimental (1er de la liste et téléchargé par inadvertance).
GrossoModo ça donne :
- Pas besoin de connexion — Je pense même que c'est déconseillé pour raison de sécurité, le but étant d'installer un système sûr !
- boot sur la clé d'installation > ok!
- Interface graphique moderne et dépouillée > ok!
- Choix de la langue & du clavier (règle aussi les "local" d'install) > ok!
- Disque > Choix > Partition auto > Données chiffrées (LUKS) > ok!
- Libérer de l'espace => Affiche liste des parts existantes > Choisir celles à supprimer ou TOUT > ok!
- Logiciels > Défaut = VM de base XFCE + VM Debian 10 + VMs Whonix (réseau Tor + WorkStation)
- Start Install
- Compte Admin > Activer > MdP
- Compte User > Config
- Poursuite de l'install > Terminé
- Reboot
je n'ai pas testé le mode expert (partitions) ne sachant pas encore le comment du pourquoi.
PROBLÈME
En fait cela n'a pas été aussi immédiat,
car en fin d'install j'ai eu un message d'Avertissement :
suivi par le choix d'interrompre ou de poursuivre sachant que le système ne pourra pas être démarré.Warning : "Failed to set new efi boot target"
J'ai poursuivi en obtenant un système sans GRUB
Voici ce que j'ai eu dans ce SSD externe :
Code : Tout sélectionner
# lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
....
sdb
├─sdb1 vfat FAT16 CC79-3653 466,9M 7% /mnt/usb1
├─sdb2 ext4 1.0 aefe64aa-58e9-44e3-8862-795bf447e4cc 871,6M 4% /mnt/usb2
└─sdb3 crypto_L 1 b05038e1-be69-45f2-9c46-b8cbcb18c463
└─luks-b05038e1-be69-45f2-9c46-b8cbcb18c463
LVM2_mem LVM2 0 fhTTBe-Ip51-DFyZ-cJkf-awD0-aoVs-zRTNxC
├─qubes_dom0-pool00_tmeta
│ └─qubes_dom0-pool00-tpool
│ ├─qubes_dom0-pool00
│ └─qubes_dom0-root ext4 1.0 820803ed-05c1-462e-b8ac-e2d29c271f3f 150,1G 8% /media/dezix
├─qubes_dom0-pool00_tdata
│ └─qubes_dom0-pool00-tpool
│ ├─qubes_dom0-pool00
│ └─qubes_dom0-root ext4 1.0 820803ed-05c1-462e-b8ac-e2d29c271f3f 150,1G 8% /media/dezix
└─qubes_dom0-swap swap 1 9a314f5f-abe2-459a-bcaf-3d758171414e
Code : Tout sélectionner
# ls -lrh /dev/mapper
total 0
lrwxrwxrwx 1 root root 7 6 janv. 11:20 qubes_dom0-swap -> ../dm-6
lrwxrwxrwx 1 root root 7 6 janv. 11:21 qubes_dom0-root -> ../dm-5
lrwxrwxrwx 1 root root 7 6 janv. 11:20 qubes_dom0-pool00-tpool -> ../dm-3
lrwxrwxrwx 1 root root 7 6 janv. 11:20 qubes_dom0-pool00_tmeta -> ../dm-1
lrwxrwxrwx 1 root root 7 6 janv. 11:20 qubes_dom0-pool00_tdata -> ../dm-2
lrwxrwxrwx 1 root root 7 6 janv. 11:20 qubes_dom0-pool00 -> ../dm-4
lrwxrwxrwx 1 root root 7 6 janv. 11:20 luks-b05038e1-be69-45f2-9c46-b8cbcb18c463 -> ../dm-0
crw------- 1 root root 10, 236 6 janv. 11:20 control
Code : Tout sélectionner
# cat /etc/fstab
#
# /etc/fstab
# Created by anaconda on Tue Jan 5 22:40:34 2021
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/qubes_dom0-root / ext4 defaults,discard,x-systemd.device-timeout=0 1 1
UUID=aefe64aa-58e9-44e3-8862-795bf447e4cc /boot ext4 defaults 1 2
UUID=CC79-3653 /boot/efi vfat umask=0077,shortname=winnt 0 2
/dev/mapper/qubes_dom0-swap swap swap defaults,x-systemd.device-timeout=0 0 0
Il y avait donc tout ce qu'il fallait avec:
- part1 à monter sur /boot/efi
- part2 à monter sur /boot
Je n'ai pas tenté l'installation de GRUB dans un CHROOT
pour ne pas perdre mon temps à batailler avec Xen.
Je vous passe les détails,
mais me rendant alors compte qu'il y avait une version stable, j'ai douté de la version utilisée.
Puis de l'opportunité du montage externe ; j'ai donc refait un autre test en interne,
mais toujours la même chose.
Je suis allé sur L'IRC freenode #qubes
là on m'a conseillé de voir la liste du matériel testé
=> https://www.qubes-os.org/doc/#choosing-your-hardware
mon matos n'y est pas,
puis de passer :
BIOS
en : MODE LEGACY uniquement !
Là ça fonctionne jusqu'au final.
Et ensuite ça boote aussi bien en interne qu'en externe tant que le BIOS reste en Legacy :(
Donc c'est déjà pour moi un 1er inconvénient de taille,
car je n'aime pas trop devoir aller bricoler le BIOS plus le strict nécessaire.
Usage
Le démarrage est lent tant pour Xen (1ère couche qui sous-tend les VM )
que pour la VM dom0 (fedora) qui fourni l'environnement de base et la gestion des VM "utilisateur" (équivalent de VirtualBox )
que pour les VM utilisateur elles-mêmes.
Brute de décoffrage c'est tout de même assez lourdingue.
Par exemple en n'ayant aucune VM utilisateur en fonction,
la dom0 consomme en continu 25% de CPU et une bonne portion de RAM,
beaucoup plus que ma Testing installée et une VBox Debian LXDE exécutant Firefox (page ouverte/statique)
CONCLUSION
L'idée du cloisonnement des usages dans diverses VM plus ou moins sécurisées est excellente,
mais la mise en œuvre doit être perfectible.
Dans le cas présent je lui reproche :
- BIOS Legacy (pour mon matériel)
- Consomme trop de ressources pour l'infrastructure de base
- Xen et Fedora comme systèmes de base ; je préfère du 100% Debian... et de loin
- Pas facile ou je n'ai pas compris comment intégrer les nouveaux paquets installés manuellement dans une VM Debian.
Je ne prétends surtout pas que je suis capable de faire mieux,
et certainement pas aussi sûr et maîtrisé que ce que propose Qubes.
Mais j'espère, qu'il est possible de faire quelque-chose du même genre avec :
- Xen remplacé par une Debian mini
- la VM Fedora dom0 soit par Virtualbox soit par un autre système de conteneur encore plus léger
- des VM/conteneur pour chaque usage.
Le plus délicat est probablement le système de "Presse-papier" intermédiaire,
c'est une sorte de sas permettant d'échanger des données entre les divers domaines sans les compromettre.
Celui de Qubes est peut-être importable sans trop de difficultés
(je n'ai encore rien recherché à ce sujet)
Cela vous semble-t-il un projet que nous pourrions réaliser ici-même ?
@+
**Simple Utilisateur** -- Debian stable - XFCE
- dezix
- Membre hyper actif
- Messages : 3546
- Inscription : 04 juin 2016, 14:50
- Status : Hors-ligne
Ce que je retiens de mes lectures et réflexions ,
c'est que si on fait des le départ une installation neuve et minimal pour réduire la surface
qu'on ne lui donne pas d"accès réseau ou de façon très limitée et contrôlée uniquement pour les MàJ.
Alors cette base est sûre et devrait le rester à moindre coût.
Ensuite si toute l'activité "utilisateur" est cloisonnée et que toutes les opérations à risque sont faites dans des conteneurs jetables.
La vrai difficulté que j'y vois c'est pour transférer des données d'une zone moins sûre vers une zone plus sûr.
Pour les niveaux de sécurité en fait je n'en vois que 2 : sûr et pas sûr.
Là où l'on peut faire une sorte de classification c'est le niveau de durcissement du "pas sûr"
Mais j'imagine des conteneurs préfabriqués jetables par applications.
Je me documente un peu et je vais tenter un truc simple pour voir.
Passer par un hyperviseur (KVM) doit revenir grosso-modo à xen donc je laisse cela de côté pour maintenant.
Je vais faire mes premiers tests avec des conteneurs,
j'hésite entre Docker et LXD..;
... sur le quel partirais-tu ?
c'est que si on fait des le départ une installation neuve et minimal pour réduire la surface
qu'on ne lui donne pas d"accès réseau ou de façon très limitée et contrôlée uniquement pour les MàJ.
Alors cette base est sûre et devrait le rester à moindre coût.
Ensuite si toute l'activité "utilisateur" est cloisonnée et que toutes les opérations à risque sont faites dans des conteneurs jetables.
La vrai difficulté que j'y vois c'est pour transférer des données d'une zone moins sûre vers une zone plus sûr.
Pour les niveaux de sécurité en fait je n'en vois que 2 : sûr et pas sûr.
Là où l'on peut faire une sorte de classification c'est le niveau de durcissement du "pas sûr"
Mais j'imagine des conteneurs préfabriqués jetables par applications.
Je me documente un peu et je vais tenter un truc simple pour voir.
Passer par un hyperviseur (KVM) doit revenir grosso-modo à xen donc je laisse cela de côté pour maintenant.
Je vais faire mes premiers tests avec des conteneurs,
j'hésite entre Docker et LXD..;
... sur le quel partirais-tu ?
**Simple Utilisateur** -- Debian stable - XFCE
- dezix
- Membre hyper actif
- Messages : 3546
- Inscription : 04 juin 2016, 14:50
- Status : Hors-ligne
Oui, je suis parti sur Docker
Peut-être peux-tu me mettre sur la piste ?
Une des conditions essentielles étant de partir sur une base neuve et sûre,
je pars du postulat que (j'espère juste) les dépôts stables main + (à minima pour les firmwares) contrib, non-free sont fiables.
Ce qui m'amène à ne pas utiliser les images en provenance de Docker Hub,
mais des images "Maison" FROM scratch
J'entrevois (en cours de test) comment construire une image minimale Debian
en utilisant debootstrap
mais,
je ne trouve toujours pas l'info me permettant de comprendre :
Comment construire un conteneur juste pour une application
en s'appuyant / faisant le lien avec l'OS sous-jacent.
Je n'ai peut-être pas (encore) correctement compris la notion de conteneur ?
Si nombres d'images sur Docker Hub se basent sur un conteneur reproduisant un OS,
il me semble que l'(autre) intérêt principal des conteneurs,
est que l'application qu'il contient peut voir/utiliser la base logicielle fournit par l'hôte.
Ce que je ne parviens pas savoir/comprendre :
Comment fournit-on le lien vers les services de l'hôte ?
Par exemple si hôte dispose d'un environnement graphique,
comment l'utiliser dans le conteneur, sans devoir l'installer dans le conteneur ?
J'espère que la question est bien formulée... car visiblement, il me manque encore des pièces
**Simple Utilisateur** -- Debian stable - XFCE