Dossier personnel chiffré toujours accessible après la déconnexion

8

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 leur dossier personnel si cet utilisateur n'a pas encore ouvert de session depuis le dernier démarrage du système. C'est ce à quoi je m'attendais car il ne devrait pas être pratiquement possible d'accéder au dossier de base d'un utilisateur sans que son mot de passe ne soit entré.

Cependant, j'ai constaté que lorsqu'un utilisateur avec un dossier personnel chiffré se connecte puis se déconnecte, les données en texte brut de son dossier de base sont toujours accessibles aux autres utilisateurs. Des privilèges d'accès suffisants sont nécessaires, bien sûr.

w ne répertorie pas l'utilisateur et la sortie de sudo pgrep -u <username> est vide, ce qui indique 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 base de l'utilisateur après sa déconnexion?

    
posée UTF-8 30.04.2017 - 16:16
la source

4 réponses

2

Bug connu

Si je comprends bien, il s’agit d’un bogue 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 se rompre avec systemd et des bogues y sont déposés ...

Contournement

À l’heure actuelle, mieux vaut arrêter ou redémarrer pour supprimer les traces (c’est pas assez pour se déconnecter) ).

    
réponse donnée sudodus 06.07.2017 - 17:14
la source
2

Je ne peux ni tester ni 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/$USER l'emplacement du dossier de base à l'aide du pilote ecryptfs lorsque vous vous connectez.

Très probablement, alors, ce qui se passe est que lorsque vous vous déconnectez, il ne parvient pas à démonter automatiquement ce répertoire, donc 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éconnecter lors de la déconnexion mais ne l'était pas)
  • type de déconnexion inattendu (parfois, ces solutions fonctionnent pour le login / out DM mais ne fonctionnent pas bien autrement)
  • si le démontage est géré par un script de déconnexion (pas nécessairement le cas), quelque chose précédant la commande unmount peut échouer et provoquer la sortie anticipée du script.

Une chose qui peut vous aider à vérifier ceci est d’exécuter sudo mount | grep home avant la connexion, après la connexion et après la déconnexion pour voir si quelque chose impliquant home est en cours de montage. Vous pouvez également consulter /etc/fstab pour les entrées pertinentes. Enfin, il existe une configuration dans /home/.ecryptfs/$USER/.ecryptfs/ avec des paramètres pertinents pour le montage automatique / le démontage automatique.

Vous trouverez des informations utiles sur ecryptfs dans cette réponse . ArchWiki utile.

    
réponse donnée krs013 02.07.2017 - 20:55
la source
2

Modifiez /etc/systemd/logind.conf et définissez KillUserProcesses=yes

Notez que ceci brise les programmes en arrière-plan, screen , tmux et similaire ...

Cette question est détaillée ici. Je trouve que la définition d'un nouveau service systemd n'est pas nécessaire (ou plus exactement, pas le comportement souhaité, car il est appelé en tant que hook d'arrêt, et non lorsque la session utilisateur se termine).

lien

    
réponse donnée quadruplebucky 06.07.2017 - 05:47
la source
0

Je recherche ce problème depuis un certain temps, à savoir 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 un 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 trouvé certaines différences. ecryptfs était dans 4 des fichiers de configuration pam.d alors que les documents pam_ecryptfs indiquent seulement 2 fichiers ont besoin / devraient / supportent 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 deux autres instances, redémarré et tout a fonctionné, les montages automatiques lors de la connexion et le retrait automatique lors de la déconnexion pour les connexions graphiques et de console. (J'ai utilisé des tty alternatifs pour vérifier à partir du compte root)

Ceci 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: libellé amélioré. edit_2: ajout des résultats de test du bureau et de VB.

    
réponse donnée redrock 07.07.2018 - 06:46
la source

Lire d'autres questions sur les étiquettes