[resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

debianux · 31-03-2017 09:25:54

Bonjour,

ici https://debian-facile.org/viewtopic.php?id=14461 est faite la synthèse de 'l'aventure' de l'installation de jessie-lvm-chiffré sur un lenovo-t-460s, en dual-boot-w10.

pour que ça marche, raleur a trouvé la solution d'ajouter, dans '/boot/grub/grub.cfg', 'cryptomount -a' juste avant chaque ligne 'insmod lvm', qui se trouvent dans le paragraphe '#10-linux'.

à chaque fois qu'est lancé 'update-grub', il faut refaire cette modification.

et c'est ce que je dois faire dans mes essais de modification du 'clavier-grub' et d'affichage d'écran.
et comme je 'patine', ça commence à faire beaucoup de 'cette modification'

y a-t-il un moyen pour lui expliquer, une bonne fois, qu'il lui faut l'intégrer ?

modification dans '/etc/default/grub' ?
'grub.d' ?

merci d'avance
cordialement
debianux

Dernière modification par debianux (01-04-2017 16:26:22)

kyodev · 31-03-2017 09:43:41

oui, grub.cfg est modifié à chaque fois par les scripts du répertoire /etc/grub.d/

il faut donc modifier un script 40_custom..., ou en créer un 42_...
voir:
https://debian-facile.org/doc:systeme:g … figuration

Dernière modification par kyodev (31-03-2017 09:44:22)

raleur · 31-03-2017 09:44:18

Essaie d'ajouter ça dans /etc/default/grub :

GRUB_ENABLE_CRYPTO=y

(attention à bien mettre "y" et pas "true" ou "1")

debianux · 31-03-2017 09:52:10

bonjour kyodev et raleur !
@raleur:
la position de cette ligne a-t-elle de l'importance ?

raleur · 31-03-2017 09:57:01

Non.

debianux · 31-03-2017 10:01:37

le fait de trouver dans 'grub.cfg' la ligne 'insmod cryptodisk' peut-elle signifier que 'la crypto' est déjà 'enabled' ?

cat /boot/grub/grub.cfg 

 

### BEGIN /etc/grub.d/10_linux ###

function gfxmode {

  set gfxpayload="${1}"

}

set linux_gfx_mode=

export linux_gfx_mode

menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-e93c7ebe-3451-4c97-a8b8-b63615738ace' {

  load_video

  insmod gzio

  if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi

  insmod part_gpt

  insmod cryptodisk

  insmod luks

  insmod gcry_rijndael

  insmod gcry_rijndael

  insmod gcry_sha1

        cryptomount -a

  insmod lvm

  insmod ext2

  set root='lvmid/dbbR8D-lHVU-qucD-ezm2-ZhZ5-R7l9-WuakkZ/e2Bp6z-PdPi-2CJ1-EjPr-vQjb-pNXZ-0S9KBq'

kyodev · 31-03-2017 10:16:55

grub.cfg est construit par les scripts, c'est un résultat FINAL
regarde le wiki, tu vas gagner du temps

raleur · 31-03-2017 10:31:39

debianux a écrit :

le fait de trouver dans 'grub.cfg' la ligne 'insmod cryptodisk' peut-elle signifier que 'la crypto' est déjà 'enabled' ?

Non, pas forcément. Le support de la crypto peut être incomplet. L'option ci-dessus est nécessaire lorsque /boot est chiffré.

debianux · 31-03-2017 10:32:38

@kyodev
d'une manière générale, je regarde et re-regarde le wiki, et pas que celui de df : malheureusement, je ne comprends pas tout, ce qui me conduit, tout penaud, à poser ce type de question

et si, de ton côté, ça te paraît limpide : ce 'résultat final' signifie-t-il que 'la crypto' est déjà 'enabled' ?

debianux · 31-03-2017 10:33:36

@raleur
merci !

raleur · 31-03-2017 10:34:15

kyodev a écrit :

il faut donc modifier un script 40_custom..., ou en créer un 42_

Rappel : c'est la sortie standard de l'exécution de chacun ces scripts qui est redirigée dans grub.cfg.
Question : comment fais-tu pour qu'un de ces scripts modifie ce qu'a écrit un autre script ?

kyodev · 31-03-2017 10:38:51

en mettant un nouvel ordre identique dans un script supérieur (exécuté après) comme 40_custom.. ou en créant un à partir de rien 45_zeMien par exemple
là ça cascade.

sinon il faut modifier directement LE script qui te convient pas, 30_os_prober, par exemple

j'ai pas cherché à comprendre l'utilité de la manoeuvre pour le moment, me contente de principe

si ça t'intéresse, j'en discutais hier, tout le wiki sur grub serait à modifier pour être plus conforme/simple/uptodate/...
y'a un chantier à lancer

en équipe si possible
ma bible:
https://www.gnu.org/software/grub/manual/grub.html

Dernière modification par kyodev (31-03-2017 10:43:15)

debianux · 31-03-2017 10:39:29

pas de 'cryptomount -a' à l'horizon :

cat /etc/default/grub

 

# If you change this file, run 'update-grub' afterwards to update

# /boot/grub/grub.cfg.

# For full documentation of the options in this file, see:

#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0

GRUB_TIMEOUT=5

GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`

GRUB_CMDLINE_LINUX_DEFAULT="quiet"

GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs

# This works with Linux (no patch required) and with any kernel that obtains

# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)

#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)

#GRUB_TERMINAL=console

# The resolution used on graphical terminal

# note that you can use only modes which your graphic card supports via VBE

# you can see them in real GRUB with the command `vbeinfo'

GRUB_GFXMODE=1920x1440x32

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux

#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries

#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start

#GRUB_INIT_TUNE="480 440 1"

#enable i915.preliminary_hw_support

#not required for post-4.3 kernel (2016-11-09: 3.16.0-4-amd64)      

#you won't get kernel mode-setting support and working 3D acceleration for 

# Skylake's HD Graphics" unless you enable i915 preliminary support

#GRUB_CMDLINE_LINUX_DEFAULT="quiet i915.preliminary_hw_support=1"

#essai d'automatisation de 'cryptomount -a'

GRUB_ENABLE_CRYPTO=y

après 'update-grub' :

cat /boot/grub/grub.cfg

 

### BEGIN /etc/grub.d/10_linux ###

function gfxmode {

  set gfxpayload="${1}"

}

set linux_gfx_mode=

export linux_gfx_mode

menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-e93c7ebe-3451-4c97-a8b8-b63615738ace' {

  load_video

  insmod gzio

  if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi

  insmod part_gpt

  insmod cryptodisk

  insmod luks

  insmod gcry_rijndael

  insmod gcry_rijndael

  insmod gcry_sha1

  insmod lvm

  insmod ext2

  set root='lvmid/dbbR8D-lHVU-qucD-ezm2-ZhZ5-R7l9-WuakkZ/e2Bp6z-PdPi-2CJ1-EjPr-vQjb-pNXZ-0S9KBq'

raleur · 31-03-2017 10:55:06

L'option marche (et est nécessaire) quand tout /boot est chiffré. Il faut qu'elle soit activée pour exécuter grub-install sans erreur dans cette configuration. Mais je n'ai pas regardé son effet sur le contenu de grub.cfg généré par update-grub. Comme le volume chiffré qui contient /boot est déverrouillé avant l'affichage du menu de GRUB, il n'est plus nécessaire de le déverrouiller par la suite.

Ton cas est différent puisque /boot est chiffré mais pas /boot/grub, ce qui ne nécessite donc pas d'ouvrir le volume chiffré pour afficher le menu de GRUB.

En tout cas je ne vois pas l'intérêt de charger les modules crypto si ce n'est pas pour ouvrir un volume chiffré. A mon avis c'est un bug du générateur de configuration de GRUB ou de ses scripts.

Dernière modification par raleur (31-03-2017 10:56:10)

kyodev · 31-03-2017 11:07:10

debianux a écrit :

'grub.cfg' la ligne 'insmod cryptodisk' peut

ça peut, ça n'apparait pas par défaut. donc je vois pas de bug potentiel des scripts
éventuellement un bug "bidouilleur"?

debianux · 01-04-2017 09:54:14

Bonjour,
@raleur
je crains d'être 'condamné' à 'cryptomount -a'-er à la main jusqu'à une nouvelle installation.

pour cette installation future, toujours en dual-boot-w10, pc-efi, lvm-chiffré, comment faudrait-il faire pour ne plus être confronté à cette étape ?

raleur · 01-04-2017 12:18:20

Désolé, je me suis trompé dans le nom de la variable à ajouter dans /etc/default/grub. Il s'agit de :

GRUB_ENABLE_CRYPTODISK=y

Avec cette définition, update-grub génère un fichier grub.cfg qui contient des commandes cryptomount pour ouvrir les volumes chiffrés nécessaires.

Et je maintiens que ça n'a pas de sens de générer des commandes insmod pour charger les modules crypto quand un volume est chiffré mais sans la commande cryptomount pour ouvrir le volume si la définition n'est pas présente.

raleur · 01-04-2017 12:51:40

Petites précisions :

- Avec GRUB_ENABLE_CRYPTODISK=y, il n'est plus nécessaire de séparer /boot/grub pour qu'il soit en clair à condition que "l'embarquage" de l'image principale de GRUB en dehors de /boot/grub soit possible.

- Lors de l'installation, on peut ajouter la ligne à /target/etc/default/grub via un shell de l'installateur après l'échec de l'installation de GRUB et recommencer l'installation de ce dernier qui va alors réussir, en incluant les modules crypto dans l'image principale de GRUB.

PS : En examinant un fichier grub.cfg généré avec GRUB_ENABLE_CRYPTODISK=y sur Jessie, je viens de découvrir que même dans les entrées de menu qui n'ont pas besoin d'ouvrir un volume chiffré (autres systèmes installés sans chiffrement) et pour lesquelles les commandes insmod chargeant les modules crypto sont absentes (ce qui est logique), il y a quand même une commande "cryptomount -u" (par UUID) mais sans UUID, ce qui provoque une erreur au démarrage et nécessite d'appuyer sur une touche pour continuer. Ce comportement est vraiment stupide, alors qu'il suffirait d'ajouter la commande cryptomount en même temps que les commandes insmod des modules crypto quand c'est nécessaire, et non quand GRUB_ENABLE_CRYPTODISK=y est présent.

Dernière modification par raleur (01-04-2017 12:52:22)

debianux · 01-04-2017 16:23:48

@raleur

Désolé, je me suis trompé

pas de quoi : il te sera très-beaucoup pardonné !
d'autant plus qu'avec la nouvelle 'formule', la passphrase est bien demandée après l'upgrade-grub
ça démarre comme avant, avec la double saisie de passphrase, mais le 'cryptomount -a' ne sera plus à rajouter après chaque upgrade-grub

je pense que je reviendrai interroger lors d'une prochaine installation...
merci encore !

raleur · 01-04-2017 20:22:05

debianux a écrit :

ça démarre comme avant, avec la double saisie de passphrase

Si la double saisie te gêne, il y a moyen de l'éviter.

debianux · 01-04-2017 21:48:31

toute ouie, je suis

raleur · 01-04-2017 22:50:26

Il y a un champ "key file" dans /etc/crypttab qui peut contenir le chemin d'un fichier contenant la passphrase d'un volume chiffré, évitant de devoir la taper. Mais voilà, il s'agit du volume chiffré qui contient la racine, et qui doit donc être ouvert par l'initramfs. Et le script de cryptsetup pour update-initramfs est un petit malin : il ignore les lignes qui contiennent un fichier key file. Fausse piste.

On peut en revanche utiliser l'option "keyscript". La valeur de cette option doit être un exécutable dont la sortie standard sera utilisée comme passphrase.

Il faut donc créer un script, par exemple /root/rootkey, contenant :

echo -n "passphrase"

(-n pour ne pas envoyer de caractère de fin de ligne qui serait considéré par cryptsetup comme faisant partie de la passphrase)
Avec chmod, ajouter à ce fichier la permission d'exécution à son propriétaire root, et supprimer toute permission pour les autres catégories.
Vérifier que l'exécution de ce script affiche la passphrase sans saut de ligne.
Dans /etc/crypttab, ajouter l'option keyscript à la suite de "luks" :

sdX_crypt UUID=xxxx none luks,keyscript=/root/rootkey

Regénérer l'initramfs avec update-initramfs -u.

Au démarrage suivant, la passphrase devrait être demandée par GRUB avant d'afficher le menu, mais pas par l'initramfs avant de monter la racine.

Commentaire :
Mais la passphrase est en clair dans un fichier texte ! Ce n'est pas sécurisé !
Tempérons.
Le fichier est en clair sur la racine et dans l'initramfs, mais ceux-ci sont dans un volume chiffré donc lisibles que lorsque le volume chiffré a déjà été ouvert avec la passphrase.
Une fois le volume ouvert, le fichier n'est lisible ou exécutable que par root. S'il y a des sudoers sur cette machine qui ne doivent pas connaître la passphrase, c'est effectivement un risque. Si tu fais une sauvegarde du système, la passphrase y sera en clair, à moins de l'exclure de la sauvegarde ou de chiffrer la sauvegarde aussi. Si un attaquant met la main sur la sauvegarde en clair, il n'a nul besoin de déchiffrer le disque puisqu'il a déjà accès à son contenu via la sauvegarde.

Tiens, j'ai envie d'élargir le débat sur le chiffrement.
Pourquoi veux-tu chiffrer ? Pour protéger les données en cas de perte ou de vol de la machine ? D'accord.
Pour protéger le système ? Le chiffrement n'est pas suffisant. GRUB n'est pas chiffré donc vulnérable, et tu lui donnes la passphrase. Si un attaquant a un accès physique à la machine et peut modifier GRUB à ton insu pour enregistrer la passphrase et venir la récupérer plus tard, c'est cuit.
Partant de là, j'irai même plus loin : il n'est pas très utile de chiffrer /boot qui ne contient aucune donnée sensible (dans ce cas on ne met pas la passphrase dans l'initramfs évidemment).

Dernière modification par raleur (01-04-2017 22:55:55)

debianux · 03-04-2017 11:01:41

Bonjour raleur !
merci pour cette synthèse

effectivement l'objectif est de protéger les données.

je suis arrivé au 'lvm chiffré' parce qu'il était proposé par l'installateur debian

je voulais du dual-boot (et même, si possible à l'avenir, du triple-boot en ajoutant ubuntu, à cause d'une appli métier) mais, sauf erreur, ce n'est pas une option de l'installateur debian : d'où le partitionnement 'manuel', en essayant de reproduire ce que j'avais fait sur une installation de version antérieure, sur un autre pc.

les données sont essentiellement entreposées dans un nas synology ds411, accessibles par un réseau local.

faut-il 'protéger le système' ?
j'espérais, naïvement

, que l'accès du pc étant supposé 'verrouillé', sans la passphrase, le pc est 'inexploitable', ce qui, si je comprends bien, n'est pas le cas.

s'en tenir à la protection des données ?

raleur · 03-04-2017 16:21:14

Il faut être conscient que le seul chiffrement du système n'apporte pas une protection absolue si la partie initiale du système qui n'est pas chiffrée n'est pas protégée contre les les interventions illicites (accès physique).

Voici un scénario d'attaque possible :
1) L'attaquant extrait le disque de ta machine, le monte sur une autre machine et modifie la partie initiale du système, celle qui demande la passphrase, pour enregistrer celle-ci en clair discrètement sur le disque et remet le disque en place. Ou bien il démarre ta machine avec un système live pour faire la modification.
2) Tu démarres ta machine et tapes la passphrase, que le chargeur modifié enregistre sur le disque.
3) L'attaquant revient récupérer le disque et lire la passphrase enregistrée en clair, avec laquelle il peut accéder aux données chiffrées.

debianux · 03-04-2017 18:16:27

oui, en effet...
quelle serait, à ton avis, la solution la plus simple et la plus efficace pour la protection des données, en gardant le principe du lvm ?

Debian-facile

#1 31-03-2017 09:25:54

[resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#2 31-03-2017 09:43:41

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#3 31-03-2017 09:44:18

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#4 31-03-2017 09:52:10

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#5 31-03-2017 09:57:01

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#6 31-03-2017 10:01:37

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#7 31-03-2017 10:16:55

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#8 31-03-2017 10:31:39

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#9 31-03-2017 10:32:38

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#10 31-03-2017 10:33:36

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#11 31-03-2017 10:34:15

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#12 31-03-2017 10:38:51

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#13 31-03-2017 10:39:29

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#14 31-03-2017 10:55:06

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#15 31-03-2017 11:07:10

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#16 01-04-2017 09:54:14

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#17 01-04-2017 12:18:20

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#18 01-04-2017 12:51:40

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#19 01-04-2017 16:23:48

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#20 01-04-2017 20:22:05

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#21 01-04-2017 21:48:31

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#22 01-04-2017 22:50:26

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#23 03-04-2017 11:01:41

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#24 03-04-2017 16:21:14

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

#25 03-04-2017 18:16:27

Re : [resolu] grub2, sur lvm-chiffré: GRUB_ENABLE_CRYPTODISK=y

Pied de page des forums