Szyfrowanie danych w Linuksie - EncFS.
17 czerwca, 2009
Niedawno Zal ładnie pisał o kompresji i szyfrowaniu realizowanymi via system plików, ale jak wynikło podczas dyskusji, szyfrowanie całego systemu plików może być kłopotliwe, jeśli z systemu korzysta kilku użytkowników. Oczywiście wszystko da się obejść, więc teraz szybki sposób na wprowadzenie szyfrowania dla wielu użytkowników - per user.
EncFS, bo o nim mowa, to szyfrowany system plików działający w oparciu o FUSE, czyli Filesystem In Userspace. W wersji podstawowej, albo raczej standalone, pozwala użytkownikowi na zaszyfrowanie katalogu. Jest to ciekawe, ale niezupełnie o to nam chodzi. Nawet z nakładkami typu cryptkeeper, stosowanie szyfrowania wymaga ingerencji i - przede wszystkim - pamięci użytkownika.
Jednak możemy mieć automatycznie montowany szyfrowany cały katalog domowy wskazanego użytkownika dzięki libpam-encfs przy logowaniu się użytkownika do systemu. Konfiguracji libpam-encfs opisywać nie będę, bo dokumentacja dostępna w /usr/share/doc/libpam-encfs/README* jest krótka, przystępna, aktualna i wystarczająca. Jedyne uwagi, które mi przychodzą do głowy to nie /etc/pam_encfs.conf, tylko /etc/security/pam_encfs.conf oraz użytkownik, który korzysta z szyfrowanego katalogu domowego musi być w grupe fuse (może nie jest to wystarczająco zaznaczone).
Zalety (zarówno EncFS, jak i libpam-encfs):
- prosty w użyciu,
- transparentny,
- szyfrowane są pliki, nie partycje, więc miejsce przyznawane jest dynamicznie,
- działa z dowolnym systemem plików jako bazowym (także np. FAT),
- w przypadku problemów z FS działają standardowe narzędzia, w przypadku uszkodzeń - dotyczą one pojedynczych plików,
- wszystko, czego potrzebujesz prawdopodobnie jest dostępne w Twojej dystrybucji Linuksa (w Debianie jest),
- powinno działać na dowolnym systemie obsługującym FUSE (szybki research wskazuje, że na MacOS działa), a także być przenośne między nimi (FIXME),
- kilka algorytmów szyfrowania, w tym preconfigured paranoia mode oparty o AES (do 256 bit IIRC),
- można określić czas bezczynności, po którym system plików zostanie odmontowany,
- łatwo można wymusić na wszystkich użytkownikach stosowanie szyfrowania danych.
Wady (j.w.):
- szyfruje tylko katalog domowy użytkownika, nie wszystkie miejsca z wrażliwymi danymi (patrz koniec wpisu),
- wymusza logowanie przez ssh przy pomocy hasła (przynajmniej wg. mojej wiedzy nie da się użyć klucza),
- w przypadku utraty hasła przez użytkownika danych nie da się odzyskać,
- kompresja takiego systemu plików raczej będzie nieefektywna,
- widoczne są rozmiar plików, ich ilość i atrybuty,
- widoczna jest przybliżona długość nazwy plików (z dokładnością do 8 lub 16 bajtów),
- użytkownik nie może zmieniać hasła, bo straci dostęp do danych (FIXME).
Zamiast źródła, garść mniej oczywistych linków: HOWTO dla EncFS pod Ubuntu i Fedorę, EncFS w trzech krokach.
No i jeszcze kilka ciekawostek - przy EncFS w wersji standalone można mieć więcej niż jeden klucz do każdego katalogu. Oczywiście każdy klucz odszyfrowuje tylko swoją część plików... Wymaga IIRC podania wprost pliku konfiguracyjnego. Z bardziej krytycznych miejsc - nie jest szyfrowany ani /tmp, ani swap, ale można pokusić się o /tmp w RAM, a ze swap zrezygnować (to raczej desktopy, albo naprawdę dużo RAM) i wtedy w prosty sposób uzyskujemy względnie dobrze zabezpieczony system.
Z założenia wpis nie ma być kompletnym HOWTO, raczej ma służyć prezentacji rozwiązania i zachęcić do wymiany opinii na jego temat - zapraszam. Z doświadczeń - przy odczycie większych ilości danych EncFS potrafi trochę spowolnić kompa. Nie testowałem wydajności dla większej ilości jednoczesnych użytkowników.
Gratulacje! Dotarłeś do końca wpisu. Parę linii niżej są gwiazdki, gdzie możesz go ocenić. Zrób to!
Dodaj komentarz Trackback URI RSS komentarzy
1.
Zal napisał(a):
17 czerwca 2009, 18:58:42
Ten /tmp oraz swap to w sumie nie taki duży problem. Nic nie stoi na przeszkodzie, aby były one szyfrowane przy pomocy DM-Crypt + LUKS. Chociaż faktycznie - w przypadku paranoicznego podejścia można uznać, że to właśnie przed użytkownikami systemu chcemy się ustrzec ;]
A co do samego szyfrowania katalogu domowego i EncFS - bajer! Podoba mi się to bardzo. Właśnie takiego rozwiązania oczekiwałem dla systemów, gdzie szyfrowanie całej partycji nie jest wyjściem :D
2.
ripper napisał(a):
17 czerwca 2009, 19:22:54
Ale ssh bez kluczy to słabo trochę...
A jak jest przy zostawieniu sesji screena? Czy wszystko działa jak na normalnym shellu czy utnie wszystko po wylogowaniu się z ssh?
3.
Sławek napisał(a):
17 czerwca 2009, 21:28:08
Co do normalnego hasła, to przy szyfrowaniu całego katalogu można z niego zrezygnować.
4.
lolek napisał(a):
18 czerwca 2009, 13:01:45
Ze stosowania automontowania przy logowaniu wynika oczywisty problem - będzie można po prostu złamać hasło z /etc/shadow, żeby uzyskać dostęp do danych. No ipamiętajcie o http://xkcd.com/538/ :P
5.
rozie napisał(a):
18 czerwca 2009, 15:10:14
lolek: Oczywiście, można próbować łamać hasło z /etc/shadow (o ile cały FS nie jest szyfrowany - patrz co Zal napisał w pierwszym komentarzu), ale jakie to ma szanse powodzenia w skończonym czasie (i dla jakiej funkcji skrótu?). Poza tym, nic nie stoi na przeszkodzie, by użytkownik miał w katalogu domowym katalog szyfrowany innym hasłem (już nie montowany automagicznie, niestety - coś za coś).
Jeśli chodzi o rubber hose method, to oczywiście, działa. Ale to już jest bezpieczeństwo fizyczne i wykracza nieco poza temat tego posta. ;)
6.
Karol "Zal" Zalewski napisał(a):
20 czerwca 2009, 15:05:30
Kryptografia w służbie wolności
Spoglądam na to, co dzieje się wokół mnie i nie mogę uwierzyć w to, co widzę. Obawiam się, że tam, gdzie wkracza dostatecznie rozwinięta technologia, pojawia się wiele problemów z którymi ludzie nie są w stanie sobie poradzić. I to ty[...]
7.
Anonim napisał(a):
22 czerwca 2009, 16:21:09
Teraz to rządzi tylko ecryptfs. https://launchpad.net/ecryptfs.
8.
zwierzak napisał(a):
27 grudnia 2009, 01:11:22
Sam encfs jest dla mnie dużo lepszym rozwiązaniem niż jakiekolwiek jednoplikowe szyfrowania. Jego podstawowa zaleta to brak konieczności deklaracji ile będą zajmować nasze dane, co jest niezwykle przydatne w wypadku wieloużytkownikowych systemów. Nie przeszkadza mi problem jawnego stwierdzenia uprawnień plików lub w miarę dokładnego odwzorowania długości pliku, bo jak dla mnie nie są to kwestie bezpieczeństwa. Co napastnika obchodzi, że 4 pliki na 284 spotkanych posiada uprawnienia 760, a pozostałe 640? Co go obchodzi, że jakiś plik nazywa się JrsdgUvfd;33fs3 skoro tej nazwy nie może rozszyfrować bez znajomości hasła? A to, że w tym pliku ważącym dokładnie 702,5MiB znajduje się świeżo pobrany film lub jakiś ważny dokument państwowy nie zdradzi jego zewnętrzne atrybuty, tylko środek. Najważniejsza jest zawartość pliku, która jest bezpieczna dzięki zaszyfrowaniu jej. I jak dla mnie nazwy plików mogą być w 100% jawne, a szyfrowanie by sprawdziło się tak samo. Część osób stosuje podobny sposób nazewnictwa plików do ukrywania swojego porno na dysku, gdzie folder z filmikami przyrodniczymi nosi nazwę w stylu: "Zdjęcia z wesela wujka Staśka" co jak dla mnie niewiele różni się od nazwy "HcfdHdWY22d9;!".
A mnie zastanawia treść aktualności tego rozwiązania. Najnowsza wersja encfs pochodzi z września 2008 roku i nie wiem czy jest to spowodowane porzuceniem programu przez developerów czy skończeniem prac nad nim (nie ma co w nim już poprawiać, bo jest wystarczająco dobry i stabilny do codziennego użytku).
Odnośnie samego pam_encfs to lepszym rozwiązaniem jest dla mnie pam_mount, który utrzymuje montowanie dysku twardego dopóki jakakolwiek sesja użytkownika jest utrzymywana (czyli nie trzeba się tylko zalogować i wylogować, trzeba także ubić wszystkie screeny). Jest to co prawda słaby punkt, bo wystarczy dobrać się do kompa póki jest włączony, ale jest to tak samo słaby punkt jak ten z podmianą niektórych plików w celu zrzucania treści hasła do pliku.
9.
rozie napisał(a):
27 grudnia 2009, 11:14:16
Jeśli chodzi o aktualność, to cóż... Ostatnia wersja faktycznie jest ze września zeszłego roku. Szybki rzut oka na błędy pokazuje, że niewiele jest otwartych i są świeżo zgłaszane. Rzut oka do SVN wypada gorzej - tylko jeden commitujący (nie lubię jednoosobowych projektów, zwł. związanych z security), co prawda ostatnie commity z tego miesiąca, ale blisko roczna przerwa.
Co prowadzi do szybkiego wniosku, że projekt jest dojrzały, ale raczej na wymarciu i nie można spodziewać się nowych funkcjonalności. Z drugiej strony, znam parę osób, które z tego korzystają i chwalą, obecna funkcjonalność jest b. ciekawa, a sama architektura jest taka, że większe zmiany raczej nie będą potrzebne. Czyli encfs wygląda na używalny minimum przez najbliższe 3-5 lat.