Introduction
L’utilisation de disques chiffrés est de plus en plus courante. L’idée est de protéger par chiffrement les données d’un ordinateur pour éviter sa compromission ou son accès par des tiers.
Cependant ce n’est valable que pour des accès matériels (on extrait le disque dur pour le brancher sur un autre ordinateur pour essayer de lire les données), ou si l’ordinateur est arrêté.
Car si celui-ci est démarré, les données sont déchiffrées. Alors, tout accès à la machine avec des droits suffisants permet de lire les données. Cet accès peut tout aussi bien être la compromission d’un autre utilisateur profitant de droits d’accès mal configurés, ou ayant accès à la commande sudo (sudo est un risque majeur sur toute machine utilisée par plus d’un utilisateur)ou même du superuser root.
Dans ce cas, que faire pour éviter que ses données soient accessibles?
Un volume chiffré, sur une autre partition, ou un autre disque
Une solution consiste à mettre ses données sur un disque externe chiffré. Son utilisation est simple, une fois une session établie, il suffira d’« ouvrir le volume (c’est à dire déchiffrer le disque et créer ainsi le mapper) puis de monter le mapper ainsi créé. Des outils peuvent le faire automatiquement (zulucrypt/zulumount, mais aussi certains explorateurs de fichiers comme Nautilus et autres).
Là aussi il faut être très prudent. En effet, les outils peuvent sauvegarder les clefs de chiffrement localement. Il est alors critique de pouvoir protéger ces sauvegardes locales.
On peut aussi utiliser une autre partition sur la machine que l’on utilise comme le disque externe, avec de meilleures performances. Cependant, l’accès au compte de l’utilisateur peut compromettre tout autant l’accès.
Malheureusement la plupart de ces outils (navigateurs compris) ne sont pas très efficace pour la conservation des mots de passe. Il faut alors utiliser un coffre-fort de mot de passe.
Mais si on ne veux pas utiliser un disque externe, soit parce que ce n’est pas pratique, ou tout simplement parce que les performances ne sont pas terrible, il existe une autre solution.
L’environnement utilisateur chiffré
Il est possible de faire en sorte que la partition chiffrée englobe intégralement tout l’environnement de l’utilisateur. Cette partition est montée automatiquement à l’ouverture de session de l’utilisateur.
ATTENTION : ici il ne s’agit pas d’un montage réalisé après l’authentification mais inclus dans l’authentification. Car quand on ouvre sa session, il y a d’abord l’authentification PAM, puis via systemd la création des process de la session. Et si Nautilus monte votre partition chiffrée ce sera alors après ces processus qu’il le fera, et parce qu’il a enregistré la clef de chiffrement. Cela implique qu’une partie de votre environnement ne soit pas chiffré.
Dans le cas présent, la clef de chiffrement n’est autre que le mot de passe de l’utilisateur. Il faut donc impérativement avoir un mot de passe fort.
Le processus lors de l’ouverture de la session est le suivant :
- Authentification
- Ouverture de la partition chiffrée et création du mapper
- Création du point de montage
- Montage du mapper
- Systemd créé les processus de la session
Libpam-mount
Introduction
La gestion des accès privilégiés (PAM : Privileged Access Management ) est une stratégie de cybersécurité qui contrôle et surveille l’accès aux comptes privilégiés au sein d’une organisation, en veillant à ce que seuls les utilisateurs autorisés aient des autorisations élevées. Il aide à protéger les données et systèmes sensibles contre l’accès non autorisé et les violations potentielles de la sécurité.
Libpam-mount est un module qui permet de gérer les montages de partition en fonction de cette gestion des accès pour des utilisateurs.
Ce module est destiné aux environnements avec des serveurs de fichiers centraux qu’un utilisateur souhaite monter lors de la connexion et démonter lors de la déconnexion, tels que les stations (semi-) sans disque où de nombreux utilisateurs peuvent se connecter et où le montage statique de l’ensemble /home à partir d’un serveur présente un risque pour la sécurité, ou lister tous les volumes possibles dans /etc/fstab n’est pas faisable.
- Les utilisateurs peuvent définir leur propre liste de volumes sans avoir à modifier (éventuellement non inscriptible) les fichiers de configuration globale.
- Fonctionnalité de connexion unique — l’utilisateur doit taper le mot de passe une seule fois
- Processus de montage transparent
- Pas de mots de passe stockés
- Les volumes sont démontés lors de la déconnexion, libérant les ressources du système et ne laissant pas les données exposées.
Le module prend également en charge le montage de systèmes de fichiers locaux de tout type que l’utilitaire de montage normal supporte, avec du code supplémentaire pour s’assurer que certains volumes sont correctement configurés car ils nécessitent souvent plus qu’un simple appel de montage, tels que des volumes cryptés. Cela inclut SMB/CIFS, NCP, FUSE, dm-crypt et LUKS.
Source : j.eng's site: pam_mount
Plusieurs intérêts :
- Le point de montage de l’utilisateur n’est pas visible, car il n’existe pas tant que l’utilisateur n’est pas connecté
- Le cas échéant, suivant la normalisation utilisée, un listing des partition ne permet pas de savoir quelle est la partition de l’utilisateur (sur un système avec plusieurs partitions non montées automatiquement)
- Rien n’apparaît dans /etc/fstab
- Si l’utilisateur est en veille ou en hibernation, la partition est de nouveau chiffrée (non testé encore). Les données ne sont donc accessible que si l’utilisateur est connecté et actif.
- La fonctionnalité marche aussi pour une connexion SSH.
- Last but not least: tout l’environnement de l’utilisateur est ainsi chiffré.
Comment mettre en place libpam-mount
Environnement de déploiement
L’environnement utilisé pour faire ce tutoriel est le suivant :
- Machine virtuelle Virtualbox 4Go RAM et 4 processeurs, UEFI avec TPM2+Secure Boot
- Deux disques NVME de 50Go
- Système d’exploitation Debian 13 Trixie
- Partitionné en LVM sur LUKS, avec une partition /home minimale comme dans le schéma ci-dessous :
L’utilisateur user1 sera celui qui nous intéresse dans ce dossier.
Avec lsblk :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sr0 11:0 1 3,8G 0 rom
nvme0n1 259:0 0 50G 0 disk
└─Luks1_crypt 254:1 0 50G 0 crypt
└─vg-home 254:5 0 10G 0 lvm /home
nvme0n2 259:1 0 50G 0 disk
├─nvme0n2p1 259:2 0 953M 0 part /boot/efi
└─nvme0n2p2 259:3 0 49,1G 0 part
└─Luks2_crypt 254:0 0 49,1G 0 crypt
├─vg-swap 254:2 0 11,9G 0 lvm [SWAP]
├─vg-boot 254:3 0 952M 0 lvm /boot
├─vg-root 254:4 0 10,1G 0 lvm /
├─vg-home 254:5 0 10G 0 lvm /home
├─vg-var 254:6 0 10,1G 0 lvm /var
├─vg-var_log 254:7 0 4G 0 lvm /var/log
├─vg-var_log_audit 254:8 0 4G 0 lvm /var/log/audit
├─vg-var_tmp 254:9 0 2G 0 lvm /var/tmp
└─vg-tmp 254:10 0 2G 0 lvm /tmp
- La seule partition non chiffrée est /boot/efi
- Le bootloader est systemd-boot, j’ai supprimé GRUB de mes installations du fait de son incapacité chronique à gérer certain type de configuration, dont en particulier les disques chiffrés (tout particulièrement, il ne sait pas utiliser correctement le pbkdf Argon2id).
Installation
L’installation de libpam-mount est simple
apt install -y libpam-mount hxtools
Pour permettre l’utilisation de ofl (très important pour la gestion du démontage de la partition), il faut installer hxtools.
Lors de l’installtion :
- les différents fichiers pam.d vont être complétés.
- Le fichier /etc/security/pam_mount.conf.xml est créé
Configuration
Introduction
Il y a plusieurs étapes :
- Créer la partition chiffrée de l’utilisateur
- Ouvrir la partition chiffré formatée en ext4
- Créer l’utilisateur
- Monter le mapper sur /home/user1
- Copier les fichiers /etc/skel nécessaires comme pour n’importe quel autre utilisateur
- Donner la propriété du répertoire à l’utilisateur
- Ajouter la configuration nécessaire à /etc/security/pam_mount.conf.xml
- Démonter le mapper, clore le mapper, supprimer le point de montage
- Tester en ouvrant la session
Création de la partitions
La partition se créée comme n’importe quelle partition chiffrée :
- Création de la partition LVM :
lvcreate -L 20G -n user1 vg
- Chiffrement de la partition ainsi crée :
cryptsetup luksFormat --label USER1 --cipher=serpent-xts-plain64 --hash=SHA512 --pbkdf=argon2id /dev/mapper/vg-user1
Le label n’est pas obligatoire. Le chiffrement utilisé est serpent avec xts-plain64, avec un hash SHA à 512 bits, le pbkdf est Argon2id (qui est normalement par défaut, mais il est toujours préférable de le préciser).
3. Ouverture de la partition chiffrée :
cryptsetup luksOpen /dev/vg/user1 user1_crypt
- Formatage de la partition :
mkfs.ext4 /dev/mapper/user1_crypt
Création de l’utilisateur et préparation de son environnement
L’utilisateur est créé avec useradd comme n’importe quel utilisateur, avec un détail précis son mot de passe est la clef de chiffrement de la partition chiffrée !! .
- Il faut créer un groupe spécifique : pmusers (ou tout autre nom que vous voulez). Ce groupe est important. En effet, seuls les utilisateurs membres de ce groupe pourront utiliser le montage pam_mount. Pour le créer :
groupadd pmusers
- Créer l’utilisateur :
useradd -G audio,cdrom,dip,netdev,plugdev,pmusers,sudo,sshgroup,sugroup,users,video -c "Mon User1" -d /home/user1 -M -s /bin/bash user1
Les autres groupes d’appartenances définis par l’option -G sont les groupes que j’utilise pour mes utilisateurs.
ATTENTION : Si pmusers n’est pas créé, la commande échouera.
3. Mettre à jour le mot de passe
passwd user1
- Récuperer l’uid et le gid de l’utilisateur :
uid=`id $user | sed -E 's/uid=([0-9]*)\(.*/\1/g'`
gid=`id $user | sed -E 's/.*gid=([0-9]*)\(.*/\1/g'`
- Monter la partition sur /home/user1 avec création automatique du point de montage et gestion des droits (en utilisant les options X-mount.*) :
mount -t ext4 -o X-mount.owner=$uid,X-mount.group=$uid,X-mount.mode=0750,X-mount.mkdir /dev/mapper/user1_crypt /home/user1
- Copier les fichiers de base :
cp -rv /etc/skel/.* /home/user1/
cp -rv /etc/skel/* /home/user1/
Paramétrages de pam_mount
PAM.D
Lors des tests, le démontage et la fermeture de la partition ont posé des problèmes. En effet, la partie systemd de l’utilisateur reste active. Ce qui bloque la fermeture du mapper de la partition chiffrée ; et ce, quelque soit la configuration dans pam_mount.conf.xml.
La seule solution que j’ai trouvé est d’inverser l’ordre des pam_mount.so et systemd.so dans /etc/pam.d/common-session comme ci-dessous :
# and here are more per-package modules (the "Additional" block)
session required pam_unix.so
session optional pam_systemd.so
session optional pam_mount.so
# end of pam-auth-update config
/etc/security/pam_mount.conf.xml
C’est un fichier de type XML. Il faut donc bien faire attention à l’ouverture et surtout à la fermeture des balises.
- Debug : pour des raisons de traçabilité, j’ai activé le debug :
<debug enable="1" />
Une fois en production normale, il n’est pas nécessaire de le laisser.
- Définition des volumes : c’est dans cette partie que vous allez définir les volumes à monter pour vos utilisateurs. J’ai choisi de faire des volumes génériques pour tous mes utilisateurs :
- Un volume pour le mapper
- Un volume pour le montage du mapper
Si vous voulez faire un montage spécifique à un utilisateur, il faudra spécifier dans la définition du montage le nom de l’utilisateur.
J’utilise les options suivantes :
- sgrp : seuls les membres du groupe pourront utiliser ce volume.
- fstype : filesystem du volume (crypt pour la partie chiffrée, ext4 pour le mapper).
- path : Le device du volume à monter.
- mountpoint : le point de montage (mapper pour la partie chifrée, que j’ai définie comme le login de l’utilisateur suivit de _crypt). La valeur « ~ » correspond à la définition standard : /home/user.
-
options : les options de mount supplémentaires le cas échéant (pour le montage ext4)
Je vous renvoie aux documentation de mount, umount et pam_mount.conf pour les détails.
Ce nous donne les deux volumes suivants (le premier pour l’ouverture de la partition chiffrée, le second pour le montage du mapper ainsi créé) :
<volume sgrp="pmusers" fstype="crypt" path="/dev/mapper/vg151-%(USER)" mountpoint="%(USER)_crypt" />
<volume sgrp="pmusers" fstype="ext4" path="/dev/mapper/%(USER)_crypt" mountpoint="~" options="fsck,relatime" />
J’utilise pleinement la variable définie par pam_mount :%(USER) qui correspond au login de l’utilisateur qui se connecte
- Ensuite j’ai redéfini les commandes de montage/démontage et d’ouverture/fermeture ; ceci afin de m’assurer qu’elles soient bien en adéquation avec mon système et les options voulues.
En effet, j’utilise les options X-mount qui me permettent de m’assurer que le montage soit bien la propriété de l’utilisateur et qu’il ait bien les droits nécessaires. C’est le seul moyen qui permette de le faire. Sinon, le montage est fait sous root, et donc ne fonctionne pas.
Les redéfinitions sont les suivantes :
<lclmount>mount -t %(FSTYPE) -o X-mount.owner=%(USERUID),X-mount.group=%(USERGID),X-mount.mode=0750 %(VOLUME) %(MNTPT)</lclmount>
Le montage utilise les options pam_mount : %(FSTYPE),%(USERUID),%(USERGID),%(VOLUME), %(MNTPT).
Je n’ai pas utilisé l’option X-mount.mkdir qui permet de créer le point de montage automatiquement avec la commande mount, car pam_mount a son propre mécanisme.
<umount> umount -f --lazy %(MNTPT) /run/user/%(USERUID)</umount>
les options -f et –lazy obligent le système à démonter la partition même si des liens lui sont encore liés (au sens de lsof)
<cryptmount>cryptsetup luksOpen %(VOLUME) %(MNTPT)</cryptmount>
<cryptumount>cryptsetup --debug luksClose %(MNTPT)</cryptumount>
L’option –debug peut être retirée.
- Précision sur les options. J’ai conservé les options autorisées, mais j’ai ajouté une définition pour interdire l’utilisation de setui et dev pour les partitions utilisateurs pour des raisons de sécurité/durcissement du système.
<mntoptions deny="suid,dev" />
- Gestion du logout :
Pour la fin de session de l’utilisateur, pam_mount va attendre un peu que systemd s’arrête, et fermer d’autorité tout ce qui est hup, terminaux et tuer le reste des processus liés à l’utilisateur :
<logout wait="5000" hup="yes" term="yes" kill="yes" />
- Gestion du point de montage :
Le point de montage est créé si nécessaire (enable) et supprimé ensuite (remove). Attention, il n’est pas supprimé si celui-ci n’a pas été créé en premier lieu :
<mkmountpoint enable="1" remove="true" />
Fin de configurations
Maintenant, la partition utilisateur peut être démontée, le point de montage supprimé, et la partition chiffrée fermée :
umount /home/user1
rm -fr /home/user1
cryptsetup luksClose user1_cryp
Test
Pour tester, il suffit d’ouvrir une session avec user1.
Conclusion
Il a fallut pas mal de temps pour réussir cette configuration (plus de 20 restauration de VM, et près de 300 tests).
Ce n’est pas d’une simplicité évidente; la documentation est assez minimaliste.
Mais le resultat est plutôt pas mal.
Un gros inconvénient tout de même: A chaque fois que le mot de p asse change il faut mettre à jour la clef de chiffrement. Sinon point de salut. Il faut donc avoir une gestion des mots de passe extrêmement méticuleuse.
Car pour des raisons évidente, un utilisateur ne peux pas avoir les droits sur le changement de clef d’une partition, car il pourrait modifier cette des autres. A chacun de définir alors ses processus.
Je n’ai pas testé l’authentification d’un utilisateur pour une connexion SSH avec des clefs. Cela fait aussi partie des tests qu’il me reste à faire.
Enfin, ce mécanisme peut très bien servir pour faire le montage de n’importe quel type de partition automatiquement à l’authentification de l’utilisateur.