W obecnych czasach powoli się odchodzi od stosowania technologi flash w przeglądarkach. Na dobra sprawę, po tym jak google w youtube przesiadł się na html5, to korzystanie z flash player'a nie ma już większego sensu. Są jednak serwisy, które nie nadążają za zmieniającą się rzeczywistością i w ich przypadku przejście z flash'a na html5 może jeszcze zająć kilka lat. Zatem nawet jeśli nie korzystamy z flash'a na co dzień, to i tak większość z nas będzie chciała go mieć w systemie, tak na wszelki wypadek, by nie być pozbawionym możliwości oglądania materiałów video na tych drugorzędnych serwisach. Jako, że wtyczka flash jest bardzo dziurawa, przydałoby się ją nieco skonfigurować i w tym wpisie zostanie przedstawionych szereg opcji, które można umieścić w pliku mms.cfg .

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.

Jakiś czas temu natknąłem się na moduł pam-usb , który to w dość ciekawy sposób zabezpiecza dostęp do konta użytkownika root. Cały mechanizm opiera się o pendrive, którego to unikalne cechy są brane pod uwagę przy uwierzytelnianiu podczas logowania się na konto super użytkownika, czyli min. gdy wydajemy polecenie su albo sudo . Jest to o tyle ciekawa rzecz, że konto użytkownika root możne stać się niewrażliwe na próby złamania hasła w przypadku połączenia sieciowego. Jak by nie patrzeć, atakujący, który łączy się zdalnie, nie jest w stanie podłączyć do naszego komputera żadnego fizycznego urządzenia, w wyniku czego nigdy nie uzyska dostępu do konta administratora.

Pakiet libpam-usb wyleciał z debiana jakiś czas temu. Powodem były zależności, które wskazywały na przestarzały już pakiet udisks . Poza tym, nikt nie zajmował się tym pakietem. Obecnie jest on dostępny jedynie w starszych wydaniach debiana.

Czytając sobie artykuł na temat TORyfikacji zapytań do serwerów kluczy GPG, pomyślałem, że w sumie mógłbym zreprodukować przedstawione tam kroki dotyczące implementacji tego rozwiązania na windowsie i wdrożyć je na linux'ie. Chodzi generalnie o to, by serwer kluczy GPG nie był odpytywany bezpośrednio przy szukaniu/przesyłaniu kluczy przez sieć, bo to może identyfikować nas, jak i grupę ludzi, która się z nami komunikuje. Jakby nie patrzeć, klucze GPG składają się z dość newralgicznych informacji, typu imię, nazwisko czy adres email, a serwer kluczy GPG tych danych w żaden sposób nie zabezpiecza i są one zwykle przesyłane otwartym tekstem przez sieć.