Comment installer Ubuntu avec le chiffrement de disque ET la mise en cache SSD

10

J'utilise Ubuntu dans un environnement d'entreprise, et notre politique de sécurité stipule que nous devons utiliser le chiffrement complet du disque.

J'ai également un ordinateur portable avec un SSD mSATA de 32 Go et 750 Go de rouille en rotation. Mon installation actuelle utilise bcache pour en tirer parti, installée à l'aide de cette procédure . Cela offre une amélioration des performances très bienvenue sans que je doive me soucier de remplir le SSD.

Ce sera une question généreuse. La prime sera attribuée pour:

  • Une méthode claire et fiable pour effectuer une nouvelle installation d'Ubuntu
    • Toute version est acceptable, mais 15.04 (Vivid) ira bien
  • L'ensemble du système de fichiers sera crypté
    • La préférence ici est d'utiliser la case à cocher appropriée dans le programme d'installation d'Ubiquity par défaut (cryptage dm-crypt)
  • Le système de fichiers sera mis en cache sur un SSD
    • De préférence, la méthode du noyau dm-cache / lvmcache voir ici pour la méthode pour le faire avec Debian Jessie
    • Le cache doit également être sécurisé (c'est-à-dire crypté)
    • Il doit y avoir une explication claire pour expliquer pourquoi le cache est également crypté

J'ai déjà essayé la méthode pour Debian Jessie ci-dessus, mais elle refuse de démarrer pour moi. Ont pas encore essayé la méthode décrite dans les commentaires ici .

Les solutions publiées seront testées sur une machine virtuelle VirtualBox avec deux disques virtuels vierges et une copie de version du bureau 15.04 (version amd64). Bounty passe à la première solution que j'adopte pour réinstaller mon matériel réel.

Veuillez écrire votre solution comme si elle allait dans le wiki de la communauté.


J'ai attribué la prime - je pense qu'il existe encore un potentiel pour une solution "LUKS-on-LVM" qui combine la facilité de la réponse approuvée en n'ayant qu'un seul mot de passe, et en utilisant uniquement des composants de mappeur de périphériques.

Adrian
la source
D'après ce que je comprends, vous ne voulez pas utiliser lvmcache dans l'installation LVM par défaut sur LUKS ubuntu car le cache ne sera pas chiffré.
solsTiCe
@solsTiCe - je croyais que lvmcrypt, étant une belle couche facile au-dessus de dm-cache, devrait également être possible de se réconcilier avec LUKS (LUKS étant une autre chose de mappeur de périphériques, dm-crypt), il importe juste de quelle manière autour de vous superposez des choses
Adrian
Vous devez comprendre que la partition / boot devra très certainement être non chiffrée. bcache était incompatible avec grub sur Ubuntu 14.04 et je crois qu'il l'est toujours.
Adam Ryczkowski
@AdamRyczkowski Oui, j'ai maintenant cette configuration. C'est acceptable mais je préférerais une configuration LUKS.
Adrian
Je ne vois pas pourquoi LUKS exclurait bcache ... Ils ne dépendent pas les uns des autres et l'un peut heureusement s'asseoir l'un sur l'autre.
Adam Ryczkowski

Réponses:

7

LVM sur LUKS sur bcache

Ici, le jeu de poupée russe est un peu plus profond avec 3 piles / couches ...

Mon idée initiale à propos de cette question était d'utiliser une installation Ubuntu par défaut avec LVM sur LUKS et de la convertir en un périphérique de support bcache avec des blocs, mais cela n'a pas fonctionné pour moi lors de mon test avec LVM.

De plus, le programme d'installation ubuntu ( ubiquité ) est trop limité pour être installé à l'intérieur d'un périphérique bcache préparé à l'avance (au moins avec LUKS sur LVM), nous nous tournons donc vers une méthode pour faire les choses manuellement.

Démarrez dans le live CD / USB et choisissez "Try Ubuntu" et ouvrez un terminal

Pré-installation

sudo -i
# Define some variable to avoid confusion and error
luks_part=/dev/sda3
boot=/dev/sda2                    # boot partition
caching_bcache=/dev/sdb           # SSD or partition in SSD

# Do secure erase of encrypted backing and caching device (see Notes [1])
dd if=/dev/urandom of=$luks_part || dd if=/dev/urandom of=$caching_bcache
# Go and grab some coffe, this will take a while...

apt-get install bcache-tools
# Setup bcache caching and backing devices
make-bcache -C $caching_bcache -B $luks_part
# (Optional) Tweak bcache
echo writeback > /sys/block/bcache0/bcache/cache_mode

# Below we now create manually what ubiquity should have done for us
# Setup LUKS device on bcache device
cryptsetup --key-size 512 luksFormat /dev/bcache0
cryptsetup luksOpen /dev/bcache0 crypted

# Setup LVM on LUKS
# You can skip that part if you don't want to use a swap
# or don't want to use multiple partition. Use /dev/mapper/crypted
# as you root latter on
pvcreate  /dev/mapper/crypted
vgcreate vg /dev/mapper/crypted
lvcreate -L 1G vg -n swap
lvcreate -l 100%FREE vg -n root

Installation

Laissez le terminal ouvert et exécutez maintenant l'installation. Choisissez "autre chose" lors du partitionnement et spécifiez

  • votre partition de démarrage ( /dev/sda2)
  • votre partition racine ( /dev/mapper/vg-root)
  • votre échange ( /dev/mapper/vg-swap)

et cochez la case pour formater vos partitions

À la fin de l'installation, ne redémarrez pas mais cliquez simplement sur "Continuer d'essayer ubuntu"

Post-installation

Dans notre terminal ouvert

# Install bcache-tools to add bcache module to initramfs
mount /dev/mapper/vg-root /mnt
mount $boot /mnt/boot
mount -o bind /sys /mnt/sys
mount -o bind /proc /mnt/proc
mount -o bind /dev /mnt/dev
chroot /mnt
# To get apt-get running in the chroot
echo 'nameserver 8.8.8.8' > /run/resolvconf/resolv.conf
apt-get install bcache-tools

# Create /etc/crypttab to add crypted bcached partition
echo "crypted UUID=`blkid -o value /dev/bcache0|head -1` none luks" > /etc/crypttab

exit
sync
umount /mnt/sys
umount /mnt/proc
umount /mnt/dev
umount /mnt/boot
umount /mnt
vgchange -an /dev/mapper/crypted
cryptsetup luksClose crypted
sync

# Reboot & enjoy

Il existe un bogue de redémarrage Ubuntu 15.04 connu à partir de Live CD / USB, vous devrez donc forcer le redémarrage / l'arrêt

Vérifier

Une fois démarré, vous pouvez vérifier qu'il /dev/bcache0s'agit bien d'une partition LUKS avec

if sudo cryptsetup isLuks /dev/bcache0; then \
    echo "crypted";\
    else echo "unencrypted";\
fi

En effet, il s'agit du cache de votre partition LUKS, et vous accédez désormais à vos données via l'appareil /dev/bcache0et jamais à partir du périphérique de sauvegarde d'origine ( /dev/sda3ici)

Références

http://bcache.evilpiepirate.org/

https://wiki.archlinux.org/index.php/Bcache

https://wiki.archlinux.org/index.php/Dm-crypt

bcache-status n'est pas encore officiellement fusionné dans bcache-tools. Vous pouvez l'avoir ici: https://gist.github.com/djwong/6343451

[1] Il pourrait y avoir de meilleures façons de procéder à cet essuyage

solstice
la source
Assurez-vous d'exécuter update-initramfs -uk allaprès la création de crypttab et la exitcommande suivante .
dess
4

LVM sur LUKS + LUKS / dm-cache

Le programme d'installation d'Ubuntu utilise la configuration LVM sur LUKS pour son chiffrement complet du disque.

Si vous souhaitez également utiliser dm-cache / lvmcache pour augmenter les performances, vous devrez placer votre pool de cache dans un volume chiffré pour maintenir la sécurité de vos données.

Les étapes sont

  • Créer un volume LUKS sur le périphérique de bloc cible
  • Étendez le groupe de volumes par défaut avec le nouveau volume LUKS chiffré
  • Créez les métadonnées de cache et les volumes de données dans le nouveau volume LUKS
  • Liez-les ensemble en tant que pool de cache
  • Lier ce pool de cache au volume racine
  • Assurez-vous que le nouveau volume chiffré peut être monté au démarrage en l'ajoutant à /etc/crypttab
  • Assurez-vous que votre environnement de démarrage prend en charge dm-cache

Le script ci-dessous fournit un exemple et ajoutera un pool de cache chiffré à un système de fichiers racine existant. Il a été conçu pour les systèmes qui ont utilisé l'option de chiffrement de disque par défaut dans le programme d'installation d'Ubuntu - c'est-à-dire; disque entier partitionné et chiffré, pas de partitions personnalisées, etc.

Veuillez noter qu'il y a très peu de validation ou de programmation défensive dans ce script. Si cela détruit votre système de travail, c'est votre responsabilité.

Appelez ainsi:

# 1   2          3           4     5    6
sudo bash lvmcryptocache /dev/sdb 32M 1968M
  1. A besoin de root pour fonctionner
  2. exécuter le script en bash
  3. le nom du script
  4. le périphérique de bloc que vous souhaitez utiliser (testé uniquement avec le disque entier)
  5. la taille des métadonnées
  6. la taille des données du cache

Les paramètres de taille sont par défaut en Mo: vous aurez besoin d'un rapport de 1: 1000 d'espace de métadonnées à l'espace de cache (par exemple, si votre disque de cache fait 180 Go, vous avez besoin de 180 Mo d'espace de métadonnées et 179820 Mo d'espace de données - vous voudrez peut-être arrondir le les métadonnées montent un peu pour être prudent. Il y a une limite inférieure pour les métadonnées de 8M.)

Vous serez invité à entrer un mot de passe pour votre volume de cache - vous serez invité à entrer les mots de passe pour les DEUX de vos disques lors du démarrage.

Références


#! / bin / bash
#
# lvmcryptocache
#
# Ajoutez un pool de cache LVM et attachez-le au volume racine
# Y compris le cryptage LUKS
# Suppose que vous utilisez une configuration «tout sur root»
# Si ce n'est pas le cas, adaptez-le si vous le souhaitez
#
# Script sous licence GPL3 ou ultérieure
# © Adrian Wilkins mai 2015
#
# Transmettez le nom du périphérique de disque que vous utilisez comme cache
# Ceci devrait idéalement être totalement vide, alors exécutez
#
# dd if = / dev / zero of = / dev / $ {DISK}
#
# dessus pendant un court moment pour nuke la table de partition

CACHE_DISK = 1 $
META_SIZE = 2 $
DATA_SIZE = 3 $

DISK_NAME = $ (nom de base $ CACHE_DISK)

CRYPT_VOLUME = $ {DISK_NAME} _crypt
CACHE_PV = / dev / mapper / $ {CRYPT_VOLUME}

# Créer un volume LUKS sur un disque brut

cryptsetup luksFormat $ CACHE_DISK
cryptsetup open --type luks $ CACHE_DISK $ CRYPT_VOLUME

# A commencé à essayer de trouver des choses sur la taille du disque mais c'est complexe
# Essayez si vous le souhaitez, je continuais de manquer
#
# DISK_SIZE = $ (fdisk -l | grep "Disk $ {CACHE_DISK}" | awk '{print $ 5}')
# 
# META_SIZE = $ ((DISK_SIZE / 1000))
# META_SIZE = $ ((META_SIZE + 512))
# MOD = $ ((META_SIZE% 512))
# MOD_OFFSET = $ ((512 - MOD))
# META_SIZE = $ ((META_SIZE + 512)) 
# META_SIZE = $ ((META_SIZE + MOD_OFFSET))
# 
# DATA_SIZE = $ ((DISK_SIZE - META_SIZE))
# 

# Créer un nouveau PV à l'intérieur d'un volume chiffré

pvcreate $ CACHE_PV
vgextend ubuntu-vg $ CACHE_PV
lvcreate -L $ {META_SIZE} -n cachemeta ubuntu-vg $ CACHE_PV
lvcreate -L $ {DATA_SIZE} -n cachedata ubuntu-vg $ CACHE_PV
lvconvert --type cache-pool --poolmetadata ubuntu-vg / cachemeta --cachemode writethrough ubuntu-vg / cachedata --yes
lvconvert --type cache --cachepool ubuntu-vg / cachedata ubuntu-vg / root

# Ajoutez maintenant l'UUID du pool de cache PHYSICAL DRIVE (/ dev / sdb) à / etc / crypttab
DISK_UUID = $ (ls -al / dev / disk / by-uuid / | grep $ DISK_NAME | awk '{print $ 9}')
echo "$ {CRYPT_VOLUME} UUID = $ {DISK_UUID} aucun luks, jeter" >> / etc / crypttab

apt-get install --yes outils de provisionnement fin

CROCHET = $ (fichier temporaire)
# Ajoutez un script de hook à initramfs pour ajouter les bons outils et modules

echo "#! / bin / sh"> $ HOOK
echo "PREREQ =" lvm2 "" >> $ HOOK
echo "prereqs ()" >> $ HOOK
echo "{" >> $ HOOK
echo "echo \" $ PREREQ \ "" >> $ HOOK
echo "}" >> $ HOOK
echo "case $ 1 in" >> $ HOOK
echo "prereqs)" >> $ HOOK
echo "prérequis" >> $ HOOK
echo "exit 0" >> $ HOOK
écho " ;;" >> $ CROCHET
echo "esac" >> $ HOOK
echo "if [! -x / usr / sbin / cache_check]; then" >> $ HOOK
echo "exit 0" >> $ HOOK
echo "fi" >> $ HOOK
echo ". / usr / share / initramfs-tools / hook-functions" >> $ HOOK
echo "copy_exec / usr / sbin / cache_check" >> $ HOOK
echo "manual_add_modules dm_cache dm_cache_mq dm_persistent_data dm_bufio" >> $ HOOK

cp $ HOOK / etc / initramfs-tools / hooks / lvmcache
chmod + x / etc / initramfs-tools / hooks / lvmcache

echo "dm_cache" >> / etc / initramfs-tools / modules
echo "dm_cache_mq" >> / etc / initramfs-tools / modules
echo "dm_persistent_data" >> / etc / initramfs-tools / modules
echo "dm_bufio" >> / etc / initramfs-tools / modules

# Mettre à jour les initramfs

update-initramfs -u

echo Redémarrez maintenant!
Adrian
la source
1. Vous proposez de vider votre disque cache avec zéro, mais à la place, vous devez l'effacer en toute sécurité avec des données aléatoires si vous souhaitez y placer un LUKS chiffré. 2. Dans votre configuration, vous avez 2 partitions LUKS donc même si vous utilisez la même phrase secrète, vous devez la saisir deux fois, non?
solsTiCe
1. L'effacement aléatoire du disque est un peu dépassé sur le matériel moderne - les zéros sont suffisants pour placer le disque au-delà de la plupart des mesures de niveau non académique et certainement au-delà des laboratoires commerciaux de récupération de disque. À moins que le volume que vous utilisez ne détienne des données sensibles précédemment , il n'est pas nécessaire car tous les blocs qui y sont écrits seront cryptés; en raison des algorithmes de nivellement de l'usure, vous ne devriez pas du tout utiliser un SSD contenant des données sensibles en texte brut. 2. Oui, il y a 2 partitions LUKS, comme je le dis dans le texte, vous serez invité à saisir les deux phrases de passe lors du démarrage.
Adrian
l'essuyage aléatoire N'EST PAS pour supprimer en toute sécurité les données sur le SSD mais pour éviter un examen minutieux et être capable de distinguer les données cryptées du blanc comme 00000000zerazer000000000000. Ici, vous pouvez voir les données cryptées au milieu. cela affaiblit votre cryptage au lieu d'être caché au milieu d'une soupe aléatoire.
solsTiCe
J'ai fini par suivre cette route après avoir été bloqué en configurant bcache. On dirait que ça fonctionne assez bien: | cache_utilization_pct | 79.096846147 |. Cependant, topje vois constamment des états de 20 à 50%. Serait-ce un effet secondaire de la mise en mémoire tampon?
Jean Jordaan
Je ne peux pas vraiment prétendre le savoir - mais je suppose que cela pourrait être un effet secondaire des optimisations impliquées dans la réduction des écritures sur le SSD. Article sur IOWait ici: thattommyhall.com/2011/02/18/iops-linux-iostat
Adrian