SECURITE GRUb: Mot de passe

Support Debian
#21

Essaie de t’exprimer de façon plus rigoureuse et explicite.
Qu’entends-tu par “base M$” et “enrober” ?

Si ton objectif est d’installer Debian avec LVM chiffré à côté d’un système Windows, il ne faut pas toucher aux partitions Windows, sinon ce dernier ne fonctionnerait plus. Il faut créer à côté une partition chiffrée contenant un volume physique (PV) LVM, ou bien une partition LVM (PV) non chiffrée contenant des volumes logiques chiffrés ou non. Dans tous les cas il faut une partition ou un volume logique non chiffré pour /boot car grub gère LVM mais pas le chiffrement.

#22

[quote=“PascalHambourg”]Essaie de t’exprimer de façon plus rigoureuse et explicite.
Qu’entends-tu par “base M$” et “enrober” ?

Si ton objectif est d’installer Debian avec LVM chiffré à côté d’un système Windows, il ne faut pas toucher aux partitions Windows, sinon ce dernier ne fonctionnerait plus. Il faut créer à côté une partition chiffrée contenant un volume physique (PV) LVM, ou bien une partition LVM (PV) non chiffrée contenant des volumes logiques chiffrés ou non. Dans tous les cas il faut une partition ou un volume logique non chiffré pour /boot car grub gère LVM mais pas le chiffrement.[/quote]

Par enrobé je veux dire que LVM2 crée une partition cryptée en y incluant les deux partitions (m$ et Debian) mais apparemment au vu de ce que tu me dis ce n’est pas possible.

Mon Fdisk -l est [code]invite@debian:~$ sudo fdisk -l

Disque /dev/sda : 160.0 Go, 160041885696 octets
255 têtes, 63 secteurs/piste, 19457 cylindres, total 312581808 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d’E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x00047255

Périphérique Amorce Début Fin Blocs Id Système
/dev/sda1 * 63 156282879 78141408+ 7 HPFS/NTFS/exFAT
/dev/sda2 156284926 312580095 78147585 5 Étendue
/dev/sda5 156284928 175814655 9764864 83 Linux
/dev/sda6 175816704 181383167 2783232 82 partition d’échange Linux / Solaris
/dev/sda7 181385216 312580095 65597440 83 Linux

Disque /dev/sdb : 8166 Mo, 8166703104 octets
252 têtes, 62 secteurs/piste, 1020 cylindres, total 15950592 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d’E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0xa277032c

Périphérique Amorce Début Fin Blocs Id Système
/dev/sdb1 * 63 15936479 7968208+ b W95 FAT32
/dev/sdb2 15936480 15936542 31+ 21 Inconnu
[/code]

je suppose qu’il n’est pas possible de créer la partition lvm cryptée à postériori, ai je raison?

ps: j’examine cela linux.developpez.com/lvm/

#23

A lire cela, j’ai l’impression que tu n’as pas une idée claire du principe de fonctionnement de LVM (qui est très simple).

Ça dépend de ce que tu entends par “créer a posteriori”. Si tu veux dire transformer les partitions classiques en volumes logiques LVM et/ou chiffrés sans perdre les données, alors non ce n’est pas possible sans tout sauvegarder, recréer les partitions et volumes et restaurer les données. Mais seulement pour les partitions Linux, puisque Windows ne peut pas utiliser le LVM ou le chiffrement de Linux.

#24

Oui j’ai compris au vu de cela Partition(s) de disque |----> Volume Group |----> Logicals Volumes |----> système de fichiers

#25

Bonjour/soir,

désolé de remonter le topic (il est marqué comme Récent, mais février ça commence à dater).

J’ai voulu essayer la même chose (protéger l’accès aux items de Grub par mot de passe) sur Jessie, il y a peu de temps. Comme il a été dit, c’est bien en éditant /etc/grub.d/40_custom (ou en créant un autre fichier custom entre 41 et 49), et en exécutant update-grub pour que ces modifications soient inscrites dans /boot/grub.cfg

Bon à savoir: Dans Grub, le clavier est en QWERTY par défaut. Je n’ai pas cherché davantage pour savoir comment le passer en AZERTY, mais résultat: je me suis retrouvé avec un système “imbootable” (la phrase de passe était un poil trop complexe pour que je la tape en imaginant un clavier QWERTY, surtout qu’il n’y a pas de Backspace ni de Delete).

Pour réparer cela sans s’embêter avec un chroot, il est plus rapide de booter sur un live CD/USB et d’aller éditer manuellement /boot/grub.cfg (pas très élégant mais ça marche).

Morale de l’histoire , selon moi Grub 2 n’est pas vraiment conçu pour assurer la protection des données (peu pratique), et je rejoins l’avis énoncé plus haut selon lequel le chiffrement des partitions / et /home est bien plus adapté (certes, /boot ne sera pas chiffré, mais il ne contient pas d’informations sensibles).

#26

A l’impossible nul n’est tenu. Le chargeur d’amorçage n’est qu’un maillon de la chaîne, il est vain de le sécuriser si les autres maillons (firmware, OS) ne le sont pas.

La mise en place d’un mot de passé dans GRUB n’a de sens que si on sécurise aussi l’amorçage par le firmware (BIOS, UEFI) : mise en place d’un mot de passe pour la modification des paramètres, amorçage des supports amovibles désactivé ou restreint par mot de passe.

La configuration du firmware est elle-même vaine si un accès physique est possible et permet de réinitialiser les paramètres de sécurité (clear CMOS).

Et bien entendu, le chiffrement est indispensable (mais pas suffisant) pour empêcher l’accès au système et aux données si un accès physique au disque est possible.

#27

Je suis bien d’accord, ce n’est pas le rôle de Grub.
C’est plutôt celui du chiffrement des partitions (cryptsetup dispose d’ailleurs d’options intéressantes, comme l’utilisation d’une clé située sur un média amovible: un fichier de 1024 bits tirés de /dev/urandom et placé sur une clé USB elle-même chiffrée par mot de passe, par exemple, c’est pas mal). Et protéger le BIOS par mot de passe est aussi une bonne idée.

C’est vrai. Attention aux cold boot attacks sur la RAM, aux ondes électro magnétiques générées par le matériel, etc (vaste sujet !). Mais heureusement, on parle là d’attaques qui nécessitent des moyens techniques considérables.