Granice bezpieczeństwa Dockera i LXC dla uprzywilejowanych usług domowych

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Docker vs LXC Security Boundaries for Privileged Home Services

Docker jest bezpiecznym wyborem domyślnym, gdy uprzywilejowana usługa domowa może pozostać jedną zadeklarowaną aplikacją z wąsko określonymi montowaniami. LXC jest czystszy, gdy usługa rzeczywiście potrzebuje małego systemu Linux, ale żadne z tych rozwiązań nie tworzy oddzielnej granicy jądra.

Decydującą kwestią nie jest to, która nazwa brzmi na bardziej odizolowaną. Oba rozwiązania opierają się na izolacji zapewnianej przez jądro hosta. Porównaj faktycznie przyznane uprawnienia, udostępnione urządzenia i pliki, jednostkę, którą aktualizujesz i przywracasz, oraz konsekwencje ucieczki z izolacji. Jeśli współdzielenie jądra jest samo w sobie nieakceptowalne, przestań porównywać Docker i LXC i użyj maszyny wirtualnej albo oddzielnego hosta.

Zaakceptuj granicę współdzielonego jądra, zanim porównasz funkcje

Docker zwykle pakuje aplikację wraz z jej zależnościami, natomiast LXC udostępnia pełniejsze środowisko użytkownika Linux z systemem init, kontami, pakietami i usługami systemowymi. Ta różnica operacyjna nie zapewnia LXC niezależnego jądra gościa.

Badania nad izolacją kontenerów w Linuksie opisują mechanizmy przestrzeni nazw i polityk jako patchwork, którego semantyka może być trudna do sprawdzenia. To ograniczenie izolacji opartej na współdzielonym jądrze dotyczy obu kandydatów i sprawia, że żadne z tych rozwiązań nie jest odpowiedzią, gdy separacja jądra jest obowiązkowa.

Rozważaj oba rozwiązania wyłącznie dla zaufanych lub ograniczonych obciążeń. Przenieś kod wystawiony do internetu, nieznane obrazy lub automatyzację o poważnych konsekwencjach do maszyny wirtualnej, gdy naruszenie bezpieczeństwa nie może bezpośrednio dosięgnąć jądra hosta.

Pozwól, aby wymagane uprawnienia zmieniły wybór domyślny

Docker pozostaje atrakcyjny, gdy usługa potrzebuje kilku jawnie określonych możliwości, konfiguracji tylko do odczytu oraz jednej lub dwóch trwałych ścieżek. Definicja Compose może uwidocznić te wyjątki podczas przeglądu.

LXC pasuje do usług, które oczekują konwencjonalnego systemu Linux, kilku demonów, menedżera pakietów lub stabilnej sieci na poziomie systemu. Nieuprzywilejowane LXC zachowuje przydatne mapowanie UID, ale tryb uprzywilejowany, zagnieżdżanie i szerokie montowania bind osłabiają tę przewagę.

Policz wyjątki, zamiast zaznaczać pole uprzywilejowania. Jeśli którykolwiek projekt wymaga sieci hosta, gniazda zarządzania kontenerami, zapisywalnych montowań systemowych, wszystkich urządzeń lub profilu bez ograniczeń, przeprojektuj ścieżkę dostępu albo opuść warstwę współdzielonego jądra.

Dostęp do urządzeń i pamięci masowej decyduje o zasięgu skutków naruszenia

Koordynator USB, węzeł renderowania GPU, interfejs UPS lub katalog multimediów należy udostępniać tak wąsko, jak pozwala na to usługa. Stabilne ścieżki urządzeń, montowania tylko do odczytu oraz jawne przypisanie właścicieli UID/GID są zarówno elementami izolacji, jak i ustawieniami ułatwiającymi obsługę.

Niedawna relacja z wdrożenia Proxmox pokazuje, że nieuprzywilejowane LXC może izolować usługi oparte na Dockerze w oddzielnych jednostkach przywracania, nadal współdzieląc jądro hosta i stos pamięci masowej. Ten wzorzec LXC o małym zasięgu skutków naruszenia jest przydatny tylko wtedy, gdy zagnieżdżanie i wyjątki dotyczące sterowników pamięci masowej pozostają udokumentowane.

Wybierz Docker, gdy jedna aplikacja potrzebuje jednej małej granicy danych. Wybierz LXC, gdy kilka usług systemowych powinno działać razem. Odrzuć oba układy, jeśli jedno naruszenie bezpieczeństwa zapewnia zapisywalny dostęp do kopii zapasowych, kontroli nad hipernadzorcą lub niezwiązanych danych rodzinnych.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Porównaj jednostkę, którą aktualizujesz i przywracasz

Wycofanie zmian w Dockerze zwykle oznacza przywrócenie poprzedniej wersji konfiguracji Compose i obrazu wraz z danymi spójnymi na poziomie aplikacji. Wycofanie zmian w LXC może przywrócić całe środowisko użytkownika, co jest wygodne, ale może również odtworzyć nieaktualne pakiety, dane uwierzytelniające i ukryte ręczne zmiany.

Odtwórz każdego kandydata na jednorazowym hoście. W przypadku Dockera przywróć definicje, sekrety i wolumeny; w przypadku LXC odtwórz lub przywróć kontener i sprawdź stan pakietów, sieci, urządzeń oraz montowań. Łatwiejszy pomyślny test jest silniejszym dowodem niż mniejsze zużycie pamięci w stanie bezczynności.

Szersza decyzja ZimaSpace dotycząca granic usług VM, LXC i Docker jest kolejnym krokiem, gdy nadal rozważasz niezależne jądro.

Werdykt warunkowy: wybierz najwęższą granicę, która nadal ogranicza skutki awarii

Wybierz Docker dla jednej dobrze spakowanej, zaufanej aplikacji, której urządzenia, możliwości, sekrety i trwałe ścieżki mogą pozostać jawne i minimalne.

Wybierz LXC dla zaufanego środowiska usług Linux, które rzeczywiście korzysta z systemu init, pakietów, wielu demonów lub sieci na poziomie systemu, pozostając w miarę możliwości nieuprzywilejowanym.

Nie wybieraj żadnego z nich, gdy obciążenie wymaga szerokiej kontroli nad hostem, przetwarza wrogie dane wejściowe o poważnych konsekwencjach lub musi przetrwać naruszenie bezpieczeństwa jądra hosta. W takim przypadku maszyna wirtualna albo oddzielny komputer nie jest przesadą; to brakująca granica bezpieczeństwa.