Czy dla systemu Linux jest zaszyfrowany system plików tylko do zapisu?


14

Szukam zaszyfrowanego systemu plików dla systemu Linux, który można zamontować w trybie tylko do zapisu, co oznacza, że ​​powinieneś być w stanie zamontować go bez podawania hasła, a jednocześnie nadal móc pisać / dołączać pliki, ale nie powinieneś być w stanie odczytać zapisane przez siebie pliki ani odczytać plików już znajdujących się w systemie plików. Dostęp do plików należy zapewnić tylko wtedy, gdy system plików jest zamontowany za pomocą hasła. Ma to na celu zapisywanie plików dziennika lub podobnych danych, które są tylko zapisywane, ale nigdy nie są modyfikowane, bez ujawnienia samych plików. Uprawnienia do plików nie pomagają tutaj, ponieważ chcę, aby dane były niedostępne, nawet gdy system jest w pełni zagrożony.

Czy coś takiego istnieje w systemie Linux? A jeśli nie, jaka byłaby najlepsza alternatywa dla tworzenia zaszyfrowanych plików dziennika?

Moje obecne obejście polega na prostym przesyłaniu danych gpg --encrypt, co działa, ale jest bardzo kłopotliwe, ponieważ nie możesz łatwo uzyskać dostępu do systemu plików jako całości, musisz gpg --decryptręcznie przesłać każdy plik .


3
Wierzę, że możesz robić to, co chcesz syslog. To oddziela generowanie wiadomości dziennika od systemu, który je przechowuje, więc aplikacje generujące wiadomość nie mają dostępu do miejsca, w którym są przechowywane. Dzienniki mogą nawet (i często znajdują się) na osobnym serwerze.
mpez0,

Chcę pójść o krok dalej i nie mieć dostępu do danych, nie tylko do procesu, który je utworzył, ale nawet do rootowania. Tak właśnie działa szyfrowanie kluczem publicznym za pomocą gpg, ale szukam sposobu, aby to zrobić na poziomie systemu plików.
Grumbel,

Odpowiedzi:


4

... Chcę, aby dane były niedostępne, nawet gdy system jest w pełni zagrożony.

To jest niemożliwe. Jeśli system jest w pełni zagrożony, „z definicji” jest dostępne wszystko na nim - w tym klucze szyfrowania.

Szyfrowanie jest bezużyteczne w ochronie przed naruszeniem bezpieczeństwa systemu, gdy system jest uruchomiony, JEŻELI klucze do szyfrowania / deszyfrowania danych znajdują się w tym samym systemie z zaszyfrowanymi danymi. Na przykład, jeśli masz zainstalowany system plików LUKS i ktoś uzyskuje dostęp do systemu root, możesz wyciągnąć klucze z pamięci RAM - ponieważ musi on żyć w pamięci RAM, aby odszyfrować system plików. W Twojej sytuacji, jeśli wpisujesz hasło za każdym razem, gdy szyfrujesz plik, jesteś chroniony (zakładając, że keylogger nie jest obecny w twoim systemie), jeśli nie, to jesteś w tej samej sytuacji i ktoś, kto naruszy twój system, może to znaleźć klucz i cofnij całe szyfrowanie.

Musisz wysłać dane, które chcesz chronić poza systemem + NIE zapisuj ich na nośniku pośrednim w tym systemie, jeśli absolutnie nie chcesz, aby root się do nich dostał. rsyslogwyraźnie obsługuje to w odniesieniu do rejestrowania i można zaszyfrować połączenie między źródłem a zlewem za pomocą OpenVPN stunnellub podobnego. Jestem pewien, że istnieją inne opcje transferu „w jedną stronę”.



„ponieważ muszą żyć w pamięci RAM, aby odszyfrować system plików” może to dotyczyć konkretnie LUKS, ale nie ogólnie: asymetryczne szyfrowanie zostało zaprojektowane właśnie w tym celu (osoba posiadająca klucz publiczny może szyfrować, ale nie deszyfrować)
Clément

3

Wydaje mi się, że idziesz w złym kierunku. Jeśli chcesz plik, w którym można pisać, ale nie można go odczytać, to uprawnienia do plików są tym, czego szukasz.


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

Oczywiście ten plik może znajdować się w zaszyfrowanym systemie plików.


Możesz zamontować system plików za pomocą danego umask, nie pozwalając użytkownikom na zmianę uprawnień.
nos

I tylko właściciel pliku (lub superużytkownik) może zmienić uprawnienia.
goryl

Myślę, że OP próbuje się chronić nawet przed atakiem roota.
Clément

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

też może być przydatny. Każdy plik utworzony w ramach bieżącego procesu będzie miał tryb 0200.

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.