eCryptfs, bezpieczeństwo plików dla każdego (Linuksowca)

Tomasz Torcz 2006-11-22 14:57 Comments

Wraz z jądrem 2.6.19 użytkownicy Linuksa dostają bardzo wygodny sposób na szyfrowanie swoich danych, mianowicie eCryptfs.

Sam szyfruję mój ~ od trzech lat. W wakacje 2004 przeszedłem z cryptoloop na dm-crypt. Jest bardzo wygodny, jednak operuje na całych urządzeniach blokowych, co jest jednocześnie jego zaletą i wadą. Zaletą, gdyż można go użyć do szyfrowania partycji swap czy urządzeń, do których np. bazy danych odwołują się bez pośrednictwa systemu plików, lub które są udostępniane przez iSCSI. Całościowe szyfrowanie poza zawartością plików utajnia też ich nazwy i strukturę katalogów. Wadą zaś jest konieczność wcześniejszego przeznaczenia bezpiecznego wolumenu i bardzo uciążliwa migracja danych.

Inne podejście stosuje tytułowy eCryptfs. Operuje w innym miejscu stosu -- jest nakładany na już istniejący system plików (dm-crypt znajduje się pomiędzy urządzeniami blokowymi a filesystemami). Z tego powodu trywialne jest zaszyfrowanie danych uprzednio obecnych na dysku. Wystarczy stworzyć obok katalog z włączonym szyfrowaniem i przenieść dane. Dane bezpieczne współdzielą przestrzeń dyskową z niezabezpieczonymi.

Jak widać eCryptfs i dm-crypt dają trochę inne możliwości i nadają się do różnych zastosowań. Całościowe szyfrowanie dysków dm-cryptem prawdopodobnie wspierane będzie w kolejnym Ubuntu. Do moich zastosowań lepiej jednak nadaje się eCryptfs.

Archived comments:

Michał Górny 2006-11-22 16:20:43

A mi bardziej by się przydała transparentna kompresja katalogów przez bzip2.

zdzichu 2006-11-22 18:07:01

Natywna kompresję ma ZFS :). I chyba reiser4fs, ale ten to w tej dekadzie do jądra chyba nie trafi.

Michał Górny 2006-11-22 18:23:22

Nie kojarzę, by udało mi się znaleźć jakąś implementację zfs pod Linuksa. A Reiser4 próbowałem jeszcze z kerneli -mm, ale za jasną cholerę nie potrafiłem rozszyfrować, jak toto zmusić do zamierzonych zadań.

zdzichu 2006-11-22 18:24:23

Bo pod Linuksa nie ma ZFS. Są pod inne otwarte, wolne systemu, jak OpenSolaris czy FreeBSD. Prawdopodobnie pod Darwina też będzie.

Michał Górny 2006-11-22 18:29:39

Tylko że pod tymi innymi systemami, o ile kojarzę, nie ma dobrego wsparcia DVB, ani em8300.

Azrael Nightwalker 2006-11-23 00:20:09

"Dane bezpieczne współdzielą przestrzeń dyskową z zabezpieczonymi."
Chyba ci chodziło o "niezabezpieczonymi"

zdz 2006-11-23 10:33:59

Azrael: dzięki, poprawiłem.

Azrael Nightwalker 2006-11-23 10:34:58

Jeszcze apropos ZFSa - gdzieś czytałem że ktoś go portuje do Linuksa przy użyciu FUSE.

m--s 2006-11-24 00:14:20

Azrael: niby że tak, ale ostatnio chyba jest zastój:

http://zfs-on-fuse.blogspot.com/

do samego jądra Linuksa to by go trzeba (ZFSa) przepisać od nowa, bo licencja OpenSolarisowa CDDL (na któej wydany jest też ZFS) jest niekompatybilna z GPL (zresztą CDDL specjalnie została tak zaprojektowana, wzmianka o tym jest między innymi tu: http://lxer.com/module/newswire/view/68828/index.html).

FUSE (http://fuse.sourceforge.net/) to jednak coś innego, bo to nie GPL, ale LGPL, czyli że można to linkować z czym się chce, czyli między innymi z modułami na CDDL. Wydaje się to być póki co jedyne rozwiązanie problemu "ZFS dla Linuksa".

Zupełnie oddzielnie ZFS jest przenoszone do FreeBSD, głównie dzięki Polakowi (yay!) Pawłowi Dawidkowi: http://www.opensolaris.org/jive/thread.jspa?threadID=12562, chyba nawet jest już włączone do oficjalnego repozytorium.

Azrael Nightwalker 2006-11-24 00:15:58

Na ZFSa w Linuksie mamy 2 dodatkowe szanse:
1) Przeportowanie kodu z BSD
2) Udostępnienie OpenSolarisa na GPL (patrz Java)

m--s 2006-11-24 00:26:50

acha, ZFS to chyba offtopic niestety, gdyż w ZFSie brakuje szyfrowania, jest dopiero w fazie "pomysłu" na OpenSolaris'ie, nie mówiąc o portowaniu tego gdzie indziej:

http://opensolaris.org/os/project/zfs-crypto/

... oczywiście sposób działania ZFS i jego mocna integracja ze sprzętem (czyli największa jego zaleta) uniemożliwia stosowanie niezależnych rozwiązań, a przynajmniej mocno je utrudnia - bo niby jak w tym wszystkim miałyby działać snapshoty i klony z jednoczesnym (sic!) raportowaniem błędów fizycznych sektorów dysku? ... chyba, że nakładać szyfrowanie na poziomie już samych plików, jak wspomniany tu eCryptfs, ale to raczej nie nadaje się do "poważnych zastosowań" (niemożliwe jest np. ukrywanie samego faktu szyfrowania, czy też niszczenie danych przez po prostu zamazanie klucza, co daje "bezpieczne wyczyszczenie" dysku o dowolnym rozmiarze w czasie poniżej sekundy, nawet jeśli hasło było zapisane na żółtej karteczce przy monitorze :) ).

Uważam, że temat systemu plików ZFS powinien być rozpropagowany wszędzie gdzie się da, to wszak prawdziwa rewolucja! ...trochę szkoda, że prawie nikt o nim nie słyszy.

m--s 2006-11-24 00:35:23

Azrael: byłoby naprawdę pięknie, ale jeśli przyjrzeć się temu, co mają do powiedzenia rzecznicy (?) firmy Sun, to największymi przeciwnikami udostępnienia kodu jądra Solarisa na GPLu są... jego deweloperzy. Wiele z kluczowych osób stwierdziło, że w razie wypuszczenia całości na GPLu odchodzą z roboty... szczegóły pod podanym przeze mnie wcześniej linkiem (http://lxer.com/module/newswire/view/68828/index.html), a dokładniej to w pliku wideo oznaczonym jako [2].

Toto ma ponad 40 minut, ale warto całość przesłuchać, dużo tam mówią o stanowisku Suna względem licencji.

Michał Górny 2006-11-24 16:28:03

Znalazłem coś ciekawego:
# http://parallel.vub.ac.be/~johan/compFUSEd/
# http://www.kr.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/announce.txt

zdzichu 2006-11-24 21:39:48

Azrael: przeportowanie kodu z BSD? Przecież on dalej jest na licencji CDDL.

Azrael Nightwalker 2006-11-26 20:41:54

A fakt, dla jądra BSD to nie problem.