Se défendre contre la femme de chambre maléfique, comment gérer la suppression de la partition / boot

Lorsque vous utilisez le chiffrement complet du disque LUKS, comment feriez-vous pour vous protéger contre les mauvaises servantes ?

L'attaque malveillante est lorsque quelqu'un obtient un accès physique à votre ordinateur pendant votre absence et compromet la partition non chiffrée / de démarrage pour capturer votre mot de passe FDE la prochaine fois que vous démarrez votre ordinateur

L'une des solutions consiste à laisser votre partition / boot sur une clé USB qui est toujours avec vous (la femme de chambre ne peut pas y accéder), mais quel système de fichiers dois-je utiliser dessus, et comment configurer mon système pour gérer correctement la suppression de la clé USB (et donc de la partition / boot elle-même)?

J'utilise CentOS, mais les réponses génériques et distro-agnostiques sont bien sûr les bienvenues. Merci.

Enfin compris. Cela semble toujours hacky et sale parce que le système ne sait jamais qui /bootne peut pas être monté et vous devrez le monter manuellement avant de faire quoi que ce soit qui pourrait y écrire (pensez aux mises à jour du système, etc.), mais à part cela, cela fonctionne parfaitement .

• préparez votre lecteur flash avec une seule partition avec le drapeau de démarrage défini dessus. Vous pouvez l'exécuter shred -n 1 -v /dev/sdXpour l'effacer complètement, y compris tous les secteurs de démarrage précédents; une fois cela fait, exécutez fdiskpour créer une partition et mkfsvotre système de fichiers de votre choix.
• montez votre lecteur flash quelque part, /mnt/bootou même /newbootfera très bien.
• passer de tout à partir /bootdu lecteur flash avec mv /boot/* /newboot.
• éditez votre /etc/fstabet changez l'UUID de la partition de démarrage d'origine (ou créez une entrée s'il n'y en a pas) pour correspondre à celle de votre lecteur flash. Vous pouvez obtenir l'UUID avec lsblk -o name,uuid. Ajoutez également l' noautooption pour que le disque ne soit pas monté automatiquement pour pouvoir le retirer dès que le système commence à démarrer (une fois le noyau chargé) sans risquer de corrompre le FS dessus.
• démontez la partition de démarrage d'origine et le lecteur flash ( umount /boot && umount /newboot) et montez le lecteur flash; si votre entrée fstab est correcte, vous pouvez simplement l'exécuter mount /bootet elle sera automatiquement montée en fonction de l'UUID spécifié dans le fstab.
• régénérez la configuration de votre chargeur de démarrage pour refléter les UUID et la position "physique" de la nouvelle partition, pour GRUB, le lecteur flash apparaîtra en fait comme le premier disque dur de l'ordinateur ( hd0). Si vous êtes d'accord avec l'utilisation des scripts de configuration GRUB par défaut fournis par la plupart des distributions, vous pouvez exécuter grub-mkconfig -o /path/to/grub.cfget cela générera le fichier en fonction des partitions actuellement montées et / ou de fstab. Notez que pour CentOS 7, le correct se grub.cfgtrouve réellement dans /boot/grub2/grub.cfg.

Lorsque vous effectuez une opération pouvant accéder à la partition de démarrage, connectez votre clé USB et exécutez mount /boot. Une fois cela fait, vous pouvez courir umount /boot. Notez que cette dernière commande peut prendre quelques instants car elle vide les tampons sur le disque (le disque lui-même est lent, donc le noyau tamponne certaines opérations d'écriture pour accélérer les choses).

Une autre approche de ce problème particulier consiste à utiliser le TPM pour stocker une clé de chiffrement, mais la défense dépend de l'utilisateur pour la rendre efficace. Une solution rudimentaire basée sur RHEL7 est tpm-luks ( https://github.com/GeisingerBTI/tpm-luks ).

La façon dont cela fonctionne est au démarrage, chaque étape du processus de démarrage mesure la suivante et stocke cette mesure dans les PCR sur le TPM. Une fois le processus de démarrage terminé, tpm-luks vérifie l'état des PCR par rapport à une configuration "bonne connue". Si dans une configuration "bonne connue", le TPM descellera la clé LUKS et tpm-luks transmettra ces données pour déverrouiller la partition LUKS racine.

Parce que tout ce qui est important est mesuré avec un hachage cryptographique, il n'y a essentiellement aucun moyen pour une femme de chambre maléfique de remplacer votre GRUB / kernel / ramdisk pour collecter de manière néfaste votre phrase secrète FDE. En prime, vous n'avez pas du tout besoin d'une phrase de passe FDE! Vous pouvez en théorie supprimer complètement la phrase secrète lisible par l'homme et vous fier entièrement aux tpm-luks, mais si vous suivez cette voie, c'est probablement une bonne idée de stocker votre en-tête LUKS et de le conserver en tant que sauvegarde.

Comme je l'ai mentionné, cela nécessite une certaine diligence de la part de l'utilisateur. Si vous avez laissé l'ordinateur sans surveillance et qu'une invite de phrase secrète vous est présentée, c'est probablement une mauvaise idée de le taper jusqu'à ce que vous ayez fait des recherches. À ce stade, vous devez démarrer dans un environnement de CD en direct et vérifier s'il y a un bogue dans tpm-luks ou si la /bootpartition a vraiment été modifiée. Vous laissez toujours la /bootpartition non chiffrée, mais si quelque chose d'important est modifié, le disque principal n'est jamais déchiffré.