Dans mon article précédent C’est décidé, je retourne sous Linux, je me moquais gentiment sur le Windows livré sur mon nouveau pc (un Dell Vostro 3360, comme ça vous saurez tout). Après tant d’amusement trollesque, j’ai voulu installer un système Archlinux aux petits oignons qui me convenait. Comme je trouve que la ligne de commande reste le moyen le plus efficace et rapide de faire du peaufinage de système, on va en bouffer ! La procédure ci-dessous explique comment obtenir une installation d’Archlinux dans un conteneur LVM chiffré avec dm-crypt et LUKS (système et SWAP) avec l’activation de TRIM pour SSD et une utilisation de Enlightenment E17 comme windows manager.

Kwa ? G rien compri !

Voici ce dont on parle :

• Archlinux : mon coup de coeur dans les distributions de linux, les explications devraient pouvoir être adaptable à d’autres systèmes tant que vous avez un terminal à disposition.
• LVM : méthode de gestion de partitions non continues. On peut ajouter, supprimer, modifier les partitions un peu comme on veut, plus besoin de rester 3h devant GParted en priant le dieu Bécup.
• LUKS : norme de chiffrement par blocs, idéal sous linux pour chiffrer une partition (en opposition à par exemple à eCryptfs qui sert à chiffrer un dossier comme le propose Ubuntu avec le dossier home)
• dm-crypt : sous-système permettant de gérer le chiffrement LUKS (où se trouvent les clefs…) utilisé par le noyau Linux. Propose notamment cryptsetup que l’on utilise ici.
• SSD : nouvelle génération de disques remplaçant les vieux HDD. Plus rapides, silencieux, économes en énergie et surtout plus chers. Mon Vostro est équipé d’un SSD de 128GB (pas de HDD en hybride)
• TRIM : sur un HDD, lorsque l’on écrit là où se trouvaient des données « supprimées », on écrase l’ancienne valeur par la nouvelle. Avec un SSD, on doit d’abord supprimer le contenu du secteur puis écrire la nouvelle (perte de performances). TRIM permet d’indiquer au système lorsque l’on n’a plus besoin de certaines données, l’autorise à les supprimer et l’on gagner du temps pour la future réécriture. Une sorte de garbage collector. De par son mode de fonctionnement, TRIM rend aussi inefficace toute tentative de récupération de données en cas de rm mal placé.
• SWAP : espace du disque dédié à soulager la RAM lorsque celle-ci se retrouve surchargée. Il est nécessaire de la chiffrer pour éviter les fuites d’information (des mots de passe pouvant être chargé dans la RAM).
• E17 : window manager léger et hyper personnalisable (*tousse*opposé de GNOME*tousse*). Une version stable vient de sortir après 12 ans de développement. Au passage ne venez pas m’ennuyez sur le window manager vs desktop environment, on met un peu n’importe quoi dans les deux catégories et puis c’est moi qui décide ici, na !

Voici une image permettant de mieux comprendre ce que l’on va réaliser :

Le /boot est sur une petite partition séparée (on a besoin d’un certain nombre de modules pour déchiffrer la partition), le reste du système se trouvant dans une partition chiffrée. En déchiffrant cette partition, on ouvre un conteneur LVM. Cela permet d’avoir toutes les partitions chiffrées avec la même clef. Si l’on voulait chiffrer une seule partition (ou plusieurs avec des clefs différentes), l’on aurait fait le contraire (LUKS dans LVM). Dans mon cas, n’ayant qu’Archlinux sur un petit disque, j’ai préféré utiliser uniquement une SWAP et une partition pour le système. Libre à vous de diviser le conteur LVM en plus de parties pour un home séparé ou pour du multiboot.

La manipulation va donc permettre de chiffrer sa machine, cela ne rendra pas la machine invisible contre tout types d’attaque. Les implications exactes en termes de sécurité sont mentionnées dans la conclusion, lisez là bien avant de commencer toute manipulation si vous n’êtes pas certains de bien comprendre.

Préparation

Attention, cette procédure va écraser lamentablement vos précédentes données tel le scarabée rhumatisant sous la patte du vaillant hippopotame. Si vous voulez conserver une copie de votre disque, je vous conseille de suivre cette procédure. Suumitsu a donné une procédure permettant de convertir un disque en machine virtuelle. J’ai testé mais perso la machine virtuelle ne fonctionne pas chez moi (récup système qui échoue).

Créez un live CD ou USB, démarrez dessus jusqu’à obtenir un terminal utilisable (je passe cette étape, pour arch c’est ici que ça se passe, jusqu’au 2.2). Fait ? Maintenant on efface le tout. D’abord on met de l’aléatoire pour maximiser la sécurité (on ne peut pas différencier les données aléatoires des données chiffrées). Note : l’activation de TRIM réduit l’intérêt de cette manipulation, lisez la dernière section sur les limites pour vous faire une opinion. Si vous jugez cela inutile, passez cette étape (je la laisse sans être certain à 100% de ce que j’avance). Si vous avez un HDD, faites le.

Ouille pauvre disque, ça prend du temps (6 MB/s sur mon disque de 128GB, soit 6 heures, glups). C’est pas le mode le plus parano du monde mais ça suffit. Faire plusieurs réécritures a été montré comme superflu. En parlant de suppression efficace, n’utilisez pas non plus des outils comme shred en pensant bien effacer vos fichiers, c’est inefficace sur un SSD.

Partitions

On crée ensuite une nouvelle table de partition. J’ai utilisé cfdisk, c’est très facile et interactif, même pas besoin de lire la man page pour comprendre. Les partitions sont à définir selon vos gouts mais comme je vous le disais plus haut, je vais uniquement séparer /boot du reste. 200MB pour /boot sur sda1, le reste sur sda2.

Pour chiffrer sda2, on a plusieurs choix d’algorithmes, de modes de stockage de clef, etc. On peut par exemple utiliser une suite de bytes aléatoires qui sont stockés sur une clefs USB chiffrée avec GPG (not bad). Mais nous, on ne vise pas la top sécurité (trop contraignant je trouve), on va faire au plus simple : un mot de passe à entrer au boot. Lisez la man page ou ce wiki pour des variations. (désolé pour cet idiot de wordpress qui me remplace les doubles tiret par un caractère spécial)

On choisi un super mot de passe (que vous irez écrire sur un post-it collé à l’écran) et on confirme (n’oubliez pas les majuscules pour le « yes »).

Pour ouvrir le conteneur, on utilise la commande suivante (très important, c’est cette commande que vous allez utiliser si jamais vous crachez votre système et devez faire la réparation avec un live cd, notez la aussi sur le post-it) :

La partition est maintenant accessible à /dev/mapper/sda2_crypt (vous pouvez évidement choisir un autre nom).

La partition sda2_crypt va être convertie en Primary Volume LVM contenant la swap et /. Je conseille encore une fois la doc archlinux pour les variations mais dans mon cas :

Kevin attend patiemment que son algorithme de brute force trouve votre clef LUKS

Installation

Maintenant on peut continuer normalement l’installation comme n’importe quel système. Dans le cas d’Archlinux avec arch-chroot, il faut d’abord monter les partitions dans /mnt.

Dans le beginner’s guide d’archlinux, on peut reprendre au point 2.6. select a mirror. Les partitions montées étant déchiffrées, la génération du fichier fstab devrait donner les bons UUID.

Dans le cas de mon Dell Vostro 3360, le wifi était reconnu nativement mais pas ethernet, la faute à l’Atheros AR8161. J’ai expliqué la marche à suivre mais à ce jour (à adapter à sa version du noyau, deviendra compat-driver dès linux 3.7), les commandes sont :

Avant que vous ne redémarriez, il faut faire quelques modifications pour activer le déchiffrement et TRIM. Dans le fichier /etc/mkinitcpio.conf, on défini les modules à charger dans le noyau au démarrage. Voici ce qu’il faut dans notre cas :

sd_mod étant pour LVM, keymap pour charger la disposition du clavier que vous aurez spécifié dans /etc/vconsole.conf (attention, si pas présente, vous devrez déchiffrer votre partition en qwerty), encrypt pour LUKS, LVM2 pour LVM (inattendu je sais), resume pour sortir de l’hibernation et tout cela devant se trouver avant filesystems. Vous pouvez également faire un nettoyage ici en supprimant et déplaçant quelques modules. Je ne suis pas spécialiste de cette partie donc ne vais pas trop m’aventurer là dedans de peur de dire des conneries. Si ça vous intéresse Postblue en donne quelques unes (des optimisations, pas des conneries).

On régénère l’image à charger avec :

(ou autres paramètres en cas de noyau différent ou optimisation)

Pour indiquer à GRUB la marche à suivre, on va modifier le fichier /etc/default/grub à la ligne GRUB_CMDLINE_LINUX pour mettre :

N’oubliez pas de regénérer un nouveau fichier grub.cfg avec grub-mkconfig. Le allow-discards permettant d’activer TRIM. On va d’ailleurs également modifier le fichier /etc/fstab qui chez moi ressemble à ça :

J’avoue ne pas être certain à 100% des paramètres en dehors du discard, les nomachin permettant de réduire le nombre d’écriture nécessaire (mais peut poser des problèmes dans certains cas de figure). Lisez SSD Tuning For Linux ou Archlinux SSD pour plus d’info.

Démarrage et E17

J’ai choisi d’installer E17 comme environnement de bureau. C’est très léger et très personnalisable. Tellement personnalisable que je n’ai pas encore réussi à l’adapter complètement à mes envies mais je suis sur que ça arrivera (j’ai commencé à mettre une série d’astuces ici). Voila à quoi ça ressemble chez moi après installation.

Sobre et léger, moi j’aime ( fond d’écran)

Il suffit d’installer le paquet enlightenment17 pour obtenir le bureau ainsi que tous vos programmes favoris et légers pour les tâches voulues (connman pour la gestion du wifi, mirage pour les images, 7-zip pour les archives… à vous de voir). Comme pour n’importe quel environnement de bureau en somme.

Là par contre où une modification devient intéressante est la connexion automatique. Si l’on chiffre le disque, l’intérêt de demander le mot de passe de l’utilisateur directement après est diminué. L’optimisation vient de chez postblue qui la tient du wiki Archlinux. Connexion automatique sur votre utilisateur qui va lancer Enlightenment avec un exec enlightenment_start dans le fichier ~/.xinitrc.

Grâce à ces optimisations, sur mon Vostro, une fois le mot de passe LUKS entré, j’ai besoin de 3 secondes pour être sur un bureau prêt à l’utilisation, c’est moins que ce qu’il me fallait pour sortir d’hibernation sur mon ancienne machine !

Vérification TRIM

Alors là, pour être honnête, j’ai une incertitude. Cela a été le sujet d’une discussion sur les forums Archlinux (ici) sans arriver à de solution convenant tout le monde. De nombreux sites affirment que le flag « allow-discards » suffit à activer TRIM. On peut le vérifier ainsi :

Si on leur fait confiance (ce que j’ai envie de faire), cela devrait suffire.

Seulement « discard » indique que l’on active TRIM, pas que TRIM fonctionne (vous voyez la subtilité ?). Un test un peu plus sophistiqué est donné ici. Cela consiste en la création d’un fichier, regarder où il se trouve en mémoire, le supprimer et vérifier que le registre a bien été vidé (les commandes sont dans le lien). Cependant lors du test, je découvre que les secteurs en questions sont vides avant d’avoir supprimé le fichier.

Avec un peu de recherche, j’ai trouvé ce blog donnant une piste de réponse. Il faudrait en réalité faire une addition sur l’alignement des partitions pour obtenir la bonne valeur. J’ai réalisé l’exercice ici avec un résultat différent mais tout autant décevant : une série de bytes aléatoires dans le secteur calculé mais pas supprimés à la suppression du fichier. Erreur de calcul ? Non activation de TRIM ? Problème avec la couche d’abstraction LUKS+LVM ? Mystère. Si quelqu’un a plus d’idées, je suis sur que ça en intéressera certains.

Conclusion et limites du chiffrement

La sécurité obtenue n’est pas absolue mais est déjà très raisonnable. Chiffrer votre disque ne vous protègera pas complètement. Il n’y a pas de problèmes si vous perdez votre machine hors ligne (pas de logiciels types Prey donc, pas grave, je préfère) mais il existe des cas plus problématiques. Le fait d’entrer votre mot de passe signifie qu’un attaquant ayant accès à votre PC est potentiellement capable de modifier vos fichiers de boot pour y ajouter un keylogger par exemple. Le cas de la clef sur une clef USB diminue un peu ce risque mais est assez contraignant (à vous de voir votre besoin de sécurité).

L’activation de TRIM réduit également la sécurité. Lisez cet article par un développeur de cryptsetup pour comprendre le problème. En autorisant le système à vider tous les secteurs inutilisés, l’on va permettre la détection des secteurs utilisés et ceux qui ne le sont pas. C’est pour cela que j’affirmais plus haut que le remplissage du disque de random était sans doute inutile. Cela ne me pose pas de problème pour mon utilisation de la machine mais il faut le savoir.

Une fois la partition déchiffrée, LUKS ne sert plus à rien évidement. Le chiffrement ne vous protègera pas contre les failles de sécurité dans vos logiciels. Il est par exemple important de verrouiller votre machine en veille. Il n’est pas à ma connaissance possible d’accéder au contenu d’une machine verrouillée sans faire d’attaque physique (contenu de la RAM par ex), vous devriez donc être à l’abri des script-kiddies si vous n’avez pas laissé de failles grosse comme une maison (si vous voulez vous protégez contre des gouvernements, pensez qu’ils possèdent d’autres moyens d’obtenir les clefs que de pirater votre machine).

Au passage, je conseille vivement de ne pas choisir le même mot de passe pour LUKS et votre utilisateur. Il est beaucoup plus facile d’avoir un keylogger ou d’accéder aux hash de votre mot de passe lorsque votre machine fonctionne.

Bonus : détectez les modifications de /boot

Je disais plus haut que le problème sécurité le plus préoccupant avec cette configuration était qu’une manipulation offline pouvait tout foutre en l’air. Si l’attaquant arrive à bidouiller les fichiers dans /boot, il peut faire beaucoup ; même une clef présente sur une clef USB peut se faire enregistrer avec un script malveillant. Heureusement, une publication dans ct-magazine donne une solution : vérifier le hash du MBR et des fichiers une fois la partition déchiffrée (les hash sont chiffrés évidement). Si une modification est détectée, grosse alerte !

Téléchargez l’archive suivante 1203-146.zip par l’auteur de l’article ou ma version qui utilise sha256 plutôt que sha1 (qui, si toujours sécurisé aujourd’hui, risque de ne plus l’être très longtemps, surtout depuis cette nouvelle attaque), ajoute le fichier de config systemd, enlève un espace au début de chkboot.sh (plantait le lancement de systemd) et ajoute un fichier .desktop pour chkbook_user.sh. Si je suis pas trop sympa quand même !

Le script chkboot_user.sh utilise zenity pour les alertes. Veillez à ce qu’il soit installé. Démarrez ce script au démarrage de votre session. Cela peut se faire via l’interface graphique de window manager préféré ou en ajoutant un fichier .desktop (comme celui dans l’archive que je vous donne par exemple) dans le dossier ~/.config/autostart/. Dans le cas de E17, le dossier autostart n’est pas utilisé (juste pour GNOME, KDE et XFCE). À la place, placez le fichier .desktop dans ~/.local/share/applications/ et allez ensuite dans settings > apps > startup applications >
applications et activez l’application Chkboot.

Avec la liste des fichiers ayant changé de hash

Attention, le script chkboot.sh est à faire tourner à chaque modification du dossier /boot. Cela peut arriver souvent sous Archlinux (à chaque mise à jour du noyau ou de grub par exemple). Si vous trouvez cela trop contraignant, n’hésitez pas créer un alias type alias sysupdate="/usr/local/bin/chkboot_user.sh && yaourt -Syua && /usr/local/bin/chkboot.sh".

PS : j’ai commencé la rédaction de la page en français au sujet de LUKS sur le wiki archlinux.fr. N’hésitez pas à venir contribuer, c’est encore bien vide.

Original post of Martin T..Votez pour ce billet sur Planet Libre.