chroot zawodzi na OpenVPN: reguła AppArmor czy uprawnienie?

Demon zapisuje błąd chroot, a profil wygląda już na wystarczająco szeroki, więc kuszącym rozwiązaniem jest poszerzenie reguły ścieżki i restart. Zwykle nic to nie zmienia, bo chroot jest kontrolowany przez uprawnienie, którego profil nigdy nie mógł przekazać. Aby zdecydować, której warstwy dotknąć, potrzebne są trzy tanie kontrole: co procesowi wolno trzymać, na co pozwala polityka i co usunął program uruchamiający, zanim oba te elementy zaczęły się liczyć.

Dwie osobne bramy, i tylko jedna należy do AppArmora

chroot wymaga CAP_SYS_CHROOT w przestrzeni nazw użytkownika, w której działa proces. To zwykłe uprawnienie Linuksa, sprawdzane przez jądro, zanim wywołanie zrobi cokolwiek ze ścieżkami. Osobno profil AppArmora w trybie wymuszania może odmówić tej zdolności nawet wtedy, gdy proces ją ma, ponieważ polityka obowiązkowa jest konsultowana obok poświadczeń, a nie zamiast nich. Różnica ma znaczenie w praktyce: obie warstwy żyją w różnych plikach i zwykle utrzymują je różni ludzie.

Obie bramy zawodzą z tym samym errno. Obie dają EPERM i obie pojawiają się jako ogólna skarga o uprawnienia w logu demona, dlatego zgadywanie zawartości profilu marnuje tyle czasu. Reguła ścieżki, którą zamierzałeś dodać, kontroluje dostęp do plików po udanym chroot; nie ma nic wspólnego z tym, czy operacja jest w ogóle dozwolona.

Trzecia brama stoi powyżej obu. Jeśli menedżer usług lub nakładka uruchomiły proces bez zdolności w jego zbiorze ograniczającym, żadna zmiana AppArmora nie może jej przywrócić, a dodawanie zdolności do profilu tylko dokumentuje zamiar, którego jądro nie uszanuje.

Przeczytaj stan uprawnień, zanim zmienisz politykę

Zacznij od działającego procesu, a nie od konfiguracji, którą uważasz za aktywną. Plik stanu pokazuje pięć masek zdolności i flagę no-new-privileges, a one odpowiadają na różne pytania:

grep -E '^(CapInh|CapPrm|CapEff|CapBnd|CapAmb|NoNewPrivs):' /proc/$(pidof openvpn)/status
sudo aa-status | grep -i openvpn

CapEff to zbiór, który liczy się dla wywołania: zdolność obecna w CapBnd, ale nieobecna w CapEff, jest dozwolona przez sufit i nie jest obecnie trzymana. CapAmb ma znaczenie, gdy plik binarny nie jest uprzywilejowany w zwykłym sensie setuid, ponieważ zdolności otoczenia są sposobem, w jaki usługa zachowuje uprawnienie przez exec bez zdolności plikowych. CapInh zawiera bity, które mogą być dziedziczone przez exec, ale tylko wtedy, gdy dziedziczny zbiór uruchamianego pliku na to pozwala, więc bit tam sam z siebie nic nie daje.

Następnie potwierdź, który profil jest rzeczywiście podłączony. Proces może być ograniczony nazwą profilu, której się nie spodziewałeś, zwłaszcza gdy dystrybucja wysyła własny plik jednostki i profil razem, a odczyt /proc/PID/attr/current rozstrzyga to w jednej linii. Porównanie zmodyfikowanego pliku z profilem raportowanym przez jądro to różnica między naprawieniem przyczyny a edytowaniem pliku, którego nikt nie wczytuje.

Dodaj regułę zdolności tylko wtedy, gdy mówi o tym ślad audytu

Zapisy jądra i audytu nazywają warstwę, która odmówiła. Szukaj odmowy niosącej operację capable i nazwę sys_chroot wraz z profilem, który ją wytworzył. Jeśli taki zapis istnieje, proces już miał zdolność i AppArmor jej odmówił, a docelową zmianą jest reguła zdolności w prawdziwym profilu:

capability sys_chroot,

Trzymaj ją jako fragment w profilu, który jest naprawdę podłączony, i sprawdź słowo kluczowe wobec referencji profili apparmor.d, zamiast kopiować regułę z niepowiązanego poradnika. Wstawienie jej do współdzielonego include przyznaje ją każdemu ograniczonemu programowi, który wciąga ten plik, a przełączenie profilu w tryb complain ukrywa kolejną odmowę zamiast rozwiązać tę. Reguła profilu usuwa odmowę polityki; nie tworzy uprawnienia, więc proces, który nigdy nie miał CAP_SYS_CHROOT w swoim zbiorze efektywnym, nadal zawiedzie mimo obecnej reguły.

Jeśli zapis audytu nie pokazuje żadnej odmowy AppArmora, przestań edytować profil. Patrzysz na problem poświadczeń, a pozostała praca jest w pliku jednostki albo w procesie nadrzędnym, nie w języku polityki.

Menedżer usług trzyma własny sufit

systemd ustawia zbiór ograniczający zdolności dla każdej usługi, a domyślnie ten zbiór jest wąski. Wszystko, co tam wykluczono, jest dla procesu niedostępne niezależnie od tego, co mówi profil, dlatego utwardzone jednostki mogą zawieść w operacji, która działała, gdy demon był uruchamiany ręcznie. Odpowiednie dyrektywy łatwo odczytać w jednostce i łatwo przeoczyć, gdy aplikacja zgłasza błąd. Pliki drop-in dostarczane przez pakiet dystrybucji są zwykłym źródłem sufitu, którego nikt nie pamięta skonfigurować.

Podniesienie sufitu i przyznanie zdolności to dwie zmiany, nie jedna. Wpis w zbiorze ograniczającym mówi, że proces może trzymać zdolność; nie dodaje jej do zbioru efektywnego, a NoNewPrivs może uniemożliwić powodzenie późniejszego podniesienia, nawet gdy wszystko inne się zgadza. Dodaj tylko to, czego potrzebuje operacja, zachowaj resztę utwardzenia i oprzyj się pokusie przyznania wszystkich zdolności, aby jedna operacja przeszła.

Kolejność też tu ma znaczenie. Najpierw zmień sufit jednostki, potwierdź, że CapEff zawiera teraz ten bit, i dopiero wtedy zdecyduj, czy AppArmor nadal odmawia. Wprowadzenie obu zmian naraz pozostawia cię znowu zgadującym, jeśli błąd się utrzymuje.

Gdy odmowa zniknie, sprawdź samo więzienie

Udany chroot przenosi katalog główny, więc każda ścieżka, której demon później dotknie, jest rozwiązywana w nowym drzewie. Brakująca konfiguracja, nieobecny węzeł urządzenia albo nieskopiowany katalog certyfikatów pojawią się teraz jako błąd pliku, a ten błąd jest problemem układu, nie zdolności. Czytaj następne zdarzenie zamiast dodawać kolejne szerokie pozwolenie. Przeniesienie zmienia też znaczenie ścieżki względnej, dlatego poradniki utwardzania nalegają na ścieżki bezwzględne w konfiguracji demona.

Pomaga też pamiętać, czego chroot nie robi. To granica ścieżki, nie piaskownica: proces, który zachowuje uprawnienie, może z niej uciec, dlatego zdolność jest zwykle zrzucana po wywołaniu i dlatego ograniczenie powinno pozostać wokół demona. Utrzymywanie razem profilu AppArmora, zbioru ograniczającego zdolności i ograniczeń systemu plików jest celem tego ćwiczenia, a nie resztką do usunięcia po starcie usługi.

Reguła decyzyjna jest krótka. Jeśli zapis audytu wymienia AppArmor, dodaj jedną regułę zdolności do podłączonego profilu. Jeśli zbiór efektywny jest pusty, napraw sufit jednostki i kolejność zrzucania uprawnienia. Jeśli profil to nie ten, który edytowałeś, przestań edytować i znajdź prawdziwy.