- Omówienie konfiguracji
- Konfigurowanie serwera kompilacji
- ruchamianie kompilacji
- Konfiguracja QEMU/KVM/libvirt
Serwer budowania F-Droid izoluje kompilacje dla każdego pakietu w czystym, izolowanym i bezpiecznym środowisku wirtualnej maszyny wyrzucanej. Budowanie tysięcy aplikacji, szczególnie zautomatyzowanych i/lub nienadzorowanych, może być niebezpieczne z perspektywy bezpieczeństwa. Dzieje się tak nawet wtedy, gdy produkty z kompilacji są również szeroko dystrybuowane i w sposób półautomatyczny (“masz dostępne aktualizacje”).
Załóżmy, że zagrożone jest repozytorium źródłowe. Mały wybór rzeczy, które atakujący mógłby zrobić w takiej sytuacji:
- Użyj niestandardowych kroków kompilacji, aby wykonać praktycznie wszystko, co użytkownik robiący kompilację.
- Uzyskaj dostęp do magazynu kluczy.
- Zmodyfikuj utworzone pliki APK lub źródłowe tarballs dla innych aplikacji w repozytorium.
- Zmodyfikuj metadane (które zawierają skrypty kompilacji, które również zawierają możliwość wykonania czegokolwiek) dla innych aplikacji w repozytorium.
Przez całkowitą izolację reperkusje są co najmniej ograniczone do aplikacji, o których mowa. Środowisko kompilacji jest nie tylko świeże dla każdej kompilacji, a następnie wyrzucane, ale jest również całkowicie odizolowane od środowiska podpisywania.
Oprócz problemów związanych z bezpieczeństwem, istnieją pewne aplikacje, które mają dziwne wymagania, takie jak stare wersje NDK. Byłoby niepraktyczne (lub przynajmniej bardzo niechlujne), aby rozpocząć modyfikowanie i przywracanie zestawu SDK w systemie wielozadaniowym, ale w ramach jednorazowej wirtualnej maszyny jednorazowej wszystko jest możliwe.
Wszystko to oprócz oczywistej korzyści posiadania znormalizowanego i całkowicie odtwarzalnego środowiska, w którym tworzone są kompilacje. Dodatkowo pozwala na wyspecjalizowane niestandardowe środowiska kompilacji dla konkretnych aplikacji.
Omówienie konfiguracji
W ten sposób można skonfigurować działający serwer kompilacji, zaczynając od
całkowicie czystej, minimalnej instalacji Debiana/stabilnej. W tym HOWTO
założono, że masz już setup
fdroidserver. Uruchamianie
narzędzi fdroidserver bezpośrednio z
git (np. ~/fdroidserver/fdroid
build org.adaway), będzie najprawdopodobniej na razie najłatwiejsze od
czasu instalacji serwera kompilacji skrypty nie są tak naprawdę gotowe do
właściwego pakowania. Poza tym prawdopodobnie będzie działał tylko na
Debianie, Ubuntu i innych pochodnych Debiana, ponieważ F-Droid używa tylko
Debiana w swojej infrastrukturze (mile widziane składki
(ang. contributions)!).
Podstawowy serwer musi mieć co najmniej Debian/trixie albo będzie wymagał wprowadzenia kilku poważnych zmian. Jeśli używasz Ubuntu lub pochodnej dystrybucji, możesz uzyskać brakujące pakiety z Twojej wersji, takie jak vagrant-cachier, z tego PPA: https://launchpad.net/~fdroid/+archive/ubuntu/buildserver/
Najpierw zainstaluj niezbędne pakiety i utwórz nowego użytkownika, aby uruchomić tutaj cały proces, np. fdroid. Są to tylko pakiety wymagane przez wszystkie kompilacje, może być konieczne zainstalowanie dodatkowych pakietów do tworzenia aplikacji, na przykład curcurial lub subversion. Po zainstalowaniu pakietów i utworzeniu użytkownika fdroid, nic innego w tym procesie nie powinno być uruchamiane przy użyciu root’a lub sudo.
root:~# apt-get install vagrant git python3-certifi \
python3-libvirt python3-requestbuilder python3-yaml \
python3-progress python3-vagrant python3-paramiko python3-pyasn1 \
python3-pyasn1-modules python3-requests python3-git
vagrant-mutate vagrant-libvirt ebtables dnsmasq-base \
libvirt-clients libvirt-daemon-system qemu-kvm qemu-utils
root:~# adduser --disabled-password fdroid
root:~# su fdroid
Sklonuj kod źródłowy i uruchom jako użytkownik fdroid :
fdroid:~$ cd ~
fdroid:~$ git clone https://gitlab.com/fdroid/fdroidserver.git
Musisz również upewnić się, że twoja zmienna środowiskowa ANDROID_HOME
jest poprawnie skonfigurowana set
up.
Dla Twojej wygody opcjonalnie możesz dodać plik wykonywalny fdroid do swojej ścieżki:
fdroid:~$ echo "PATH=\$PATH:$HOME/fdroidserver" >> ~/.bashrc
Pobierz wszystkie metadane kompilacji aplikacji z repozytorium fdroiddata…
fdroid:~/fdroidserver$ cd ~
fdroid:~$ git clone https://gitlab.com/fdroid/fdroiddata.git
fdroid:~$ cp fdroidserver/examples/config.yml fdroiddata/
fdroid:~$ sed -i "s@^[# ]*build_server_always.*@build_server_always: true@" fdroiddata/config.yml
Konfigurowanie serwera kompilacji
Oprócz konfiguracji podstawowej opisanej wcześniej, wysyłamy w sposób zgodny z Vagrant Debian/bullseye base box o nazwie ‘fdroid/bullseye64 ‘.
Od początku ładujemy skrzynki Debian Vagrant dla naszego serwera buildserver. Pobieranie i weryfikacja naszych wstępnie zbudowanych skrzynek Vagrant jest w pełni zautomatyzowana. (Jeśli jesteś zainteresowany tym procesem lub chcesz go uruchomić samodzielnie, powinieneś spojrzeć na: F-Droid Base Box)
Tworzenie skrzynki serwera F-Droid buildserver
Stwórz plik konfiguracyjny dla Vagrant jako
~/fdroidserer/buildserver/Vagrantfile.yaml który zawiera:
vm_provider: libvirt
Wtedy podstawowy obraz instalatora build… (pobieranie basebox i wszystkich platform SDK może zająć dużo czasu).
fdroid:~$ cd fdroidserver
fdroid:~/fdroidserver$ ./makebuildserver --verbose
Zajmie to dużo czasu, będzie wymagało dużej przepustowości i miejsca na dysku - większość z nich poświęcono na instalację niezbędnych części zestawu SDK systemu Android dla wszystkich różnych platform. Na szczęście wystarczy zrobić to od czasu do czasu. Jeśli masz już działający obraz serwera kompilacji, jeśli przepisy ulegną zmianie (np. gdy trzeba dodać pakiety), możesz ponownie uruchomić ten skrypt, a istniejący zostanie zaktualizowany.
Po zakończeniu otrzymasz nową skrzynkę bazową o nazwie ‘buildserver’, która
jest używana do tworzenia aplikacji. Teraz możesz budować pakiety tak jak
kiedyś, ale po uruchomieniu fdroid build --verbose --server ...,
uruchomione kompilacje aplikacji będą izolowane wewnątrz maszyny wirtualnej.
Chociaż stworzony obraz zaalokował limitowaną ilość rdzeni CPU i pamięci
operacyjnej, możesz edytować ~/fdroiddata/builder/Vagrantfile aby
zmodyfikować je dynamicznie podczas uruchomienia, np. libvirt.cpus = 6 and
libvirt.memory = 12288, ale upewnij się, że nie przekraczasz limitu
maszyny hostującej, inaczej proces VM może zostać zakończony.
Przy pierwszym wykonaniu kompilacji tworzona jest nowa maszyna wirtualna z
wykorzystaniem pola ‘buildserver’ jako bazy. Migawka stanu tego czystego
komputera jest zapisywana do użytku w przyszłych kompilacjach w celu
zwiększenia wydajności. Możesz wymusić odrzucenie tej migawki i
przebudowanie od zera przy użyciu przełącznika: fdroid build --resetserver
....
Poprawki buforowania makebuildserver (opcjonalnie)
Główne pliki do pobrania sdk/ndk będą automatycznie zapisywane w pamięci
podręcznej, aby przyspieszyć działanie po raz kolejny, ale nie ma prostego
sposobu na wykonanie tego w przypadku dłuższych sekcji, które korzystają z
‘androidowego’ narzędzia SDK do instalowania platform, dodatków i
narzędzi. Jednak zamiast zezwalać na automatyczne buforowanie, możesz podać
wstępnie wypełniony katalog pamięci podręcznej, który zawiera nie tylko te
pliki do pobrania, ale także pliki .tar.gz dla wszystkich istotnych
dodatków. Jeśli skrypty zabezpieczające je wykryją, będą używane zamiast
używania narzędzi Android. Na przykład, jeśli posiadasz
buildserver/addons/cache/platforms/android-19.tar.gz, który będzie użyty
podczas instalacji platformy android-19, zamiast ponownego pobierania z
użyciem android update sdk --no-ui -t android-19. Możliwe jest tworzenie
plików pamięci podręcznej dla tych dodatków z lokalnej instalacji pakietu
SDK, w tym:
cd /path/to/android-sdk/platforms
tar czf android-19.tar.gz android-19
mv android-19.tar.gz /path/to/buildserver/addons/cache/platforms/
Jeśli już zbudowałeś serwer buildserver, możesz pobrać te pliki bezpośrednio z buildserver:
vagrant ssh -- -C 'tar -C ~/android-sdk/platforms czf android-19.tar.gz android-19'
vagrant ssh -- -C 'cat ~/android-sdk/platforms/android-19.tar.gz' > /path/to/fdroidserver/buildserver/cache/platforms/android19.tar.gz
ruchamianie kompilacji
Podczas korzystania z buildserver, najłatwiej będzie uruchomić fdroid
bezpośrednio z git checkout fdroidserver. Jeśli nie masz jeszcze
zainstalowanych i skonfigurowanych narzędzi fdroidserwer, musisz to zrobić
w następnej kolejności: Instalowanie narzędzia Serwer i
Repo. Zapewnia to wszystkie
zależności potrzebne do uruchomienia fdroidserver z git.
Teraz jesteś gotowy do uruchamiania kompilacji. Przetestuj, budując najnowszą wersję programu fdroid:
fdroid:~/fdroidserver$ cd ~/fdroiddata
fdroid:~/fdroiddata$ ~/fdroidserver/fdroid build org.fdroid.fdroid -l --server
Konfiguracja QEMU/KVM/libvirt
Chociaż VirttalBox był używany w przeszłości, gościnne maszyny wirtualne
QEMU/KVM poprzez libvirt są obecnie zalecanym ustawieniem ponieważ jest ono
używane przez f-droid.org. Aby pliki obrazów libvirt można było odczytywać
bezpośrednio za pomocą pakietu vagrant, należy skonfigurować użytkownika
QEMU libvirt tak, aby zawsze ustawiało prawo własności do
libvirt.libvirt.
root:~# cat << EOF >> /etc/libvirt/qemu.conf
user = "libvirt"
group = "libvirt"
dynamic_ownership = 1
EOF
root:~# service libvirtd restart
Debian/bullseye i Ubuntu/xenial
root:~# adduser fdroid libvirt
root:~# adduser fdroid libvirt-qemu
starsze wersje Debiana i Ubuntu
root:~# adduser fdroid libvirtd
root:~# adduser fdroid kvm
Zaawansowana zagnieżdżona konfiguracja KVM:
Ta sekcja nie dotyczy korzystania z F-Droida w normalnej konfiguracji. Jeśli
chcesz uruchomić flagę fdroid build --server w KVM, ten pomocnik pomoże ci
zacząć.
Rozważ następujące podstawowe ustawienia zagnieżdżania:
bare metal host (l0)
\- F-Droid VM (l1)
\- F-Droid builder VM (l2)
Powyższe kroki opisują sposób konfigurowania (l1) i makebuildserver konfiguracji (l2).
Przede wszystkim musisz sprawdzić, czy cpu obsługuje zestaw instrukcji vmx (lub svm na amd). Możesz użyć tego polecenia, aby wyświetlić szczegóły dotyczące procesora:
root:~# cat /proc/cpuinfo
Włącz (l0) musisz sprawdzić, czy włączone jest zagnieżdżanie:
root:~# cat /sys/module/kvm_intel/parameters/nested
Jeśli nie jest włączona, możesz ją włączyć, uruchamiając:
echo "options kvm-intel nested=Y" > /etc/modprobe.d/kvm-intel.conf
Aby to zadziałało, musisz ponownie uruchomić komputer.
Następnie musisz upewnić się, że twoja konfiguracja (l1) vm przekazuje funkcje procesora wymagane do zagnieżdżenia. Tak więc otwórz konfigurację VM /etc/libvirt/qemu/my-vm.xml i wstaw blok kontrolera do twojego tagu domeny. (virt-manager udostępnia również interfejs użytkownika dla tej operacji.)
<cpu mode='custom' match='exact'>
<model fallback='allow'>SandyBridge</model>
<vendor>Intel</vendor>
<feature policy='require' name='vmx'/>
</cpu>
Rzeczywista wymagana konfiguracja zależy od twojego procesora. Szczegółowe informacje można znaleźć w podręczniku libvirts. Ważną częścią jest przekazywanie vmx (lub svm na amd) do systemu gościa.
