Dossier de départ chiffré toujours accessible après la déconnexion

13

Si vous avez un compte avec un dossier personnel chiffré, vous ne pouvez pas accéder aux données en texte brut de l'utilisateur dans son dossier personnel si cet utilisateur ne s'est pas encore connecté depuis le dernier démarrage du système. C'est ce à quoi je m'attendais car il ne devrait en fait pas être possible d'accéder au dossier de départ d'un utilisateur sans avoir entré son mot de passe.

Cependant, j'ai constaté que lorsqu'un utilisateur avec un dossier de départ chiffré se connecte puis se déconnecte, les données en texte brut dans son dossier de départ sont toujours accessibles aux autres utilisateurs. Naturellement, des privilèges d'accès suffisants sont requis.

wne répertorie pas l'utilisateur et la sortie de sudo pgrep -u <username>est vide, indiquant que l'utilisateur n'a aucun processus en cours d'exécution.

Quelle est la raison de ce comportement? Pourquoi ne pas simplement verrouiller le dossier de départ de l'utilisateur après sa déconnexion?

UTF-8
la source
Pourriez-vous s'il vous plaît inclure la sortie de grep -Fe ecryptfs /var/log/auth.logà peu près au moment où l'utilisateur s'est déconnecté?
David Foerster
La commande donne cette sortie: pastebin.com/jZXdahbJ Selon Emacs, les seules lignes qui contiennent la chaîne "ecryptfs" sont les lignes qui ont été produites lorsque j'ai exécuté cette commande.
UTF-8
Le résultat est comme prévu juste les lignes qu'Emacs m'a déjà montré: pastebin.com/VtV7iCDg
UTF-8
D'accord. Ça valait le coup d'oeil.
David Foerster
J'ai également remarqué ce bug dans les systèmes live persistants (dans une tentative de créer un deuxième utilisateur avec une maison cryptée).
sudodus

Réponses:

6

Bug connu

Si je comprends bien, c'est un bug connu.

Voir ce lien: wiki.archlinux.org/index.php/ECryptfs

Faites défiler jusqu'au paragraphe rose

Attention: Malheureusement, le démontage automatique est susceptible de rompre avec systemd et des bugs sont déposés contre lui ...

Solution de contournement

Comme c'est le cas maintenant, vous feriez mieux d' arrêter ou de redémarrer afin de supprimer les traces (il ne suffit pas de vous déconnecter).

sudodus
la source
Qu'entendez-vous par «la déconnexion entraînera une fuite d'informations entre les utilisateurs»? Voulez-vous dire que quelque chose se passe, à part qu'un autre utilisateur disposant de privilèges suffisants peut accéder aux données en texte brut dans le répertoire de base du premier utilisateur? (Ceci est déjà possible avant la déconnexion, bien sûr.)
UTF-8
1
Essayer de mieux expliquer: «Il ne suffit pas de se déconnecter». (La déconnexion ne supprime pas les instances en texte clair des fichiers, qui ont été utilisées par l'utilisateur dont le domicile est chiffré. Les informations peuvent donc fuir de cet utilisateur vers un autre utilisateur, qui se connecte, au moins si cet autre utilisateur dispose des privilèges sudo. Mais si vous arrêtez ou redémarrez, les instances en texte clair des fichiers disparaissent.
sudodus
3

Je ne peux pas tester ou confirmer cela, mais en supposant que vous utilisez ecryptfs(ce que propose Ubuntu lors de l'installation, IIRC), les données chiffrées sont stockées dans un dossier caché /home/.encryptfs/$USERet montées à l'emplacement de votre dossier personnel à l'aide du ecryptfspilote lorsque vous vous connectez dans.

Il est donc très probable que lorsque vous vous déconnectez, il ne parvienne pas à démonter automatiquement ce répertoire, de sorte que les fichiers sont toujours accessibles. Cela pourrait être causé par ...

  • une mauvaise configuration (peut-être était-elle censée être configurée pour se démonter à la déconnexion mais ne l'était pas)
  • type de déconnexion inattendu (parfois ces solutions fonctionnent pour la connexion / déconnexion DM mais ne fonctionnent pas bien sinon)
  • si le démontage est géré par un script de déconnexion (pas nécessairement le cas), quelque chose qui précède la commande de démontage peut échouer et entraîner la fermeture anticipée du script.

Une chose qui peut vous aider à vérifier cela serait d'exécuter sudo mount | grep homeavant la connexion, après la connexion et après la déconnexion pour voir si quelque chose impliquant homeest en cours de montage. Vous pouvez également rechercher /etc/fstabdes entrées pertinentes. Enfin, il y a une configuration /home/.ecryptfs/$USER/.ecryptfs/avec des paramètres pertinents pour le montage / démontage automatique.

Des informations utiles sur ecryptfspeuvent être trouvées dans cette réponse et dans l' ArchWiki toujours utile .

krs013
la source
J'ai essayé ce que vous m'avez dit: pastebin.com/DrmEXQPV Je ne me déconnecte pas de manière bizarre mais de la manière standard de l'interface graphique. Le FS est toujours monté, comme vous pouvez le voir. Les fichiers de configuration que vous avez mentionnés sont vides. Il n'y a rien dans mon /etc/fstabentrée sauf pour dire que ma seule partition de données devrait être montée sur /et 1 entrée qui concerne une ressource réseau liée à l'université. Dois-je essayer de me déconnecter d'une autre manière? Si c'est le cas, comment?
UTF-8
Le commentaire de déconnexion d'une manière différente était un peu une supposition - les gestionnaires de bureau ajoutent beaucoup en plus de la connexion et de la déconnexion, ce qui complique la notion et rend difficile de dire quels événements sont déclenchés. Je me demandais parce qu'il y avait peut-être un script ou un événement qui n'était pas en cours d'exécution. D'après les autres réponses, ce n'est pas ce genre de problème, mais quelque chose à voir avec ecryptfslui-même. Sur cette note, cependant, utilisez-vous sshou vous connectez-vous via les terminaux de texte? Il peut être possible d'écrire un script qui se chargera de démonter à la déconnexion si nous trouvons où le mettre.
krs013
3

Modifier /etc/systemd/logind.confet définirKillUserProcesses=yes

Notez que ces pauses programmes d'arrière - plan, screen, tmuxet même ...

Cette question va ici plus en détail. Je trouve la définition d'un nouveau service systemd inutile (ou plus précisément, pas le comportement souhaité, car il est appelé en tant que hook d'arrêt, pas à la fin de la session utilisateur).

/unix/251902/ecryptfs-auto-umount-does-not-work

quadruplebucky
la source
Je vais vérifier si votre méthode fonctionne pour un système live persistant avec un deuxième utilisateur, qui a chiffré la maison.
sudodus
Désolé, mais je n'ai pas pu faire fonctionner cette méthode dans un système live persistant avec un deuxième utilisateur, qui a chiffré la maison. (Je n'ai pas testé votre solution dans un système installé, je laisserai cela à @ UTF-8 qui a posé la question d'origine.)
sudodus
Je ne souhaite pas résoudre ce problème sur mon propre ordinateur. Je suis le seul à l'utiliser de toute façon, mais je veux utiliser 2 comptes avec des dossiers personnels chiffrés et personne d'autre ne connaît le mot de passe de l'un ou l'autre compte. Je m'intéresse à la raison pour laquelle il ne démonte pas automatiquement les volumes chiffrés par défaut . Ne pourrait-il pas simplement vérifier les processus d'arrière-plan actifs exécutés dans le contexte de l'utilisateur et les démonter s'il n'y en a pas?
UTF-8
@ UTF-8, je suis d'accord avec vous, que cela devrait fonctionner comme vous le souhaitez. Si je comprends bien, c'est un bug connu. Voir ce lien, wiki.archlinux.org/index.php/ECryptfs . Faites défiler jusqu'au paragraphe rose «Avertissement: Malheureusement, le démontage automatique est susceptible de rompre avec systemd et des bogues sont déposés». - Comme c'est le cas maintenant, vous feriez mieux d'arrêter ou de redémarrer afin de supprimer les traces (la déconnexion entraînera une fuite d'informations entre les utilisateurs.)
sudodus
@ UTF-8 c'est un bug dans l'interaction systemd / session depuis au moins sifflant (je suis parfaitement à l'aise de simplement l'accrocher sur systemd) - le changement /etc/systemd/logind.conf fonctionne pour moi le 16.04 (testé avec trois utilisateurs différents , différentes sessions, etc ...)
quadruplebucky
3

Je fais des recherches sur ce problème depuis un certain temps, c'est-à-dire que le système de fichiers non crypté reste monté après la déconnexion de l'utilisateur.

J'ai utilisé "ecryptfs-migrate-home -u user" pour créer le montage. suivi les instructions et tous les travaux, sauf pas de démontage automatique à la déconnexion.

J'ai comparé les fichiers de configuration dans /etc/pam.d/ à la documentation de pam_ecryptfs et j'ai trouvé quelques différences. ecryptfs était dans 4 des fichiers de configuration pam.d alors que les documents pam_ecryptfs indiquent que seulement 2 fichiers ont besoin / devraient / prendre en charge ecryptfs, par exemple,

   /etc/pam.d/common-auth:
              auth    required        pam_ecryptfs.so unwrap
   /etc/pam.d/common-session:
              session optional        pam_ecryptfs.so unwrap

J'ai donc commenté les 2 autres instances, redémarré et tout a fonctionné, les montages automatiques à la connexion et les démontages automatiques à la déconnexion pour les connexions graphiques et console. (J'ai utilisé des tty alternatifs pour vérifier à partir du compte root)

C'est le 18.04 Lubuntu sur un ordinateur portable, un ordinateur de bureau et un invité virtualbox (hôte Windows).

Je suis intéressé par l'expérience des autres.

edit_1: formulation améliorée. edit_2: ajout des résultats des tests de bureau et VB.

redrock
la source
La désactivation / la mise en commentaire de ces lignes a-t-elle causé des problèmes? La modification de votre mot de passe recompresse-t-elle toujours le fichier de clés eCryptfs?
Xen2050
Cela a fonctionné pour moi sur Linux Mint 19. Pour ajouter plus de détails pour les autres: les quatre fichiers de configuration dans /etc/pam.d qui font référence à ecryptfs sont: common-auth, common-password, common-session, common-session- non interactif. La mise en commentaire des lignes dans common-password et common-session-noninteractive a conduit au comportement souhaité de démontage à la déconnexion. En outre, l'entrée dans common-auth a été définie sur "facultatif" au lieu de "requis" car elle est censée être conforme à la documentation. Cependant, je l'ai laissé tel quel.
evencoil
@ Xen2050, désolé pour une réponse tardive. Je n'ai détecté aucun problème après des modifications commentant des lignes et je n'ai pas encore essayé de changer de mot de passe.
redrock le
Le changement de mot de passe peut être important à tester, il doit recouvrir automatiquement la clé de cryptage avec votre nouveau mot de passe, donc la connexion la prochaine fois fonctionne. Si cela ne fonctionne pas, le simple fait de remplacer le mot de passe par le précédent devrait fonctionner ... [c'est toujours bien d'avoir une sauvegarde cependant]
Xen2050
1
@ Xen2050, j'ai fait le test de changement de mot de passe. ça a marché.
redrock
2

Je le fais avec un script dans rclocal

#!/bin/sh
#

while true; do
    if [ ! -d /run/user/1000 ]; then
        if [ -f /home/momo/.mounted ]; then
            umount /home/harry
        fi      
    fi

    if [ ! -d /run/user/1001 ]; then
        if [ -f /home/vm/.mounted ]; then
            umount /home/maud
        fi
    fi

    sleep 10
done
exit 0
Walter wunsch
la source
Comment obtenez-vous l'ID utilisateur?
Avinash Raj
0

Si vous n'avez pas besoin d'accéder depuis cron ou à des tâches (tâches non interactives) à N'IMPORTE QUEL répertoire personnel, il vous suffit de commenter la ligne

session  optional        pam_ecryptfs.so unwrap

dans /etc/pam.d/common-session-noninteractive.

Cela entraînera le démontage de tous les répertoires personnels chiffrés lorsque l'utilisateur se déconnectera.

Geoff Mulligan
la source