Wsparcie dla WiFi w initramfs/initrd by odszyfrować LUKS przez SSH bezprzewodowo

W poprzednim artykule, który traktował o odszyfrowaniu kontenera LUKS przez SSH z poziomu initramfs/initrd na Raspberry Pi, została poruszona kwestia adresacji IP, która w opisanym tam rozwiązaniu miała pewne ograniczenia. Chodziło o to, że połączenie SSH do RPI mogło być realizowane jedynie przez przewodowy interfejs sieciowy eth0 . Trzeba było zatem się zastanowić nad rozwiązaniem, które umożliwiłoby korzystanie również z bezprzewodowego interfejsu WiFi, tj. wlan0 . Celem niniejszego wpisu jest pokazanie w jaki sposób można dorobić wsparcie dla połączeń WiFi w naszej malinie, tak by szło odszyfrować kontener LUKS przez SSH, w sytuacji gdy z jakiegoś powodu nie chcemy lub też nie możemy korzystać z przewodowego interfejsu sieciowego tego minikomputera z zainstalowanym system RasPiOS/Raspbian.

Odszyfrowanie LUKS przez SSH z poziomu initramfs/initrd na Raspberry Pi

Od paru dni bawię się swoim Raspberry Pi w kontekście zaszyfrowania jego systemu RasPiOS/Raspbian. O ile samo zaszyfrowanie tego minikomputera przy pomocy mechanizmu LUKS nie było jakoś specjalnie trudne, to trzeba było pomyśleć nad rozwiązaniami mającymi ułatwić otworzenie takiego zaszyfrowanego kontenera przy starcie systemu. Póki co udało się wypracować w miarę zadowalające rozwiązanie wykorzystujące dedykowane urządzenia USB w roli klucza, bez którego system się nie uruchomi. Są jednak i inne rozwiązania, które mogą nam pomóc odszyfrować system RPI bez potrzeby fatygowania się do pomieszczenia i wtykania w jej port USB jakiegoś pendrive. Mowa o zaprzęgnięciu usługi SSH, która by została uruchomiona w fazie initramfs/initrd, chwilę przed wpisaniem hasła do kontenera LUKS. Takie rozwiązanie wymaga jednak zainstalowania innego serwera SSH, tj. Dropbear, pogodzenia go z serwerem OpenSSH oraz też trzeba odpowiednio przygotować sam obraz initramfs/initrd. Po pomyślnym skonfigurowaniu systemu, będziemy się logować do Raspberry Pi przez SSH i wpisywać hasło do kontenera LUKS, a jeśli to hasło będzie prawidłowe, to system zostanie odszyfrowany i uruchomiony.

Wykorzystanie nośnika USB jako klucz do odszyfrowania Raspberry Pi (LUKS)

Ostatnio udało mi się zaszyfrować swojego Raspberry Pi 4B przez wdrożenie kontenera LUKS i upchnięcie w nim wszystkich danych z partycji / zainstalowanego w tym urządzeniu systemu RasPiOS/Raspbian. To jednak nie był koniec pracy, bo taki zaszyfrowany system na RPI ma szereg wad. Tym główniejszym uniedogodnieniem jest wpisywanie hasła na początku fazy boot, by pełny start systemu był w ogóle możliwy. Sytuacja się komplikuje, gdy do naszego minikomputera nie mamy podłączonego monitora i/lub klawiatury. Ten zaistniały problem można rozwiązać na kilka sposobów, np. przez zaprzęgnięcie do pracy dodatkowego nośnika USB w celu umieszczenia na nim pliku klucza (keyfile). Niemniej jednak, można pójść o krok dalej i wykorzystać samo urządzenie jako klucz i gdy takiego pendrive nie podłączymy do portu USB naszej maliny, to system nam się nie uruchomi. Te dwa rozwiązania są bardzo podobne do siebie ale to drugie jest nieco bardziej odporne na ewentualne problemy ze skasowaniem pliku klucza, co może nam się przytrafić, gdy taki pendrive jest wykorzystywany w roli regularnego nośnika danych przechowującego dla niepoznaki jakieś pliki. Tak czy inaczej oba te sposoby zostaną opisane w niniejszym artykule.

Jak zaszyfrować Raspberry Pi (RasPiOS/Raspbian, LUKS)

Ostatnio napisał do mnie pewien osobnik, który miał dość spory problem z zaszyfrowaniem swojego Raspberry Pi. Po wymianie kilku maili zacząłem tracić rozeznanie w całej tej sytuacji i doszedłem do wniosku, że najwyraźniej zaszyfrowanie systemu maliny nie jest rzeczą trywialną. Postanowiłem zatem rzucić okiem na swojego RPI i sprawdzić czy są tutaj faktycznie jakieś odstępstwa od tradycyjnego szyfrowania na bazie LUKS w stosunku do szyfrowania spotykanego w pierwszej lepszej dystrybucji linux'a, takiej jak Debian czy Ubuntu. Pobrałem więc ze strony Raspberry Pi najnowszy obraz systemu RasPiOS/Raspbian, wrzuciłem go na kartę SD przy pomocy dd i okazało się, że w zasadzie większych problemów z zaszyfrowaniem mojej maliny nie było. Przyznać trzeba, że informacje na temat szyfrowania RPI, które można spotkać na internetach, są w przeważającej większości bardzo słabej jakości i mam wrażenie, że pisane przez osoby, które nie do końca się zainteresowały poruszanym przez siebie zagadnieniem. Postanowiłem zatem na przykładzie mojego Raspberry Pi 4B opisać w miarę dokładny sposób od początku do końca jak przeprowadzić cały ten proces szyfrowania danych na karcie SD, którą podpinamy do naszego minikomputera.

Chroot do 32-bit systemu ARM z poziomu 64-bit linux'owego hosta

Eksperymentując ostatnio z moją maszynką Raspberry Pi 4B, zaszła potrzeba, by zejść do systemu RasPiOS/Raspbian przy pomocy mechanizmu chroot. Problem w tym, że system wyrzuca komunikat: chroot: failed to run command ‘/bin/bash’: Exec format error . Niby wszystko jest na swoim miejscu ale ta widoczna wyżej wiadomość nie chce zniknąć uniemożliwiając tym samym dalszą zabawę z RPI. Okazało się, że winna jest tutaj architektura CPU. Mój laptop działa pod kontrolą 64-bitowego Intel'owskiego procesora (x64, x86-64, AMD64), na którym uruchomiony jest również 64-bitowy Debian linux. Z kolei Raspberry Pi ma 64-bitowy procesor ARM (ARMv8-A) działający pod kontrolą 32-bitowego systemu operacyjnego. Te dość spore rozbieżności sprawiają, że nie damy rady skorzystać z chroot, przynajmniej nie bez zaprzęgnięcia do tego celu emulatora QEMU.

Drukowanie zeskanowanych dokumentów tekstowych na drukarce laserowej

Posiadacze monochromatycznych (czarnobiałych) drukarek laserowych zapewne spotkali się z problemem drukowania kolorowych dokumentów na tego typu urządzeniach. Nie chodzi tutaj o drukowanie obrazków czy innych elementów graficznych ale o wydrukowanie, np. zeskanowanej książki. Ostatnio przyszło mi wydrukować dokumentację techniczną dość starego urządzenia. Problem w tym, że nie był to zwykły kawałek książki, a jedynie jej skany, z których ktoś postanowił zrobić plik PDF . Takiego dokumentu "tekstowego" za bardzo nie da się wydrukować na drukarce laserowej, przynajmniej nie bez pchania się w ogromne koszty. Dla przykładu, w miejsce pożółkniętej kartki ze skanu, taka drukarka wstawi jakiś odcień szarości i w ten sposób zadrukuje tą szarością całą stronę marnując przy tym niesamowite ilości toneru, za który my będziemy musieli później zapłacić, co czyni cały proces drukowania zeskanowanych dokumentów bardzo kosztownym. Postanowiłem jednak znaleźć jakiś sposób, by tę dokumentację wydrukować, choć trzeba było pierw zająć się samymi skanami, tj. doprowadzić je do stanu, w którym można by mówić o ewentualnym ich wydrukowaniu. Okazało się, że nie jest to jakoś specjalnie trudne zadanie, zwłaszcza, gdy na linux zaprzęgnie się do tego celu ImageMagick.

Randomizacja adresów MAC WiFi w smartfonie z Androidem

Posiadacze smartfonów z Androidem w wersji 10+ rzadko kiedy orientują się, że w tej wersji został wprowadzony dość ciekawy mechanizm mający na celu poprawnie prywatności osób korzystających z takich urządzeń. Chodzi o randomizację adresów MAC przy połączeniach z sieciami WiFi. Nie zawsze ten mechanizm jest włączony domyślnie, przez co w kwestii prywatności użytkowników telefonów niewiele się zmienia, np. tak jest w przypadku mojego Xiaomi Redmi 9. Samo włączenie randomizacji MAC nie jest niczym skomplikowanym i nie trzeba do tego nawet praw administratora root (stosowna opcja jest do załączenia w oknie konfiguracji połączenia WiFi). Zwykle jednak przy wykorzystaniu standardowej randomizacji MAC mamy generowany unikalny adres MAC dla danej sieci WiFi (w oparciu o jej ESSID). Można jednak pójść o krok dalej i sprawić, że przy każdym połączeniu, nawet do tej samej sieci WiFi, będziemy mieli generowany inny adres MAC, co z kolei powinno nam zapewnić nieco więcej prywatności w publicznych sieciach WiFi oraz też przeciwdziałać śledzeniu nas przy roamingu między takimi sieciami.

Jak wyłączyć mapowanie adresów IPv4 na IPv6 w Debian linux

Przeglądając ostatnio połączenia w swoim telefonie z Androidem, natknąłem się na wpisy mające w swoich adresach źródłowych ustawione IP takie, jak ::ffff:192.168.1.188 . Podobnie sprawa wygląda w przypadku adresów docelowych tego samego połączenia, tj. widnieje tam np. ::ffff:216.58.215.1 . Na pierwszy rzut oka taka konstrukcja adresu IP przypomina IPv6, przynajmniej jej pierwsza część, tj. ::ffff: , natomiast drugi kawałek już bardzo przypomina adres IPv4. Okazuje się, że za taki format adresów IP odpowiada mechanizm mapowania adresów IPv4 na adresy IPv6. Nie jest to jednak tożsame z 6to4 czy 6in4, gdzie host ze stałym publicznym adresem IPv4 jest w stanie komunikować się z hostami nadającymi po IPv6. W przypadku mapowania adresów IPv4 na IPv6, połączenia ze zdalnymi hostami mogą odbywać się zarówno po IPv4 jak i IPv6, a to z którego z tych protokołów nasz linux skorzysta zależy od tego czy taka maszyna dysponuje przydzielonym adresem IPv6. Jeśli ISP nie zapewnia nam adresu IPv6, to wtedy pakiety sieciowe będą przesyłane z wykorzystaniem protokołu IPv4. Wciąż jednak te mieszane konstrukcje adresów IP będą widoczne na wykazie połączeń w netstat/ss . Okazuje się jednak, że ten mechanizm mapowania adresów może powodować szereg problemów związanych z bezpieczeństwem systemu. Dlatego też tam gdzie to możliwe przydałoby się go wyłączyć.

Komentarze GitHub Issues na blogu Hugo korzystającym z GitHub Pages

Jakiś czas temu Disqus wprowadził reklamy w swoim systemie komentarzy i bez mojej świadomej oraz dobrowolnej zgody serwował je użytkownikom odwiedzającym mojego bloga. W tamtym czasie nie miałem za bardzo informacji jak te komentarze zastąpić na statycznej stronie renderowanej przy pomocy Hugo. Jako, że sporo osób narzekało na to, że tutaj nie ma komentarzy, przez co liczba maili, które do mnie docierały, była trochę ponad moje moce przerobowe. Postanowiłem zatem zaimplementować system komentarzy oparty o GitHub Issues, czyli ten mechanizm, z którym prawdopodobnie każdy z nas miał już styczność zgłaszając bug'a (czy też inne zapytanie) twórcom swoich ulubionych linux'owych projektów OpenSource. Okazało się, że przy pomocy API GitHub'a można w dość prosty sposób te komentarze pokazać na blogu ale problem pojawił się w przypadku stron mających setki czy nawet tysiące wpisów już opublikowanych. Jak zatem na takich blogach wdrożyć komentarze GitHub'a, tak by przy okazji nie wyskoczyć z okna o 5 nad ranem?

Zmiana implementacji WebView z Google/AOSP na Bromite w Androidzie

Przeglądając ostatnio opcje deweloperskie w swoim telefonie z Androidem 11, wpadła mi w oczy pozycja WebView implementation . Nie ukrywam, że trochę mnie ona zainteresowała i zacząłem się zastanawiać czym tak naprawdę jest ten cały WebView. Mój smartfon działa aktualnie pod kontrolą crDroid (ROM na bazie AOSP/LineageOS) i nie jest on sprzęgnięty z usługami od Google (brak jakichkolwiek GAPPS'ów). Dlatego też w tym przypadku w implementacji WebView widnieje w zasadzie tylko jedna opcja, tj. Android System WebView. W przypadku stock'owych ROM'ów producentów telefonów będziemy mieli zaś do czynienia z Google System WebView. Jakby nie patrzeć, zarówno Android/AOSP System WebView, jak i Google System WebView pochodzą od Google, który niezbyt troszczy się o naszą prywatność. W mojej głowie pojawiło się zatem pytanie na temat tego czym te dwie implementacje się od siebie różnią, no i naturalnie też czy są jakieś alternatywne implementacje WebView, z których można by skorzystać zastępując te domyślnie preinstalowane?