Système : Installation provisoire sur Disque USB externe

On y discute de tout, ou presque...
Répondre
Avatar de l’utilisateur
dezix
Membre hyper actif
Membre hyper actif
Messages : 3546
Inscription : 04 juin 2016, 14:50
Status : Hors-ligne

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.
**Simple Utilisateur** -- Debian stable - XFCE
Avatar de l’utilisateur
PengouinPdt
Contributeur
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)
PengouinPdt { le seul, le vrai } ~ " Libre as a Pengouin "
- DIY - Debian Sid | Devuan Ceres
----
Ne réponds pas aux PM d'assistance
Avatar de l’utilisateur
dezix
Membre hyper actif
Membre hyper actif
Messages : 3546
Inscription : 04 juin 2016, 14:50
Status : Hors-ligne

Bonjour :006:


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 :lol:

Image




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 :
  • 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
Donc en théorie c'est assez simple en mode assisté
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 :
Warning : "Failed to set new efi boot target"
suivi par le choix d'interrompre ou de poursuivre sachant que le système ne pourra pas être démarré.

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
/etc/fstab étant déjà correctement configuré.

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 :
  1. BIOS Legacy (pour mon matériel)
  2. Consomme trop de ressources pour l'infrastructure de base
  3. Xen et Fedora comme systèmes de base ; je préfère du 100% Debian... et de loin
  4. 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 ?


@+

:006:
**Simple Utilisateur** -- Debian stable - XFCE
Avatar de l’utilisateur
piratebab
Site Admin
Site Admin
Messages : 4905
Inscription : 24 avr. 2016, 18:41
Localisation : sud ouest
Status : Hors-ligne

Si le but est de réaliser un système très sécurisé, je doute fort que ce soit simple. Il suffit en effet d'une toute petite erreur, et toute la sécurité s'écroule.
Avatar de l’utilisateur
dezix
Membre hyper actif
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 ?
**Simple Utilisateur** -- Debian stable - XFCE
Avatar de l’utilisateur
piratebab
Site Admin
Site Admin
Messages : 4905
Inscription : 24 avr. 2016, 18:41
Localisation : sud ouest
Status : Hors-ligne

a priori docker car plus abordable pour débuter (plus de doc basique, de forums, .....)
Avatar de l’utilisateur
dezix
Membre hyper actif
Membre hyper actif
Messages : 3546
Inscription : 04 juin 2016, 14:50
Status : Hors-ligne

piratebab a écrit : 15 janv. 2021, 16:08 a priori docker car plus abordable pour débuter (plus de doc basique, de forums, .....)
Oui, je suis parti sur Docker :good:



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 :017:
**Simple Utilisateur** -- Debian stable - XFCE
Avatar de l’utilisateur
piratebab
Site Admin
Site Admin
Messages : 4905
Inscription : 24 avr. 2016, 18:41
Localisation : sud ouest
Status : Hors-ligne

Je ne maîtrise pas assez les conteneurs pour t'aider.
La sécurité des containers est un vaste sujet, qui à ma connaissance n'est pas encore réglé.
Répondre