Dkms on Morfitronik

Moduł LKRG (Linux Kernel Runtime Guard)

Mikhail Morfikov — Tue, 09 Jun 2020 20:56:00 +0000

Jakiś czas temu opisywałem moduł TPE (Trusted Path Execution) dla kernela linux, który jest w stanie dość znacznie poprawić bezpieczeństwo naszego systemu. Ostatnio jednak natknąłem się na moduł LKRG (Linux Kernel Runtime Guard), którego to zadaniem jest stać na straży samego jądra operacyjnego i chronić je w czasie rzeczywistym przed różnego rodzaju zagrożeniami poprzez wykrywanie eksploitów wykorzystujących luki w jego mechanizmach bezpieczeństwa. Jako, że ja bardzo lubię zbroić swojego Debiana, to postanowiłem się przyjrzeć nieco bliżej temu całemu LKRG i sprawdzić jego użyteczność. Trzeba jednak wiedzieć, że LKRG jest dostarczany w formie osobnego modułu zamiast łaty na kernel, przez co trzeba będzie także postarać się o automatyzację pewnych rzeczy, m.in. procesu budowania modułu przy aktualizacji kernela via DKMS.

Jak na Debianie zrobić pakiet .deb zawierający moduł kernela linux (DKMS)

Mikhail Morfikov — Sun, 17 Mar 2019 09:37:28 +0000

Kernel linux'a jest dość złożonym organizmem, który może zostać rozbudowany przy pomocy dodatkowego kodu ładowanego w postaci zewnętrznych modułów. Czasem ze względu na wczesny etap prac nad nową funkcjonalnością jądra, taki moduł może zachowywać się dość nieprzewidywalnie, co przekreśla jego szanse na pojawienie się w stabilnych wydaniach kernela. Czasem też z jakiegoś niezrozumiałego powodu pewne rzeczy nie są celowo dodawane do jądra operacyjnego. Jedną z nich jest moduł Trusted Path Execution (TPE), który jest w stanie znacznie poprawić bezpieczeństwo systemu uniemożliwiając przeprowadzenie w nim szeregu podejrzanych działań. W Debianie tego typu niedogodności związane z brakiem pewnych modułów można obejść przez zastosowanie mechanizmu DKMS, który przy instalacji modułu spoza głównego drzewa kernela linux'a jest nam go w stanie automatycznie zbudować. W repozytorium dystrybucji Debiana znajduje się już szereg pakietów z modułami (mają końcówki -dkms ) i w prosty sposób można je sobie doinstalować. Co jednak w przypadku, gdy mamy moduł, którego nikt jeszcze nie przygotował i nie wrzucił do repozytorium? Co, gdy takich modułów mamy kilka, a przy tym korzystamy z najnowszego stabilnego kernela, który jest aktualizowany średnio co kilka dni? Ręczna budowa wszystkich zewnętrznych modułów za każdym razem jak tylko wyjdzie nowsza wersja kernela, to nie najlepsze wyjście, zwłaszcza jak dojdzie nam do tego aktualizacja samych modułów. Można za to zrobić sobie paczkę .deb tak, by przy instalacji nowego jądra operacyjnego, system nam automatycznie zbudował wszystkie dodatkowe moduły, których nasz komputer wymaga do poprawnej pracy.

Automatyczne podpisywanie modułów kernela przez DKMS

Mikhail Morfikov — Sat, 05 Jan 2019 04:10:10 +0000

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.

Sterowniki dla karty WiFi Archer T1U (mt7610u_sta)

Mikhail Morfikov — Thu, 18 Aug 2016 14:35:52 +0000

Dziś postanowiłem się wziąć za ostatnią kartę WiFi, którą podesłał mi TP-LINK. Jest to nano adapter Archer T1U V1 na czipie MediaTek MT7610U identyfikowany w systemie jako idVendor=2357 , idProduct=0105 . Na opakowaniu pisało, że ta karta działa na linux'ach ale oczywiście w przypadku mojego Debiana, ten adapter nie został w ogóle wykryty. Winą są zbyt stare sterowniki, które nie zostały zaktualizowane przez MediaTek od 2013 roku. TP-Link może i ma u siebie na stronie nieco nowszą wersję sterowników, bo z 2015 roku ale nie udało mi się za ich sprawą zbudować poprawnie modułu mt7610u_sta na kernelu 4.6 . Na szczęście mamy jedną alternatywę, która pomoże nam jako tako wybrnąć z tej sytuacji.

Sterowniki do karty TP-LINK TL-WN823N (8192eu)

Mikhail Morfikov — Fri, 12 Aug 2016 20:50:39 +0000

Systemy operacyjne nie są w stanie wejść w interakcję ze sprzętem, do którego nie posiadają sterowników. Linux już od dość dawna żyje sobie wśród nas i coraz bardziej pcha się na desktopy. Niemniej jednak producenci tych wszystkich urządzeń niechętnie wypuszczają sterowniki dla alternatywnych systemów. Ostatnio próbowałem uruchomić adapter TL-WN823N V2 od firmy TP-LINK. Na opakowaniu widnieje napis sugerujący, że ta karta działa pod linux'em. Rzeczywistość jednak okazała się zupełnie inna. Mianowicie, mój Debian w ogóle nie rozpoznał tej karty. Jedyne informacje jakie mi zwrócił to nazwę producenta czipu, którym okazał się być Realtek , oraz idVendor=2357 i idProduct=0109 . Sterowników dostępnych na stronie TP-LINK'a nie szło zbudować na obecnym kernelu 4.6 . Trzeba było zatem poszukać innej alternatywy. Na szczęście udało się znaleźć moduł 8192eu (rtl8192eu), który się skompilował i zainstalował bez problemu. Karta TL-WN823N V2 została wykryta i działa. W tym wpisie zostanie pokazany proces kompilacji tego modułu.

Sterowniki do karty TP-LINK Archer T4U (8812au)

Mikhail Morfikov — Tue, 23 Jun 2015 11:45:07 +0000

Póki co, w kernelu linux'a (4.5) nie ma odpowiednich sterowników do adaptera WiFi Archer T4U i trzeba je sobie skompilować ręcznie. Trochę to dziwne, bo przecie kod sterownika jest na licencji GPLv2 i dostępny już szmat czasu na github'ie. W każdym razie, jeśli zakupiliśmy w/w kartę i nie jest ona wykrywana po wsadzeniu jej do portu USB, to czeka nas proces kompilacji modułu 8812au i jego automatyzacja przy pomocy mechanizmu DKMS.

DKMS, czyli automatycznie budowane moduły

Mikhail Morfikov — Sat, 30 May 2015 21:05:27 +0000

Jeśli zamierzamy kupić sprzęt, który dopiero co trafił na półki w sklepach, to prawdopodobnie zaraz po podłączeniu go do naszego komputera okaże się, że to urządzenie nie jest nawet wykrywane przez system operacyjny. W przypadku gdy jego producent zapewnia w miarę przyzwoity support, to być może problemy, których doświadczamy, zostaną rozwiązane wraz z instalacją najnowszego kernela. Co jednak w przypadku gdy nawet po aktualizacji kernela nie jesteśmy w stanie odpalić, np. nowo zakupionej karty WiFi? Jako, że te wszystkie sprzęty działają w oparciu określone moduły, wystarczy taki moduł pozyskać, skompilować i załadować w systemie. Problem w tym, że z każdą nową wersją jądra operacyjnego, która trafi do repo debiana, będziemy musieli ręcznie budować moduł na nowo i właśnie w tym artykule opiszę jak nauczyć system, by sam przeprowadzał tę mozolną czynność bez naszego udziału.