Raczej na pewno spotkaliśmy się już z modułami kernela w linux'ie. Generalnie rzecz biorąc, taki moduł może być ładowany dynamicznie i w sporej części przypadków niezależnie, choć z zwykle jest pociągany przy zdarzeniach udev'a. Czasem jednak, dany moduł nie działa jak należy i może to być wynikiem, np. problemów w samym module, lub też jego niewłaściwej konfiguracji, która konfliktuje z podzespołami naszego komputera. Ten wpis będzie dotyczył tego jak ustalić parametry modułów i ich domyślne wartości, tak by móc je sobie zmienić w późniejszym czasie.

Jakiś czas temu opisywałem konfigurację dla menadżera pakietów apt i aptitude w pliku apt.conf. Ten wpis również tyczy się konfiguracji wspomnianych menadżerów, z tym, że zostanie tutaj opisana pewna funkcjonalność, która może nam zaoszczędzić trochę czasu przy aktualizacji systemu. Chodzi o to, że pakiety praktycznie zawsze muszą być pobrane na dysk przed ich instalacją. Gdy nie dysponujemy dobrym pod względem przepustowości łączem, proces pobierania pakietów jest zwykle dłuższy niż sama ich instalacja. Przydałoby się zatem zaprogramować pobieranie plików w tle, tak by nie musieć ich pobierać tuż przez przed procesem instalacyjnym.

Wykorzystywanie pełnego szyfrowania dysku twardego ma jedną zasadniczą wadę. O ile nasze dane są należycie zabezpieczone, o tyle trzeba zwracać uwagę na to komu zezwalamy na dostęp do naszego komputera. Nie chodzi tutaj o to, kto będzie używał samego systemu operacyjnego, choć to też jest ważne, ale przede wszystkim chodzi o te osoby, które mają dostęp fizyczny do naszej maszyny. Czasem możemy nabrać podejrzenia, że ktoś mógł nam jakąś pluskwę podłożyć. Wykrycie takiego robala, np. w postaci sprzętowego keylogger'a, nie powinno sprawić problemów. Z kolei już manipulacja boot sektorem dysku twardego, lub też zmiany w initramfs, który znajduje się na niezaszyfrowanej partycji /boot/ mogą przejść niezauważone. Jak zatem odratować system, co do którego mamy jakieś zastrzeżenia?

Linux jest w stanie operować na wielu systemach plików, np. ext4, ntfs, fat. Większość z nich odnosi się do dysków twardych, czy też innych urządzeń przechowujących spore ilości danych. Problem z tego typu systemami plików jest taki, że operacje na plikach w ich obrębie, jak i same pliki, zostawiają ślady. Dlatego też jeśli musimy tymczasowo skopiować plik zawierający tajne dane, lub też taki plik poddać obróbce, nie powinniśmy go umieszczać bezpośrednio na dysku. No chyba, że wykorzystujemy pełne szyfrowanie. Inną opcją (i o wiele prostszą w implementacji) jest przeznaczenie części pamięci operacyjnej RAM pod system plików tmpfs i o tym będzie ten wpis.

Ogarnęliśmy już szyfrowanie plików na Dropbox przy pomocy encfs oraz kontenerów TrueCrypt. Każda z w/w operacji drastycznie poprawiła prywatność naszych plików, które przechowujemy w chmurze. Poniższy wpis będzie w podobnym klimacie, tj. spróbujemy umieścić na Dropbox kontener LUKS, co niesie ze sobą sporo udogodnień i czyni korzystanie z zaszyfrowanego Dropbox'a praktycznie transparentnym.

Żyjemy w czasach, w których mobilność jest tak samo ważna albo może i ważniejsza (dla niektórych ludzi na pewno) jak i bezpieczeństwo i poufność danych. Użyteczność zwykle nie idzie w patrze z bezpieczeństwem, bo im prostszy jest dla nas dostęp do danych, tym bardziej zagraża ich bezpieczeństwu. W tym przypadku chcielibyśmy mieć możliwość dostępu do plików, np. naszego domowego PC, z dowolnego miejsca na ziemi. Czy można w prosty i w miarę bezpieczny sposób coś takiego osiągnąć? Jakiś czas temu opisywałem implementację encfs na dropbox'ie, w tym artykule zostanie zaś opisane sprzęgnięcie dropbox'a z kontenerem TrueCrypt.

Jakiś czas temu, można było usłyszeć, że TrueCrypt nie dba wcale o bezpieczeństwo danych zaszyfrowanych za jego pomocą. Audyt bezpieczeństwa jednak nie wykazał większych podatności w tym oprogramowaniu. Analiza binarek dostępnych na stronie TrueCrypt'a pod kątem Reproducible Builds również nie wykazała większych odchyłów w stosunku do binarek generowanych prosto z kodu źródłowego. Problematyczne może być jednak to, że tak naprawdę nie wiadomo kto stoi za tym całym projektem, przynajmniej gdy był jeszcze rozwijany. Cała sytuacja zamknięcia TrueCrypt'a z sieci była też co najmniej dziwna. W obliczu takich niewiadomych, powinniśmy rozważyć przejście na natywne rozwiązania linux'owe, które są jawnie rozwijane, wiadomo kto za nimi stoi i, co najważniejsze, mają wsparcie w samym kernelu.

Jako, że ostatnio zaszyfrowaliśmy katalog domowy przy pomocy encfs , to nie sposób sobie nie zadać pytania czy tego typu mechanizm może działać w oparciu o serwisy online takie jak, np. dropbox. Chodzi o to, że dropbox umożliwia synchronizację plików w czasie rzeczywistym, co może być problematyczne, gdy w grę wchodzi szyfrowanie danych. Wszelkie inne rozwiązania na bazie LUKS są mało praktyczne w tym przypadku. Natomiast synchronizowanie pojedynczych plików zaszyfrowanych przy pomocy encfs zapowiada się obiecująco.

Opisując mechanizm szyfrowania katalogu domowego przy pomocy narzędzia encfs , wspomniałem o problemie jaki powstaje przy jednoczesnym braku szyfrowania przestrzeni wymiany SWAP. Oczywiście, jeśli posiadamy w systemie dużą ilość pamięci RAM, to raczej nie potrzebna nam jest przestrzeń wymiany. Podobnie sprawa ma się w przypadku, gdy nie korzystamy z hibernacji. Natomiast, jeśli jedna z naszych partycji jest sformatowana jako SWAP i aktywnie z niej korzystamy, to niepełne szyfrowanie dysku, jakie zapewnia encfs może doprowadzić do skompromitowania zaszyfrowanych danych.

Wielu ludzi uważa, że szyfrowanie całego dysku jest zbędne i pozbawione większego sensu, no bo przecie "system nie zawiera żadnych wrażliwych danych, które by wymagały szyfrowania". Nie będę się tutaj spierał co do tego punktu widzenia, bo raczej wszyscy znają moje zdanie na temat "danych wymagających szyfrowania" i skupię się tu raczej na tym jak troszeczkę podratować niepełne szyfrowanie, które ludzie, nie wiedząc czemu, są bardziej skłonni stosować, niż cały ten full disk encryption.

Narzędzie encfs nie przeszło pomyślnie audytu bezpieczeństwa, a to z takiego powodu, że projekt nie był rozwijany przez szereg lat. Obecnie jest on w rekach społeczności i to od niej będzie zależeć czy te wykryte błędy zostaną poprawione.