Зашифрована домашня папка все ще доступна після виходу


13

У мене є обліковий запис із зашифрованою домашньою папкою, ви не можете отримати доступ до простих текстових даних користувача у їх домашній папці, якщо той користувач ще не ввійшов у систему, оскільки система останнього завантаження. Це я очікував, оскільки насправді це не може бути практично можливим отримати доступ до домашньої папки користувача без введення пароля.

Однак я виявив, що коли користувач із зашифрованою домашньою папкою входить, а потім виходить із системи, дані простий текст у їх домашній папці все ще доступні для інших користувачів. Звичайно, потрібні достатні права доступу.

wне відображає список користувачів і вихід sudo pgrep -u <username>пустий, що вказує на те, що у користувача немає жодних запущених процесів.

У чому причина такої поведінки? Чому б просто не заблокувати домашню папку користувача після виходу з системи?


Чи можете ви включити вихідні дані grep -Fe ecryptfs /var/log/auth.logприблизно через час, коли користувач вийшов?
Девід Фоерстер

Команда дає такий результат: pastebin.com/jZXdahbJ Згідно з повідомленням Emacs, єдині рядки, що містять рядок "encryptfs", - це рядки, які були створені, коли я виконував цю команду.
UTF-8

Результат, як очікувалося, якраз ті рядки, які мені вже показали Emacs: pastebin.com/VtV7iCDg
UTF-8,

Гаразд. Варто було подивитися.
Девід Фоерстер

Я помітив цю помилку і в стійких живих системах (у спробі створити другого користувача із зашифрованим домом).
sudodus

Відповіді:


6

Відома помилка

Якщо я правильно розумію, це відома помилка.

Дивіться це посилання: wiki.archlinux.org/index.php/ECryptfs

Прокрутіть униз до рожевого абзацу

Попередження: На жаль, автоматичне відключення чутливе до розриву із системою, і проти нього подаються помилки ...

Обхід

Як це зараз, то вам краще закрили або перезавантаження , щоб видалити сліди (Це НЕ досить , щоб вийти).


Що ви маєте на увазі під "виходом з системи, буде витікати інформація між користувачами"? Ви маєте на увазі, що щось трапляється, окрім того, що інший користувач з достатніми привілеями може отримати доступ до даних простого тексту в домашньому каталозі першого користувача? (Зрозуміло, це вже можливо перед виходом із системи, звичайно.)
UTF-8

1
Намагаючись пояснити краще: "Вийти з системи недостатньо". (Вихід не вилучає чітко текстові екземпляри файлів, які використовував користувач із зашифрованим домом. Тому інформація може просочуватися від цього користувача до іншого користувача, який входить у систему, принаймні, якщо цей інший користувач має привілеї sudo. Але якщо ви
вимкнете

3

Я не можу це перевірити чи підтвердити, але якщо припустити, що ви використовуєте ecryptfs(що пропонує Ubuntu під час встановлення, IIRC), зашифровані дані зберігаються у прихованій папці /home/.encryptfs/$USERта монтуються у фактичне місце розташування домашньої папки за допомогою ecryptfsдрайвера під час реєстрації. в.

Швидше за все, тоді відбувається те, що коли ви виходите з системи, він не може автоматично відключити цей каталог, тому файли все ще доступні. Це може бути викликано ...

  • погана конфігурація (можливо, її потрібно було налаштувати для відключення під час виходу, але не було)
  • несподіваний тип виходу (іноді ці рішення працюють для входу в систему / виходу з DM, але інакше не працюють)
  • якщо демонтаж обробляється сценарієм виходу (не обов'язково), щось, що передує команді unmount, може вийти з ладу і спричинити вихід сценарію достроково.

Одне, що може допомогти вам перевірити це - це запуститись sudo mount | grep homeперед входом, після входу та після виходу, щоб побачити, чи встановлено щось, що стосується home. Ви також можете шукати /etc/fstabвідповідні записи. Нарешті, є деяка конфігурація /home/.ecryptfs/$USER/.ecryptfs/з відповідними налаштуваннями для автоматичного налаштування / відключення.

Корисну інформацію ecryptfsможна знайти у цій відповіді та у завжди корисній ArchWiki .


Я спробував те, що ви мені сказали: pastebin.com/DrmEXQPV Я не виходив жодним дивним способом, але стандартним графічним інтерфейсом. FS все ще змонтований, як бачите. Згадані вами конфігураційні файли порожні. У моєму /etc/fstabзаписі немає нічого, окрім 1 запису, який говорить про те, що мій єдиний розділ даних повинен бути встановлений /і 1 запис, який стосується деякого мережевого ресурсу, пов'язаного з університетом. Чи варто спробувати вийти із системи будь-яким іншим способом? Якщо так: як?
UTF-8

У коментарях із виходу в інший спосіб коментар був трохи здогадкою - менеджери настільних ПК багато додають на додаток до входу та виходу з системи, що ускладнює поняття та ускладнює визначення того, які події викликаються. Мені було цікаво, бо, можливо, був якийсь сценарій чи подія, яку не виконували. Виходячи з інших відповідей, це не така проблема, а щось із ecryptfsсобою. Однак на цій замітці ви використовуєте sshабо входите через текстові термінали? Можливо, можливо, написати сценарій, який допоможе відключити вихід, якщо ми знайдемо, де його розмістити.
krs013

3

Відредагуйте /etc/systemd/logind.confта встановітьKillUserProcesses=yes

Зверніть увагу , що це порушує фонові програми, screen, tmuxі тому подібні ...

Це питання тут іде до нього детальніше. Я вважаю, що визначення нового системного сервісу непотрібне (або, точніше, не бажана поведінка, оскільки його викликають як гачок відключення, а не після закінчення сеансу користувача).

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


Я перевірю, чи працює ваш метод для стійкої живої системи з другим користувачем, який зашифрував будинок.
sudodus

Вибачте, але мені не вдалося змусити цей метод працювати в стійкій системі живлення з другим користувачем, який зашифрував домашню програму. (Я не перевіряв ваше рішення в інстальованій системі, я залишаю це @ UTF-8, який задав оригінальне запитання.)
sudodus

Мені не цікаво виправити це на власному комп’ютері. Я єдиний, хто користується ним у будь-якому випадку, але хочу використовувати два облікові записи із зашифрованими домашніми папками, і ніхто більше не знає пароль для будь-якого облікового запису. Мене цікавить, чому за замовчуванням він не відключає зашифровані томи автоматично . Чи не може він просто перевірити активні фонові процеси, що працюють у користувальницькому контексті, і відключити його, якщо таких немає?
UTF-8

@ UTF-8, я згоден з вами, що він повинен працювати так, як ви хочете, щоб він працював. Якщо я правильно розумію, це відома помилка. Дивіться це посилання, wiki.archlinux.org/index.php/ECryptfs . Прокрутіть униз до рожевого абзацу "Попередження: На жаль, автоматичне відключення чутливе до розриву з системою та подано помилки". - Як зараз, вам краще вимкнути або перезавантажити, щоб видалити сліди (вихід у систему
витече

@ UTF-8 це помилка у взаємодії systemd / сесія, оскільки принаймні хрипкий (мені цілком комфортно просто повісити його на systemd) - зміна /etc/systemd/logind.conf працює для мене 16.04 (перевірено з трьома різними користувачами , різні сеанси тощо ...)
quadruplebucky

3

Я досліджував цю проблему досить довгий час, тобто незашифрована файлова система залишається встановленою після виходу користувача.

Я використовував "ecryptfs-migrate-home -u user", щоб створити mount. дотримуйтесь вказівок і все працює, за винятком автоматичного відключення при виході.

Я порівняв конфігураційні файли в /etc/pam.d/ з документацією на пам_ecryptfs і виявив деякі відмінності. ecryptfs був у 4 файлах конфігурації pam.d, тоді як документи pam_ecryptfs вказують лише на 2 файли, які потребують / повинні / підтримують ecryptfs, наприклад,

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

Отже, я прокоментував інші два екземпляри, перезавантажив, і все це спрацювало, автоматично встановлюється при вході в систему та автоматично вимикається під час виходу як для графічного, так і для консольного входу. (Я використовував альтернативні tty's для підтвердження з кореневого облікового запису)

Це 18.04 Lubuntu на ноутбуці, настільних комп’ютерах та віртуальних скриньках (гість Windows).

Мене цікавить досвід інших.

edit_1: покращена редакція. edit_2: додані результати тестів на робочому столі та VB.


Чи вимкнення / коментування будь-якого з цих рядків викликало якісь проблеми? Чи зміна вашого пароля все ще повторно заверне файл eCryptfs?
Xen2050

Для мене це працювало в Linux Mint 19. Щоб додати ще детальну інформацію для інших: чотири конфігураційні файли в /etc/pam.d, які посилаються на шифри, є: common-auth, common-password, common-session, common-session- неінтерактивний. Коментування рядків у загальному паролі та неінтерактивному спільному сеансі призвело до бажаної поведінки відключення виходу із системи. Крім того, запис у common-auth було встановлено на "необов'язково", а не "обов'язково", як це передбачається згідно з документацією. Однак я залишив це як є.
evencoil

@ Xen2050, вибачте за несвоєчасну відповідь. Я не виявив жодних проблем після змін, коментуючи рядки, і я ще не намагався змінити пароль.
redrock

Змінюючий пароль може бути важливим для перевірки, він повинен автоматично перевпакувати ключ шифрування з вашим новим паролем, тому вхід в наступний раз працює. Якщо це не працює, то просто повернення пароля до попереднього має спрацювати ... [хоча завжди добре мати резервну копію]
Xen2050

1
@ Xen2050, я зробив тест на зміну пароля. це спрацювало.
redrock

2

Я роблю це зі сценарієм в 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

Як ви отримуєте userid?
Avinash Raj

0

Якщо вам не потрібен доступ із cron або на роботу (неінтерактивні завдання) до будь-яких домашніх каталогів, тоді вам просто потрібно прокоментувати рядок

session  optional        pam_ecryptfs.so unwrap

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

Це призведе до відключення всіх зашифрованих домашніх каталогів, коли користувач вийде з системи.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.