Défendre contre la méchante servante, comment gérer l'enlèvement de la partition / boot

Finalement compris. Cela semble encore très hacky et sale car le système ne sait jamais que /boot ne 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.) fonctionne parfaitement.

• préparez votre lecteur flash avec une seule partition avec le drapeau de démarrage défini dessus. Vous pouvez exécuter shred -n 1 -v /dev/sdX pour l'effacer complètement, y compris les précédents secteurs d'amorçage; Une fois cela fait, exécutez fdisk pour créer une partition et mkfs votre système de files de choix dessus.
• monter votre lecteur flash quelque part, /mnt/boot ou même /newboot fera très bien.
• déplacer sur tout de /boot sur le lecteur flash avec mv /boot/* /newboot .
• éditez votre /etc/fstab et changez l'UUID de la partition de démarrage d'origine (ou créez une input s'il n'y en a pas) correspondant à celui de votre lecteur flash. Vous pouvez get l'UUID avec le lsblk -o name,uuid . Ajoutez également l'option noauto pour que le lecteur ne soit pas monté automatiquement pour pouvoir le retirer dès que le système démarre (une fois le kernel chargé) sans risquer d'endommager le FS.
• démonter la partition de démarrage d'origine et le lecteur flash ( umount /boot && umount /newboot ) et monter le lecteur flash; si votre input fstab est correcte, vous pouvez simplement exécuter mount /boot et le monter automatiquement en fonction de l'UUID spécifié dans le fstab.
• régénérer la configuration de votre bootloader pour refléter les UUIDs et la position "physique" de la nouvelle partition. Pour GRUB, le lecteur flash apparaîtra comme le premier disque dur de l'ordinateur ( hd0 ). Si vous êtes d'accord pour utiliser les scripts de configuration GRUB par défaut fournis par la plupart des dissortingbutions, vous pouvez exécuter grub-mkconfig -o /path/to/grub.cfg et générer le file en fonction des partitions actuellement montées et / ou du fstab . Notez que pour CentOS 7, le grub.cfg correct se trouve dans /boot/grub2/grub.cfg .

Lorsque vous effectuez une opération qui peut accéder à la partition de démarrage, connectez votre key USB et exécutez mount /boot . Une fois terminé, vous pouvez exécuter umount /boot . Notez que cette dernière command peut prendre quelques instants car elle vide les buffers sur le disque (le disque lui-même est lent, le kernel tamponnant certaines opérations d'écriture pour accélérer les choses).

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

La façon dont il fonctionne est au démarrage, chaque étape du process de démarrage mesure la suivante et stocke cette mesure dans les RAP du TPM. Une fois le process de démarrage terminé, tpm-luks vérifie l'état des PCR par rapport à une configuration "bien connue". Si dans une configuration "bien connue", le TPM va ouvrir la key 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 crpytographique, il n'y a essentiellement aucun moyen pour une bonne demoiselle de replace votre GRUB / kernel / ramdisk pour collecter de façon néfaste votre phrase secrète FDE. En prime, vous n'avez pas besoin d'une phrase secrète FDE! En théorie, vous pouvez supprimer complètement la phrase secrète lisible par l'user et vous reposer entièrement sur le tpm-luks, mais si vous utilisez cette route, il est probablement préférable 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 sur l'user. Si vous avez laissé l'ordinateur sans surveillance et que vous recevez une invite de mot de passe, il est probablement une mauvaise idée de le taper jusqu'à ce que vous ayez fait certaines searchs. À ce stade, vous devez démarrer dans un environnement Live CD et vérifier s'il y a un bogue dans tpm-luks, ou si la partition /boot été réellement modifiée. Vous quittez toujours la partition /boot non chiffrée, mais si quelque chose d'important est altéré, le disque principal n'est jamais décrypté.