Чи існує зашифрована файлова система лише для запису для Linux?


14

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

Чи існує така річ у Linux? Або якщо ні, то яка б була найкраща альтернатива для створення зашифрованих файлів журналів?

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


3
Я вірю, що ти можеш робити все, що хочеш syslog. Це відокремлює генерацію повідомлень журналу від системи, яка зберігає їх, тому програми, що генерують повідомлення, не мають доступу до місця їх зберігання. Журнали можуть навіть (і часто є) на окремому сервері.
mpez0

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

Відповіді:


4

... Я хочу, щоб дані були недоступними навіть тоді, коли система повністю порушена.

Це неможливо. Якщо система повністю скомпрометована, то "за визначенням" все, що на ній є, - навіть ключі шифрування.

Шифрування марно захищати від системних компромісів, поки система працює, якщо ключі для шифрування / дешифрування даних знаходяться в одній системі із зашифрованими даними. Наприклад, якщо у вас встановлена ​​файлова система LUKS, і хтось отримує доступ до кореневої системи до вашої системи, можна витягнути ключі з оперативної пам’яті, оскільки вони повинні жити в ОЗУ, щоб розшифрувати файлову систему. У вашій ситуації, якщо ви вводите свою парольну фразу щоразу, коли шифруєте файл, ви захищені (якщо припустити, що у вашій системі немає кейлоггера), якщо ні, ви потрапили в ту саму ситуацію, і хтось, хто компрометує вашу систему, може знайти це введіть і скасуйте все ваше шифрування.

Вам потрібно відправити дані, які ви хочете захистити поза системою + НЕ записуйте їх на посередницький носій у цій системі, якщо ви абсолютно не хочете, щоб корінь потрапляв до них. rsyslogявно підтримує це стосовно журналу, і ви можете зашифрувати зв’язок між джерелом та мийкою за допомогою OpenVPN stunnel, або подібного. Я впевнений, що є й інші "односторонні" варіанти передачі.


1
Будь ласка, читайте en.wikipedia.org/wiki/Public-key_cryptography
rakslice

"тому що вони повинні жити в оперативній пам'яті, щоб розшифрувати файлову систему", це може бути правдою для LUKS конкретно, але не в цілому: асиметрична криптовалюта призначена саме для цієї мети (хтось, що тримає відкритий ключ, може зашифрувати, але не розшифрувати)
Clément

3

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


$ touch log
$ chmod 222 log
$ echo test > log
$ cat log
cat: log: Permission denied

Звичайно, цей файл може знаходитися в зашифрованій файловій системі.


Ви можете змонтувати файлову систему за допомогою заданого umask, не дозволяючи користувачам змінювати дозволи.
NOS

І лише власник файлу (або суперпользователь) може змінити дозвіл.
горила

Я думаю, що ОП намагається захистити себе навіть від того, щоб нападник вкоренився.
Clément

1
umask 0477 && touch file && echo test > file && cat file

може бути корисним також. Будь-який файл, створений у поточному процесі, матиме режим 0200.

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