Morfitronik Security & Privacy

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

2019-03-17 09:37:28
Morfik

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.

Parę słów na temat budowy pakietu .deb

Cały proces związany z budową pakietów .deb dla Debiana jest dość szerokim zagadnieniem i nie będę go omawiał w tym artykule szczegółowo. Kiedyś napisałem spory kawałek tekstu poświęcony właśnie zagadnieniu budowy paczek dla tej dystrybucji. Cała wiedza zawarta w tym podlinkowanym artykule nie jest jednak niezbędna do zbudowania prostej paczki .deb . Można pójść nawet na skróty i skorzystać z dpkg-buildpackage -b -us -uc . Jeśli jednak mamy już przygotowane środowisko pod pbuilder (w tym przypadku jest) i do tego jeszcze własne lokalne repozytorium na bazie reprepro (i to również jest), to ogarnięcie pbuilder‘a i budowanie paczek .deb za jego sprawą bardzo ułatwia życie. Zatem nie trzeba studiować tamtego poradnika by zrobić sobie pakiet z modułem DKMS. Niemniej jednak, jeśli podczas procesu budowy wystąpią jakieś błędy, to możemy nie być w stanie ich przezwyciężyć. Przydałoby się zatem chociaż pobieżnie tamten artykuł przeczytać.

W niniejszym artykule skupię się głównie na aspektach budowy pakietu związanych z mechanizmem DKMS i to te kwestie będą tutaj opisane bardziej szczegółowo. Cały proces zostanie przeprowadzony na przykładzie pakietowania modułu TPE.

Przygotowanie źródeł modułu kernela

Każdy moduł kernela ma swoje źródła, które musimy sobie pierw pozyskać. Tutaj sprawa jest prosta, bo projekt jest hostowany na GitHub’ie i wystarczy sklonować repozytorium w poniższy sposób:

$ git clone https://github.com/cormander/tpe-lkm tpe-2.0.3

Mając źródła, trzeba je zdebianizować. Ten proces polega na stworzeniu katalogu debian/ i uzupełnieniu w nim szeregu plików. Te pliki można tworzyć ręcznie ale lepiej jest zaprzęgnąć do pracy narzędzie dh_make , które znajduje się w pakiecie debhelper . Skorzystanie z dh_make będzie możliwe dopiero, gdy format nazwy katalogu będzie miał postać nazwapaczki-wersja .

W przypadku modułów DKMS ogromne znaczenie ma nazwa samego modułu. Nie możemy sobie dowolnie wybrać nazwy pakietu, bo nawet najdrobniejsza różnica w tych nazwach sprawi, że mechanizm DKMS nam tego modułu nie będzie potrafił zbudować.

Nazwę modułu najlepiej jest odczytać z pliku Makefile , który powinien się znajdować w głównym katalogu ze źródłami. W pierwszej linijce tego pliku mamy coś takiego:

MODULE_NAME := tpe

Dlatego nazwa katalogu, do którego klonowaliśmy repozytorium zaczyna się od tpe , po którym mamy numerek wersji 2.0.3 . Ta nazwa jest jedynie tymczasowa. W przypadku budowania modułów spoza głównego drzewa kernela będzie zwykle normalnym stanem rzeczy, że ich autorzy dość często te moduły będą aktualizować (dodawać nowe commit’y) ale niekoniecznie będą oni przy tym wydawać nową wersję modułu. Dlatego też będzie trzeba posługiwać się pośrednią wersją, np. w postaci daty ostatniego commit’a w repozytorium git. Ta powyższa nazwa katalogu źródeł tpe-2.0.3 ma jedynie na celu pomóc w wygenerowaniu plików szkieletowych, które później poddamy edycji.

Mając przygotowaną nazwę katalogu źródeł, przechodzimy do niego i wpisujemy w terminalu poniższe polecenie:

$ dh_make --single --packagename tpe --email morfik@nsa.com --native --copyright gpl2
Maintainer Name     : Mikhail Morfikov
Email-Address       : morfik@nsa.com
Date                : Sun, 17 Mar 2019 00:45:27 +0100
Package Name        : tpe
Version             : 2.0.3
License             : gpl2
Package Type        : single
Are the details correct? [Y/n/q]

To powyższe polecenie stworzyło nam katalog debian/ . Z plików w tym folderze zostawiamy jedynie katalog source/ oraz pliki changelog , compat , control , copyright i rules .

Plik debian/control

Do pliku control wrzucamy poniższą zawartość:

Source: tpe
Section: kernel
Priority: optional
Maintainer: Mikhail Morfikov <morfik@nsa.com>
Build-Depends: debhelper (>= 11~),
  dkms
Standards-Version: 4.3.0
Homepage: https://github.com/cormander/tpe-lkm
Vcs-Git: https://github.com/cormander/tpe-lkm.git
Vcs-Browser: https://github.com/cormander/tpe-lkm

Package: tpe-dkms
Architecture: all
Depends: ${misc:Depends},
 dkms
Recommends: linux-headers
Description: Trusted Path Execution (TPE) Linux Kernel Module, Version 2
 Trusted Path Execution is a security feature that denies users from
 executing programs that are not owned by root, or are writable. This
 closes the door on a whole category of exploits where a malicious
 user tries to execute his or her own code to attack the system.
 .
 Since this module doesn't use any kind of ACLs, it works out of the
 box with no configuration. It isn't complicated to test or deploy to
 current production systems. Just install it and you're done!

Pozycja Source: ma wskazywać na nazwę, która była w pliku Makefile . Każda paczka zawierająca moduły DKMS musi kończyć się frazą -dkms . Dlatego też w Package: mamy tpe-dkms . Zależności zawsze będą takie same. Pozostałe pola trzeba sobie dostosować w zależności od modułu.

Plik debian/changelog

Plik changelog edytujemy wpisując w terminalu dch -i i uzupełniamy w poniższy sposób:

tpe (2.0.3~git20181202-1) unstable; urgency=medium

  * Initial release. (Closes: #123456)
  * Upstream commit: e68ba85

 -- Mikhail Morfikov <morfik@nsa.com>  Sat, 16 Mar 2019 19:25:16 +0100

Tutaj już się nam zmieniła wersja 2.0.3~git20181202-1 , bo od 2.0.3 zostały w repozytorium git poczynione pewne zmiany i dlatego nie powinniśmy dawać samego 2.0.3 .

Plik debian/copyright

Plik copyright nie jest aż taki ważny, gdy zamierzamy budować paczkę z modułem głównie dla siebie ale wypadłoby go uzupełnić tak, by miał ręce i nogi:

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: tpe
Source: https://github.com/cormander/tpe-lkm

Files: *
Copyright: 2011-2018 Corey Henderson
License: GPL-2

Files: debian/*
Copyright: 2019 Mikhail Morfikov <morfik@nsa.com>,
License: GPL-2

License: GPL-2
 This program is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
 the Free Software Foundation; version 2 dated June, 1991.
 .
 On Debian systems, the complete text of version 2 of the GNU General
 Public License can be found in '/usr/share/common-licenses/GPL-2'.

Plik debian/rules

Sednem całej zabawy z pakietowaniem modułów DKMS jest odpowiednie uzupełnienie pliku debian/rules . Poniżej jest przykładowa zawartość:

#!/usr/bin/make -f
# -*- makefile -*-

export DH_VERBOSE=1
export DH_OPTIONS = -v
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/buildflags.mk
include /usr/share/dpkg/pkg-info.mk

%:
    dh $@ --with dkms

override_dh_install:
    dh_install -p tpe-dkms scripts/ usr/src/$(DEB_SOURCE)-$(DEB_VERSION_UPSTREAM)
    dh_install -p tpe-dkms conf/ usr/src/$(DEB_SOURCE)-$(DEB_VERSION_UPSTREAM)
    dh_install -p tpe-dkms README usr/src/$(DEB_SOURCE)-$(DEB_VERSION_UPSTREAM)
    dh_install -p tpe-dkms Makefile usr/src/$(DEB_SOURCE)-$(DEB_VERSION_UPSTREAM)
    dh_install -p tpe-dkms *.c usr/src/$(DEB_SOURCE)-$(DEB_VERSION_UPSTREAM)
    dh_install -p tpe-dkms *.h usr/src/$(DEB_SOURCE)-$(DEB_VERSION_UPSTREAM)

override_dh_dkms:
    dh_dkms -V $(DEB_VERSION_UPSTREAM)

override_dh_auto_configure:
override_dh_auto_build:
override_dh_auto_test:
override_dh_auto_install:
override_dh_auto_clean:

Jako, że budujemy moduł DKMS, to określamy --with dkms . Na samym dole zaś mamy kilka pozycji override_dh_auto_* . Wszystkie z nich są puste i nadpisują odpowiadające im targety. Ma to na celu uniemożliwienie budowania modułu podczas tworzenia pakietu – w końcu nie chcemy budować samego kodu, a jedynie przygotować paczkę, która przy instalacji zbuduje moduł na docelowej maszynie.

Przy pomocy override_dh_install: przepisujemy domyślny target instalacji plików. Musimy w nim skopiować wszystkie pliki źródłowe wykorzystywane w procesie budowania modułu kernela. Zwykle są to pliki mające sufiks *.c i *.h ale mogą być również i inne. Wszystkie te pliki trzeba umieścić w odpowiednim katalogu pod /usr/src/ . W zasadzie to edycja tego targetu w przypadku różnych modułów kernela sprowadza się do określenia plików, które chcemy skopiować oraz zmiany nazwy pakietu w -p tpe-dkms .

Z kolei override_dh_dkms: nadpisze nam target konfigurujący DKMS. W tym przypadku będzie dostosowana wersja w pliku dkms.conf bez potrzeby ręcznej edycji tego pliku. Plik dkms.conf musimy za to sobie stworzyć ręcznie.

Plik debian/tpe-dkms.dkms

Wspomniany wyżej plik dkms.conf będzie po części generowany ale musimy i tak stworzyć jego szkielet. Nazwa pliku debian/tpe-dkms.dkms odpowiada temu co wpisaliśmy w polu Package: w pliku control plus sufiks .dkms . Poniżej znajduje się jego zawartość:

PACKAGE_NAME="tpe"
PACKAGE_VERSION="#MODULE_VERSION#"
BUILT_MODULE_NAME[0]="$PACKAGE_NAME"
MAKE[0]="make -C ${kernel_source_dir} M=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build"
CLEAN="make -C ${kernel_source_dir} M=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build clean"
DEST_MODULE_LOCATION[0]="/updates/dkms"
REMAKE_INITRD="no"
AUTOINSTALL="yes"

W zmiennej $PACKAGE_NAME podajemy nazwę modułu z pliku Makefile . W zmiennej $PACKAGE_VERSION nie określamy wersji modułu. Będzie ona automatycznie generowana przez mechanizm budowy pakietu. Pozostałe zmienne również zostawiamy bez zmian. Niekiedy będzie potrzeba dostosowania zmiennych $MAKE i $CLEAN . Jeśli nasz moduł nie jest niezbędny w fazie initramfs/initrd, to nie musimy ustawiać zmiennej $REMAKE_INITRD na yes , co przyśpieszy instalację modułu w systemie.

Plik debian/watch

Przydałoby się także stworzyć plik debian/watch , który ma za zadanie monitorować czy upstream wypuścił nowszą wersję modułu. Niemniej jednak, jeśli będziemy podbierać wersję z git’a, to trzeba będzie synchronizować repozytorium z pominięciem pliku debian/watch . Tak czy inaczej poniżej znajduje się jego zawartość:

version=4
opts=filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/tpe-lkm-$1\.tar\.gz/ \
 https://github.com/cormander/tpe-lkm/releases .*/archive/(\d\S*)\.tar\.gz

Plik debian/source/format

Na koniec musimy jeszcze zmienić format źródeł z 3.0 (native) na 3.0 (quilt) . Edytujemy zatem plik debian/source/format i przepisujemy go do poniższej postaci:

3.0 (quilt)

Paczka .tar z oryginalnymi źródłami

Musimy teraz stworzyć sobie paczkę .tar , w której będą przechowywane oryginalne źródła. Pamiętajmy, że nie możemy po prostu skompresować katalogu roboczego, bo w nim znajdują się choćby nasz katalog debian/ oraz pliki od repozytorium git .git/ . Tych wszystkich rzeczy trzeba się z paczki .tar pozbyć. Robimy to w poniższy sposób:

$ cd ..
$ tar --exclude='.git*' --exclude='.pc' --exclude='debian' -cf - tpe-2.0.3 | xz -9 -c - > tpe_2.0.3~git20181202.orig.tar.xz

Kluczowe tutaj jest określenie nazwy paczki .tar , która musi pasować do wzoru nazwapaczki_wersja.orig.tar.xz . Jeśli w pliku debian/changelog uwzględniliśmy także datę ostatniego commit’a, to ją również trzeba uwzględnić w nazwie paczki .tar .

Budowanie paczki .deb zawierającej źródła modułu kernela

Mając przygotowane pliki źródłowe, możemy przejść do stworzenia paczki .deb , która nam je ładnie ogarnie. Budujemy pierw źródła:

$ cd tpe-2.0.3
$ debuild -S -sa -d -i

I budujemy pakiet .deb :

$ cd ..
$ sudo pbuilder --build tpe_2.0.3\~git20181202-1.dsc

Z racji, że nie będziemy nic kompilować, a jedynie zainstalujemy trochę zależności, to proces budowania paczki .deb zajmie jedynie chwilę. Po paru minutach paczka powinna być gotowa do instalacji w docelowym systemie.

Instalacja modułu kernela przy pomocy DKMS w systemie

Jeśli wszystkie kroki do tej pory przeprowadziliśmy poprawnie, to możemy przejść do etapu instalacji paczki .deb w systemie. Mając lokalne repozytorium stworzone za sprawą reprepro dodajemy pierw paczkę do niego:

$ debsign /media/Kabi/pbuilder/result/tpe_2.0.3\~git20181202-1_amd64.changes
$ reprepro --basedir /media/Kabi/repozytorium/debian/ include sid /media/Kabi/pbuilder/result/tpe_2.0.3\~git20181202-1_amd64.changes.

Odświeżamy listę pakietów w repozytorium i instalujemy paczkę tpe-dkms :

# apt-get update
# aptitude install tpe-dkms
The following NEW packages will be installed:
  tpe-dkms
0 packages upgraded, 1 newly installed, 0 to remove and 112 not upgraded.
Need to get 0 B/17.3 kB of archives. After unpacking 75.8 kB will be used.
Get: 1 file:/media/Kabi/repozytorium/debian sid/main amd64 tpe-dkms all 2.0.3~git20181202-1 [17.3 kB]
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Selecting previously unselected package tpe-dkms.
(Reading database ... 325463 files and directories currently installed.)
Preparing to unpack .../tpe-dkms_2.0.3~git20181202-1_all.deb ...
Unpacking tpe-dkms (2.0.3~git20181202-1) ...
Setting up tpe-dkms (2.0.3~git20181202-1) ...
...

Po chwili powinien rozpocząć się automatyczny proces budowania modułu kernela za sprawą mechanizmu DKMS. W zasadzie to wszystkie kroki, które w tym procesie mają miejsce są dokładnie takie same jak przy ręcznej budowie modułu kernela via DKMS, z tym, że to system bez naszej ingerencji przeprowadzi cały ten proces:

...
Loading new tpe-2.0.3~git20181202 DKMS files...
Building for 4.20.16-amd64-morficzny+
Building initial module for 4.20.16-amd64-morficzny+
Done.

tpe.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/4.20.16-amd64-morficzny+/updates/dkms/

do_depmod 4.20.16-amd64-morficzny+
DKMS: install completed.

Proces budowy modułu się zakończył, podobnie jak i proces instalacji pakietu. Niektóre moduły będą się budować dłużej, a inne krócej, przez co cała instalacja będzie sprawiać wrażenie, że nic się nie kompilowało. Na wszelki wypadek można jeszcze sprawdzić status zainstalowanych w systemie modułów DKMS:

# dkms status
tpe, 2.0.3~git20181202, 4.20.16-amd64-morficzny+, x86_64: installed

Informacja na końcu, tj. installed oznacza, że moduł został dodany do mechanizmu DKMS, zbudowany i zainstalowany przez niego, co potwierdza wyjście polecenia modinfo :

# modinfo tpe
filename:       /lib/modules/4.20.16-amd64-morficzny+/updates/dkms/tpe.ko
version:        2.0.3
description:    Trusted Path Execution (TPE) Module
license:        GPL v2
author:         Corey Henderson
srcversion:     59FE85B47CF025933F0DEC7
depends:
retpoline:      Y
name:           tpe
vermagic:       4.20.16-amd64-morficzny+ SMP preempt modversions RANDSTRUCT_PLUGIN_0eaedf097c03a5950fbbc3dbbc78d213cd5e0408fdc9f6643749049983af6ba9
sig_id:         PKCS#7
signer:         Key for morfikownias kernel
sig_key:        08:D5:CC:EF:11:AF:1F:63:0C:A6:C7:2A:B2:DB:71:A7:F0:41:DF:24
sig_hashalgo:   sha512
signature:      3A:BB:B3:40:07:35:59:25:30:B0:89:53:01:94:B1:DC:36:04:90:60:
                14:91:8B:5B:67:25:CD:03:62:B3:19:6F:5F:3D:9F:EF:15:1E:AA:23:
                25:6D:A6:73:E1:FC:4F:7B:1C:65:34:82:35:CC:F7:9D:71:FF:0A:08:
                65:E9:F5:79:33:52:00:0C:BB:CC:5A:3F:64:97:5D:62:5C:D2:76:61:
                2B:95:1D:0C:67:A7:59:89:4A:D4:14:A4:54:D5:DB:5A:E1:06:C0:98:
                B5:26:67:46:D6:C3:ED:D1:1E:89:3D:3E:4B:7D:D3:D9:23:97:8A:75:
                E4:91:36:9A:D1:8E:50:57:3C:84:40:9F:7A:2A:C7:D1:61:74:D8:1D:
                79:9D:9D:3B:D0:13:30:8F:9F:86:6D:B9:C3:4B:1A:B5:7E:84:B9:48:
                5B:A3:4C:5C:78:E5:45:A5:BB:84:E8:DC:20:A5:F2:A1:E7:6D:E2:A4:
                33:ED:CA:92:B5:74:B6:0D:09:1C:A2:8C:2F:FE:A6:A4:8D:AD:2A:99:
                7D:B1:F9:FF:83:B3:A0:A2:3A:50:29:D7:B5:B9:C8:36:30:10:CA:98:
                43:1B:1E:18:52:76:50:F3:1B:60:15:D1:82:6E:B8:58:1C:43:4C:71:
                BD:C6:CF:1F:62:6F:5A:65:4B:D4:62:56:AC:32:36:44:65:BF:22:FE:
                E3:24:36:31:EC:14:99:18:60:54:42:CF:76:FF:5B:09:7B:6F:15:49:
                9A:1A:30:B9:B4:C5:98:78:19:1D:BB:02:09:24:C9:B8:44:66:A0:87:
                E8:87:85:F3:3A:CA:40:72:70:65:01:0C:46:88:77:F2:8F:4D:5C:D4:
                7A:01:2A:16:20:68:97:18:07:80:50:B3:9D:1D:A4:94:76:11:4A:AB:
                30:33:87:8E:EE:4C:75:86:86:F8:34:A7:B4:64:EF:02:09:C9:3B:3A:
                AB:AF:AD:DA:36:C5:B7:14:2B:5B:9B:43:73:6A:F8:43:BF:AB:BF:3F:
                CC:56:52:F9:E2:18:D9:A2:F9:75:EC:8A:17:9E:D5:BC:36:FB:4C:9D:
                6B:96:BE:8E:3F:FB:2C:0C:06:82:5D:8B:87:A5:CB:5C:90:EF:98:52:
                11:9C:ED:E5:90:CD:F3:6C:2D:74:1F:C3:A6:AF:AB:8F:B7:1D:0F:2C:
                BF:8D:85:5C:6D:EE:59:5F:66:07:C5:71:37:A4:86:69:A7:71:18:63:
                C4:0B:69:C3:88:03:62:15:03:BA:28:FE:79:A4:85:64:DC:C4:18:04:
                C1:26:61:E6:FF:BA:72:86:45:AD:D3:C6:80:E1:9E:9E:20:83:7B:72:
                FB:7E:F1:90:64:AC:3F:93:48:ED:14:47

No i jak widać, moduł tpe.ko siedzi na swoim miejscu, zatem cały proces przygotowania pakietu .deb z modułem kernela zakończył się powodzeniem. Podobnie sprawa będzie wyglądać, gdy zaktualizujemy paczkę, czy też będziemy instalować nowszy kernel.

Warto też zadbać o to, by moduł instalowany przy pomocy mechanizmu DKMS ładował się przy starcie systemu tworząc stosowną konfigurację w katalogach /etc/modules-load.d/ oraz /etc/modprobe.d/ .

Podpisywanie modułów DKMS

Jeśli nasz kernel wykorzystuje podpisy cyfrowe i nie zezwala na załadowanie modułów, które nie zostaną podpisane tym samym kluczem co kernel, to trzeba również zadbać o podpisanie modułów tworzonych za sprawą mechanizmu DKMS.


Komentarze

Zawartość wpisu