Une raison pour chiffré /?

9

Je suis un grand fan de Linux et j'aime essayer de nouvelles distributions de temps en temps. J'ai généralement mes dossiers personnels et mes racines dans un lvm au-dessus d'une partition chiffrée, mais cela a tendance à devenir fastidieux, chaque processus de création d'initramfs étant plus étranger que le dernier.

J'apprécie la confidentialité, mais la plupart de mes informations précieuses ou personnelles sont stockées dans les dossiers d'accueil. De plus, j'ai partitionné en utilisant GPT, donc plusieurs partitions ne sont pas si difficiles à configurer même en dehors d'un lvm.

La question est donc la suivante: le cryptage racine et le niveau LVM de "/" en valent-ils la peine, en particulier avec tous les tracas de l'espace utilisateur avec lesquels je dois faire face?

lvm encryption root-filesystem nikitautiu
la source
2
Peut-être que j'aurais dû mentionner un échange. Je travaille sur un ordinateur portable, j'utilise donc souvent le swap-to-disk. C'est une fonctionnalité facilement exploitable à moins que la partition ne soit chiffrée et parce que le montage d'un tel échange est fait avant le montage root, cela signifie que je pourrais tout aussi bien monter le / aussi pendant que j'y suis.
nikitautiu

Réponses:

12

Tout d'abord, les problèmes liés à la racine cryptée et à l'espace utilisateur précoce sont généralement déjà gérés par votre distribution (pour autant que je sache, Fedora, Debian, Ubuntu et OpenSUSE prennent en charge la racine cryptée prête à l'emploi). Cela signifie que vous n'avez pas à vous soucier de la configuration elle-même.

L'une des raisons du chiffrement / est simplement de s'assurer que vous ne divulguez aucune information. Pensez aux programmes qui écrivent des données temporaires dans / tmp , des fichiers journaux contenant des informations sensibles comme le nom d'utilisateur / les mots de passe dans / var / log ou des fichiers de configuration contenant des informations d'identification comme un mot de passe dans / etc / fstab ou certaines commandes dans l'historique du shell de l'utilisateur root.

L'utilisation de LVM au lieu de partitions présente un grand avantage, vous pouvez facilement redimensionner / renommer / supprimer des volumes logiques sans avoir à re-partitionner votre disque lui-même, c'est juste plus pratique que d'utiliser des partitions (GPT ou MBR)

Ulrich Dangel
la source
Pour moi, LVM a toujours été une norme de facto, il offre tellement de flexibilité par rapport au partitionnement traditionnel, en particulier dans un environnement multi-boot. Aussi longtemps que j'ai déjà appris à utiliser les outils initramfs et mkinitcpio, je pourrais aussi bien apprendre tout autre outil ramfs qu'une distribution exotique a à offrir. : D
nikitautiu
1
@vitiv juste pour l'enregistrement initramfs-tools a une excellente intégration de cryptoroot, installez simplement cryptsetup, créez le / etc / crypttab approprié, ajustez / etc / fstab et vous avez terminé.
Ulrich Dangel
10

/etc, /varet /tmpvenez à l'esprit. Tous peuvent potentiellement avoir un contenu sensible. Tous peuvent avoir des volumes séparés, mais il est courant que chacun d'eux se trouve sur le même système de fichiers que le répertoire racine. Peut-être que vous en avez déplacé un ou plusieurs dans leurs propres volumes, mais les avez-vous tous déplacés?

  • /etc contient:

    • mots de passe hachés; éventuellement plusieurs sortes, telles que /etc/shadowet/etc/samba/smbpasswd

    • clés privées de toutes sortes: SSL, SSH, Kerberos ...

  • /var contient:

    • /var/log, dont beaucoup de contenus sont destinés à être en lecture seule par root car ils peuvent contenir des données sensibles; par exemple, /var/log/httpd/access_logpeuvent contenir des données GET qui sont des entrées non chiffrées par les utilisateurs d'un site Web, et peuvent donc être sensibles.

    • fichiers de base de données; MySQL stocke généralement ses fichiers de table et d'index dans /var/lib/mysql, par exemple

  • /tmpcontient des fichiers temporaires, qui peuvent ne pas sembler sensibles, mais il existe de nombreuses attaques contre le logiciel Unix qui impliquent des conditions de concurrence en raison de la possibilité de modifier ou de sniper un fichier temporaire pendant que le processus essaie de l'utiliser. Je sais que dans de nombreux cas, le contenu du fichier n'est sensible qu'à court terme (c'est-à-dire pas à travers un redémarrage) mais j'imagine que certains programmes peuvent dépendre de la façon dont les bits collants et mkstemp (3) se comportent pour mettre temporairement en cache les éléments sensibles de longue durée les données aussi.

Warren Young
la source
3
/ etc et / var sont un bon point. Quant à / tmp, il est presque toujours configuré en tmpfs.
nikitautiu
4

Une autre raison empêche la falsification du système de fichiers. Une fois crypté, il est beaucoup plus compliqué de faire quoi que ce soit qui pourrait vous mordre au prochain démarrage, par exemple en plaçant un rootkit sur votre système de fichiers (que ce soit en démarrant un CD live ou en déplaçant temporairement le disque dur vers une autre machine). Votre noyau (et initrd) sont toujours vulnérables, mais cela peut être atténué en utilisant soit un démarrage sécurisé (avec une chaîne de démarrage correctement signée) soit en démarrant à partir d'un périphérique amovible sûr (par exemple un lecteur flash ou une carte mémoire que vous avez sous contrôle). le temps).

peterph
la source
en effet, le chiffrement de / home est sans valeur si tous les binaires peuvent être falsifiés avant le prochain démarrage de l'utilisateur. je dirais que je serais la réponse la plus importante. / le cryptage domestique ne protège que contre le vol soudain
infinite-etcetera