Ostatnio próbowałem zaktualizować obraz TWRP recovery dla jednego z moich telefonów. Ja generalnie buduje te obrazy ze źródeł OMNI ROM, a tam jest dostępnych szereg gałęzi, np. 6.0, 7.1, 8.1 , etc, które naturalnie pasują do odpowiadających im wersji Androida. Do tej pory budowałem w oparciu o gałąź 7.1 ale po wydaniu polecenia repo sync , szereg aktualizacji w stosunku do repozytorium bootable/recovery zostało pobranych, w tym też i jedna trefna, która uwalała proces kompilacji. Ostatecznie udało się problem namierzyć i zlikwidować ale w międzyczasie próbowałem zbudować obraz TWRP recovery z gałęzi 8.1. Wygląda na to, że im nowszy Android, tym obrazy recovery rosną w objętość i 16M, które u mnie jest limitem, zostało przekroczone o jakieś 500K i to przy najbardziej okrojonej funkcjonalności trybu recovery. Czy istnieje jakieś rozwiązanie, które by umożliwiło zmniejszenie rozmiaru obrazu ramdisk-recovery.img , co przełożyłoby się również na wagę pliku recovery.img ? Tak, trzeba tylko zmienić rodzaj kompresji z domyślnego gzip na lzma.

Bawiąc się ostatnio na Debianie przestrzeniami nazw sieciowych, wpadł mi do głowy pomysł na nieco bardziej zautomatyzowaną formę separacji procesów użytkownika od pozostałej części systemu. Co by nie mówić, opisany w podlinkowanym artykule sposób uruchomienia Firefox'a niezbyt mi przypadł do gustu. Nowy sposób separacji zakłada za to wykorzystanie kontenerów Docker'a, w których to będzie uruchamiany dowolny proces, np. Firefox, a całym przedsięwzięciem związanym z procesem konteneryzacji będzie zajmował się już Docker. W ten sposób uruchomienie dowolnej aplikacji, w tym też tych graficznych (GUI), będzie sprowadzać się do wydania w terminalu tylko jednego polecenia. Zatem do dzieła.

Jeśli mamy smartfon z Androidem na pokładzie, to zapewne każdy za nas zadawał sobie pytanie, czy da radę z takiego telefonu pozbyć się szeregu aplikacji, z których praktycznie nie korzystamy na co dzień. Część z tych programów można wyłączyć w ustawieniach systemowych ale są też i takie aplikacje (głównie producenta telefonu, czy też operatora GSM albo te od Google), których standardowo nie da się wyłączyć z poziomu działającego Androida. Nawet jeśli wymusimy zatrzymanie stosownych usług, to za chwilę (lub po restarcie urządzenia) one i tak nam automatycznie wystartują. Im więcej zbędnych aplikacji działa w tle, tym częstsze wybudzanie telefonu, a więc i szybsze wyczerpywanie się baterii. Dlatego też jeśli nie korzystamy z wbudowanego w ROM bloatware, to przydałoby się go usunąć lub chociaż trwale wyłączyć. Co ciekawe, tego typu proces nie musi odbywać się za sprawą administratora systemu (root), bo w zasadzie każda aplikacja w Androidzie może zostać zainstalowana/odinstalowana dla konkretnego użytkownika w systemie. Nie potrzebujemy mieć zatem nawet ukorzenionego Androida, by pozbyć się tego całego syfu z systemu, który naszemu urządzeniu spędza sen z powiek i nie daje mu się przy tym porządnie wyspać.

Bawiąc się ostatnio kernelem linux na dystrybucji Debian i opcjami mającymi poprawić jego bezpieczeństwo, włączyłem sobie mechanizm podpisywania modułów. W ten sposób żaden zewnętrzny moduł nie zostanie załadowany przez jądro operacyjne, no chyba, że taki moduł będzie podpisany przez ten sam klucz co i kernel. Zdziwiłem się odrobinę, gdy moim oczom pokazał się hash md4 w wyjściu polecenia modinfo . Jak się okazało później, to niezbyt dokładne zinterpretowanie wiadomości PKCS#7 przez kmod było (i nadal jest) wynikiem błędu obecnego w tym pakiecie od już paru lat. W efekcie modinfo nie jest w stanie zweryfikować tej sygnatury, a w moim umyśle zaistniało pytanie: czy istnieje w ogóle możliwość manualnego sprawdzenia czy ta sygnatura jest w porządku? Kernel co prawda ten cały zabieg przeprowadza automatycznie ale przydałoby się ręcznie zweryfikować poprawność sygnatury modułu i przy okazji obadać sobie co tak naprawdę się dzieje podczas tego procesu.

Domyślnie każdy proces uruchomiony na linux (w tym przypadku Debian) dziedziczy swoją przestrzeń nazw sieciowych (network namespaces) od procesu nadrzędnego, standardowo od procesu init (tego z pid 1). W takim przypadku, wszystkie procesy współdzielą tę samą przestrzeń nazw sieciowych, przez co mają dostęp do tych samych interfejsów sieciowych, tych samych tras routingu, a reguły firewall'a czy ustawienia serwerów DNS w jednakowym stopniu dotyczą wszystkich procesów i zmieniając sieciową konfigurację systemu robimy to globalnie dla wszystkich tych procesów jednocześnie. Czasami tego typu mechanika działania sieci nie jest zbyt pożądana z punktu widzenia bezpieczeństwa lub też prywatności użytkownika. Przykładem mogą być przeglądarki internetowe, np. Firefox, Opera czy Google Chrome/Chromium, które mogą zdradzić nasz lokalny adres IP (w przypadku stosowania NAT). Jako, że też zostawiamy wszędzie nasz namiar w postaci zewnętrznego adresu IP, to oba te adresy mogą nas bez większego problemu zidentyfikować w internecie. Można jednak postarać się, by ten adres lokalny, który zwróci przeglądarka internetowa, różnił się od tego, który przydziela nam nasz operator ISP.

Do tej pory zbytnio nie interesowałem się zagadnieniami dotyczącymi mechanizmu SafetyNet, który ma na celu utrudnić nieco życie użytkownikom smartfonów z Androidem lubiącym posiadać pełny dostęp do systemu swoich urządzeń za sprawą uzyskania praw administratora (root). To co się zmieniło na przestrzeni ostatnich paru miesięcy, to fakt, że coraz więcej aplikacji polega na tym całym SafetyNet, a przynajmniej ja zaczynam coraz częściej korzystać z tego typu oprogramowania. Jeśli jednak nasze urządzenie nie przejdzie testów SafetyNet, to funkcjonalność aplikacji polegających na tym mechanizmie może zostać dość znacznie ograniczona. Przykładem może być appka Revolut i jej odblokowanie za pomocą czytnika linii papilarnych. Bez SafetyNet trzeba podawać PIN za każdym razem, gdy się do tej aplikacji będziemy próbowali zalogować. Zwykle do obejścia SafetyNet używa się Magisk'a ale w pewnych sytuacjach, nawet i on nie jest w stanie z tym zdaniem sobie poradzić, przynajmniej nie bez dodatkowej konfiguracji. Jeśli na co dzień korzystamy z opcji debugowania ADB/USB, to może nas spotkać nie lada dylemat -- ADB/USB debug vs. SafetyNet. Okazuje się, że można pogodzić te dwie rzeczy.

Budując kernel linux'a trzeba zastanowić się nad kwestią modułów, które nie są wbudowane bezpośrednio w samo jądro operacyjne. Nie chodzi tutaj bezpośrednio o funkcjonalność kernela, którą można zbudować jako moduł w procesie jego kompilacji ale raczej o wszystkie zewnętrzne moduły, które przez zespół kernela są traktowane jako out-of-tree . By poprawić nieco bezpieczeństwo związane z takimi modułami, można wdrożyć podpisy cyfrowe, które takie moduły muszą okazać podczas próby załadowania ich w systemie. Gdy moduł nie został podpisany, to kernel go nie załaduje zwracając przy tym błąd modprobe: ERROR: could not insert 'module': Required key not available . W ten sposób można ochronić się przed częścią ataków, w których moduły pochodzenia trzeciego mogą zostać załadowane i poczynić nam ogromne spustoszenie w systemie. Problem w tym, że w dystrybucji Debian wykorzystywany jest mechanizm DKMS (Dynamic Kernel Module Support). Może i mamy dzięki niemu możliwość instalacji w systemie całej masy dodatkowych modułów ale ich również nie będzie można załadować, bo nie zostały podpisane kluczem, którego certyfikat został zaszyty w kernelu. Można jednak zmusić mechanizm DKMS, by wskazane przez nas moduły podpisywał automatycznie przy ich instalacji i aktualizacji.

Każda maszyna działająca pod kontrolą dystrybucji linux ma na swoim pokładzie kernel, czyli jądro operacyjne, które zarządza praktycznie każdym aspektem pracy takiego komputera. W dystrybucji Debian, kernel jest dostarczany w pakietach mających nazwy zaczynające się od linux-image-*. Te pakiety są budowane przez odpowiednie osoby z zespołu Debiana i udostępniane do łatwej instalacji użytkownikowi końcowemu. Niemniej jednak, taki kernel ma za zadanie działać na jak największej ilości komputerów, a przez to posiada całą masę modułów, które na naszej maszynie nigdy nie będą wykorzystane. Ten fakt nie wpływa w jakimś ogromnym stopniu na pracę maszyny, ale gdy później zachodzi potrzeba skonfigurowania kernela w nieco inny sposób, np. włączenie jednej czy dwóch opcji czy też nałożenie patch'a, który nie został zaaplikowany przez dev'ów Debiana, to trzeba taki kernel na nowo skompilować już samodzielnie, a to zajmie nam bardzo dużo czasu. Zamiast tego można pokusić się o przygotowanie kernela pod konkretny hardware wyłączając przy tym całą masę zbędnych rzeczy i ograniczając przy tym czas jaki jest potrzebny na zbudowanie całego jądra operacyjnego. Czy istnieje jakiś prosty sposób, by taki kernel zbudować sobie samemu mając przy tym minimalną wiedzę co do opcji kernela, które mogą nas przysporzyć o ból... głowy? Okazuje się, że tak i w tym artykule prześledzimy sobie cały ten proces.

Parę dni temu dowiedziałem się o projekcie /e/. Z racji, że ten ROM jest dostępny na mój smartfon LG G4C (jeszcze nieoficjalnie), to postanowiłem go sobie wgrać i zobaczyć jak się będzie sprawował. Podczas testów nowego oprogramowania spróbowałem zaszyfrować partycję /data/ . Problem w tym, że po automatycznym zresetowaniu się systemu, urządzenie już nie chciało się uruchomić. Przez dłuższy czas widniało logo LG, a po chwili pojawił się czarny ekran z informacją "Kernel Crash" lub niebieski ekran z informacją "Subsystem Crash". Czy telefon w takiej sytuacji nadaje się jedynie do wyrzucenia?

Nie bawiłem się ostatnio Neffos'ami ale w końcu udało mi się doprowadzić szyfrowanie w X1 Max (i pewnie X1 też) do ładu. Dla przypomnienia, to w tych modelach najwyraźniej system zapomniał by pytać użytkownika o hasło podczas konfiguracji, a że partycja z danymi użytkownikami jest zaszyfrowana w standardzie (bez możliwości zmiany), to ustawiane jest domyślne hasło tj. default_password . W ten sposób z technicznego punktu widzenia wilk jest syty i owca cała, no bo użytkownik nie jest dręczony dodatkowym hasłem przy uruchamianiu systemu (obok hasła blokady ekranu), no i dane są zaszyfrowane, no chyba, że ktoś wpisze ten nieszczęsny default_password .