Zaszyfrowany folder domowy jest nadal dostępny po wylogowaniu


13

Jeśli masz konto z zaszyfrowanym folderem domowym, nie możesz uzyskać dostępu do danych tekstowych użytkownika w jego folderze domowym, jeśli ten użytkownik jeszcze się nie zalogował od czasu ostatniego uruchomienia systemu. Tego się spodziewałem, ponieważ w rzeczywistości dostęp do folderu domowego użytkownika powinien być praktycznie niemożliwy bez podania hasła.

Odkryłem jednak, że kiedy użytkownik z zaszyfrowanym folderem domowym loguje się, a następnie wylogowuje, dane w postaci zwykłego tekstu w folderze domowym są nadal dostępne dla innych użytkowników. Oczywiście wymagane są wystarczające uprawnienia dostępu.

wnie wyświetla użytkownika, a wynik działania sudo pgrep -u <username>jest pusty, co wskazuje, że użytkownik nie ma uruchomionych procesów.

Jaki jest powód tego zachowania? Dlaczego nie zablokować folderu domowego użytkownika po wylogowaniu?


Czy możesz podać wynik grep -Fe ecryptfs /var/log/auth.logz czasu wylogowania użytkownika?
David Foerster

Komenda daje wynik: pastebin.com/jZXdahbJ Według Emacsa jedynymi liniami zawierającymi ciąg „ecryptfs” są linie, które zostały utworzone, gdy uruchomiłem to polecenie.
UTF-8

Rezultat jest zgodny z oczekiwaniami tylko linii, które Emacs już mi pokazał: pastebin.com/VtV7iCDg
UTF-8

Dobrze. Warto było zajrzeć.
David Foerster

Zauważyłem ten błąd także w trwałych systemach na żywo (w próbie stworzenia drugiego użytkownika z zaszyfrowanym domem).
sudodus

Odpowiedzi:


6

Znany błąd

Jeśli dobrze rozumiem, jest to znany błąd.

Zobacz ten link: wiki.archlinux.org/index.php/ECryptfs

Przewiń w dół do różowego akapitu

Ostrzeżenie: Niestety automatyczne odmontowywanie jest podatne na zerwanie z systemd i zgłaszane są do niego błędy ...

Obejść

W tej chwili lepiej zamknąć lub uruchomić ponownie , aby usunąć ślady ( nie wystarczy się wylogować).


Co rozumiesz przez „wylogowanie spowoduje wyciek informacji między użytkownikami”? Czy masz na myśli, że coś się dzieje, poza tym, że inny użytkownik z wystarczającymi uprawnieniami może uzyskać dostęp do danych tekstowych w katalogu osobistym pierwszego użytkownika? (Oczywiście jest to już możliwe przed wylogowaniem.)
UTF-8

1
Próba lepszego wyjaśnienia: „Nie wystarczy się wylogować”. (Wylogowanie nie usuwa instancji plików tekstowych, które były używane przez użytkownika z zaszyfrowanym domem. Informacje mogą przeciekać od tego użytkownika do innego użytkownika, który loguje się, przynajmniej jeśli ten inny użytkownik ma uprawnienia sudo. Ale jeśli zamkniesz lub uruchomisz ponownie, instancje plików w postaci
zwykłego

3

Nie mogę tego przetestować ani potwierdzić, ale przy założeniu, że korzystasz ecryptfs(co Ubuntu oferuje podczas instalacji, IIRC), zaszyfrowane dane są przechowywane w ukrytym folderze /home/.encryptfs/$USERi montowane w rzeczywistej lokalizacji folderu domowego za pomocą ecryptfssterownika podczas logowania w.

Najprawdopodobniej dzieje się tak, że po wylogowaniu nie można automatycznie odmontować tego katalogu, więc pliki są nadal dostępne. Może to być spowodowane ...

  • zła konfiguracja (być może miał być skonfigurowany do odmontowania podczas wylogowywania, ale nie był)
  • nieoczekiwany typ wylogowania (czasami te rozwiązania działają przy logowaniu / wylogowaniu DM, ale w przeciwnym razie nie działają dobrze)
  • jeśli odmontowanie jest obsługiwane przez skrypt wylogowania (niekoniecznie tak jest), coś poprzedzającego polecenie odmontowania może się nie powieść i spowodować wcześniejsze zakończenie skryptu.

Jedną z rzeczy, które mogą pomóc Ci to sprawdzić, jest uruchomienie sudo mount | grep homeprzed zalogowaniem, po zalogowaniu i po wylogowaniu, aby sprawdzić, czy coś związanego z tym homejest montowane. Możesz także poszukać /etc/fstabodpowiednich wpisów. Wreszcie, istnieje pewna konfiguracja /home/.ecryptfs/$USER/.ecryptfs/z odpowiednimi ustawieniami do automatycznego montowania / odmontowywania.

Przydatne informacje na temat ecryptfsmożna znaleźć w tej odpowiedzi oraz w zawsze pomocnym ArchWiki .


Próbowałem tego, co mi powiedziałeś: pastebin.com/DrmEXQPV Nie wylogowuję się w żaden dziwny sposób, ale w standardowy sposób z GUI. FS jest nadal zamontowany, jak widać. Wspomniane pliki konfiguracyjne są puste. W moim /etc/fstabwpisie nie ma nic, oprócz tego, że moja jedyna partycja danych powinna zostać zamontowana, /a 1 wpis dotyczy zasobów sieciowych związanych z uniwersytetem. Czy powinienem spróbować wylogować się w inny sposób? Jeśli tak to jak?
UTF-8

Wylogowanie w inny sposób było nieco zgadywane - menedżerowie pulpitu dodają wiele do logowania i wylogowywania, co komplikuje to pojęcie i utrudnia określenie, które zdarzenia są wyzwalane. Zastanawiałem się, ponieważ mógł być jakiś skrypt lub zdarzenie, które nie było uruchamiane. Na podstawie innych odpowiedzi nie jest to taki problem, ale coś wspólnego z ecryptfssamym sobą. Czy w tej notatce korzystasz sshlub logujesz się przez terminale tekstowe? Może być możliwe napisanie skryptu, który zajmie się odmontowaniem podczas wylogowywania, jeśli znajdziemy gdzie go umieścić.
krs013,

3

Edytuj /etc/systemd/logind.confi ustawKillUserProcesses=yes

Zauważ, że to przerwy w tle programy screen, tmuxi podobne ...

To pytanie jest bardziej szczegółowe. Uważam, że zdefiniowanie nowej usługi systemowej jest niepotrzebne (a ściślej nie pożądane zachowanie, ponieważ jest wywoływane jako hak zamykania, a nie po zakończeniu sesji użytkownika).

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


Sprawdzę, czy twoja metoda działa dla trwałego systemu na żywo z drugim użytkownikiem, który zaszyfrował dom.
sudodus

Niestety, ale nie mogłem nie zrobić tej pracy metody w trwałym systemie żywo z drugim użytkownikiem, który został zaszyfrowany domu. (Nie przetestowałem twojego rozwiązania w zainstalowanym systemie, pozostawię to @ UTF-8, który zadał oryginalne pytanie.)
sudodus

Nie jestem zainteresowany naprawieniem tego na własnym komputerze. Jestem jedynym, który i tak z niego korzysta, ale chcę używać 2 kont z zaszyfrowanymi folderami domowymi i nikt inny nie zna hasła do żadnego z tych kont. Interesuje mnie, dlaczego domyślnie nie odmontowuje zaszyfrowanych woluminów . Czy nie może po prostu sprawdzić aktywnych procesów w tle działających w kontekście użytkownika i odmontować je, jeśli nie ma żadnych?
UTF-8

@ UTF-8, zgadzam się z tobą, że powinien działać tak, jak chcesz, aby działał. Jeśli dobrze rozumiem, jest to znany błąd. Zobacz ten link, wiki.archlinux.org/index.php/ECryptfs . Przewiń w dół do różowego akapitu „Ostrzeżenie: Niestety automatyczne odmontowywanie jest podatne na zerwanie z systemd i błędy są zgłaszane”. - Tak jak teraz, lepiej zamknij lub uruchom ponownie, aby usunąć ślady (wylogowanie spowoduje wyciek informacji między użytkownikami).
sudodus

@ UTF-8 to błąd w interakcji systemd / sesji, ponieważ przynajmniej świst (jestem całkowicie komfortowy, wieszając go na systemd) - zmiana /etc/systemd/logind.conf działa dla mnie 16.04 (testowana z trzema różnymi użytkownikami , różne sesje itp.)
quadruplebucky

3

Badam ten problem od dłuższego czasu, tj. Niezaszyfrowany system plików pozostaje zamontowany po wylogowaniu użytkownika.

Użyłem „ecryptfs-migrate-home -u user”, aby utworzyć mount. postępował zgodnie ze wskazówkami i wszystkie prace oprócz automatycznego odmontowania podczas wylogowywania.

Porównałem pliki konfiguracyjne w /etc/pam.d/ z dokumentacją pam_ecryptfs i znalazłem pewne różnice. ecryptfs był w 4 plikach konfiguracyjnych pam.d, podczas gdy dokumenty pam_ecryptfs wskazują, że tylko 2 pliki potrzebują / powinny / obsługiwać ecryptfs, np.

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

Tak więc skomentowałem pozostałe 2 instancje, uruchomiłem ponownie i wszystko działało, automatycznie montuje się przy logowaniu i automatycznie odmontowuje podczas wylogowania dla logowania graficznego i konsoli. (Użyłem alternatywnych tty do weryfikacji z konta root)

Jest to 18.04 Lubuntu na laptopie, komputerze stacjonarnym i gościu virtualbox (host Windows).

Interesuje mnie doświadczenie innych.

edit_1: poprawione brzmienie. edit_2: dodano wyniki testu pulpitu i VB.


Czy wyłączenie / skomentowanie któregoś z tych wierszy spowodowało jakieś problemy? Czy zmiana hasła nadal powoduje zawijanie pliku kluczy eCryptfs?
Xen2050,

Działa to dla mnie w Linux Mint 19. Aby dodać więcej szczegółów dla innych: cztery pliki konfiguracyjne w /etc/pam.d, które odnoszą się do ecryptfs, to: common-auth, common-password, common-session, common-session- nieinteraktywny. Komentowanie wierszy wspólnych haseł i nieinteraktywnych sesji wspólnych doprowadziło do pożądanego zachowania odmontowywania podczas wylogowywania. Ponadto wpis w common-auth został ustawiony na „opcjonalny” zamiast „wymagany”, jak powinno być zgodnie z dokumentacją. Zostawiłem to jednak takim, jakie jest.
evencoil

@ Xen2050, przepraszam za spóźnioną odpowiedź. Nie wykryłem żadnych problemów po zmianach komentujących linie i nie próbowałem jeszcze zmieniać hasła.
redrock

Zmiana hasła może być ważna do przetestowania, powinien automatycznie ponownie owinąć klucz szyfrujący nowym hasłem, więc logowanie przy następnym uruchomieniu będzie działać. Jeśli to nie zadziała, to tylko zmiana tył hasła do poprzedniego powinien pracować ... [to zawsze dobrze jest mieć kopię zapasową choć]
Xen2050

1
@ Xen2050, zrobiłem test zmiany hasła. zadziałało.
redrock

2

Robię to za pomocą skryptu w 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

Jak zdobyć identyfikator użytkownika?
Avinash Raj

0

Jeśli nie potrzebujesz dostępu z crona lub w zadaniach (zadania nieinteraktywne) do DOWOLNYCH katalogów domowych, musisz po prostu skomentować linię

session  optional        pam_ecryptfs.so unwrap

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

Spowoduje to odmontowanie wszystkich zaszyfrowanych katalogów domowych po wylogowaniu użytkownika.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.