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.

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.

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.

Ostatnio na polskim forum linux mint pojawił się wątek, w którym jeden z użytkowników miał problem z ogarnięciem podświetlania klawiatury. Chodzi generalnie o start komputera z włączonym backlight'em klawiatury, przez co trzeba to podświetlenie manualnie wyłączać za każdym razem po uruchomieniu się systemu. W przypadku mojego laptopa Lenovo ThinkPad T430, taka sytuacja co prawda nie występuje i system uruchamia się naturalnie ze zgaszoną klawiaturą. Niemniej jednak, zainteresował mnie ten problem tyle, że w drugą stronę -- chodzi o możliwość startu systemu z włączonym podświetleniem klawiatury, bo ustawienia BIOS/EFI/UEFI mojego laptopa tego aspektu pracy komputera nie są w stanie w żaden sposób skonfigurować. Okazało się, że zaimplementowanie tego typu funkcjonalności nie jest jakoś specjalnie trudne i można bez większego trudu ogarnąć backlight klawiatury przy pomocy prostej reguły dla UDEV'a.

Mając możliwość skonfigurowania EFI/UEFI na moim laptopie, postanowiłem jak najbardziej się za to przedsięwzięcie zabrać. Okazało się jednak, że w przypadku takiej dystrybucji linux'a jak Debian, to zadanie może być nieco problematyczne, zwłaszcza gdy chce się korzystać jedynie z menadżera rozruchu jakim jest rEFInd, czyli bez dodatkowego bootloader'a (grub/grub2/syslinux/extlinux) instalowanego bezpośrednio na dysku twardym i jednocześnie posiadając w pełni zaszyfrowany system (LUKSv2 + LVM). Rzecz w tym, że w takiej sytuacji w konfiguracji rEFInd trzeba podawać ścieżki bezpośrednio do plików initrd.img oraz vmlinuz (obecnych na partycji /boot/ ). W Debianie nazwy tych plików mają format initrd.img-x.x.x-x-amd64 i vmlinuz-x.x.x-x-amd64 . Za każdym razem, gdy wypuszczany jest nowy kernel, to ten numerek ( x.x.x-x ) ulega zmianie, co pociąga za sobą potrzebę ręcznego dostosowania konfiguracji rEFInd. Może i aktualizacje kernela w Debianie nie są jakoś stosunkowo częste ale może istnieje sposób, by ten problem z dostosowaniem konfiguracji rozwiązać?

Zapewne wielu użytkowników Debiana zdążyło już zauważyć, że od wydania 10 (Buster), AppArmor jest włączony domyślnie. Nie powinien on raczej sprawiać żadnych problemów po doinstalowaniu pakietów apparmor-profiles oraz apparmor-profiles-extra , które zawierają szereg profili pod różne aplikacje użytkowe. Niemniej jednak, pewnych procesów nie da się ograniczyć przez AppArmor, przynajmniej nie w standardowy sposób. Chodzi o to, że jeśli mamy już odpalony jakiś proces, to nie ma możliwości zamknąć go w profilu AA do momentu aż zakończy on swoje działanie i zostanie uruchomiony ponownie. Profile AppArmor'a są ładowane podczas startu systemu w pewnym określonym momencie ale szereg procesów systemowych startuje sporo wcześniej w stosunku do usługi AppArmor'a. W taki sposób nawet jeśli w późniejszym czasie profile zostaną załadowane, to i tak część procesów nie będzie ograniczona bez względu na to czy zdefiniowaliśmy im zestaw reguł. Oczywiście można próbować restartować usługi lub szeregować je po apparmor.service ale nie zawsze tak się da zrobić. Alternatywnym rozwiązaniem tego problemu jest ładowanie polityki AppArmor'a w fazie initrd/initramfs, czyli w momencie, w którym nasz system nie ma jeszcze nawet uruchomionego procesu z PID z numerkiem 1 .

Podczas instalowania jądra operacyjnego w jakiejś dystrybucji linux'a, w katalogu /boot/ jest tworzonych kilka plików. Mamy tam między innymi initrd.img i jest to obraz posiadający swój własny system plików, który jest ładowany do pamięci RAM w fazie boot (via bootloader). W tym obrazie znajdują się moduły i narzędzia, przy pomocy których to główny system plików naszego linux'a może zostać zamontowany. Czasem jednak potrzebujemy zajrzeć wgłąb tego obrazu, a to nie jest znowu taka prosta sprawa.