Dlaczego przeniesienie certyfikatu VPN psuje jego etykietę SELinux

Certyfikaty mogą leżeć we właściwym katalogu z czytelnym trybem i własnością roota, a usługa nadal może zgłosić, że nie potrafi otworzyć pliku. W systemie SELinux ta kombinacja wskazuje na jeden konkretny mechanizm, a nie na uprawnienia. Etykieta podróżowała razem z plikiem, bo zmiana nazwy nie tworzy nowego obiektu. Inode zachował kontekst bezpieczeństwa, który miał na starej ścieżce, a polityka dla nowej ścieżki nigdy nie dostała szansy przypisać własnego.

Co zmiana nazwy naprawdę robi z etykietą

Plik niesie swój kontekst SELinux jako dane atrybutu przypięte do inode. Zmiana nazwy w obrębie jednego systemu plików zmienia wpis katalogowy i nic więcej, co jest szybkie i atomowe, i to jest powód, dla którego kontekst przeżywa przeniesienie. Żadna polityka nie jest pytana, żadna wartość domyślna nie jest stosowana i żadne ostrzeżenie nie jest drukowane.

Kopiowanie zachowuje się inaczej. Kopia tworzy nowy inode w katalogu docelowym, a polityka przypisuje kontekst na podstawie typu tego katalogu, więc skopiowany certyfikat zwykle kończy z poprawną etykietą, podczas gdy przeniesiony pozostaje błędny. Ta jedna różnica wyjaśnia większość zamieszania w tej klasie zgłoszeń.

Przeniesienia między systemami plików wracają do semantyki kopiowania, więc to samo polecenie może zachowywać się różnie na dwóch maszynach w zależności od tego, czy /etc leży na osobnym woluminie. Sprawdź to, zanim uznasz narzędzie za niewiarygodne. Jedno spojrzenie na tabelę montowań mówi, jakiego rodzaju przeniesienia dokonałeś.

Odczytaj bieżącą etykietę wobec oczekiwanej

Trzy polecenia tylko do odczytu odpowiadają na to pytanie, niczego nie zmieniając. Pierwsze pokazuje, co plik ma teraz, drugie zgłasza, czego polityka oczekuje dla dokładnie tej ścieżki, a trzecie wymienia każdy plik w katalogu, którego etykieta się różni.

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

Ufać należy przebiegowi próbnemu, bo nazywa każdy plik, którego kontekst odbiega od polityki, a mimo to zostawia system nietknięty. Jeśli certyfikat pojawi się na tej liście, znalazłeś rozbieżność między tym, co oznacza ścieżka, a tym, co twierdzi plik. Jeśli się nie pojawi, etykieta jest już taka, jakiej chce polityka, a twój czas należy gdzie indziej.

Następnie powiąż różnicę z rzeczywistą odmową. Niezgodność jest dowodem błędnej etykiety, a nie dowodem, że usługa przez to zawiodła, a poprawka zastosowana bez odpowiedniej odmowy w logu jest domysłem z dodatkowymi krokami.

Przywróć mapowanie zamiast wymyślać wyjątek

Dla standardowej lokalizacji polityka już mapuje ścieżkę, więc restorecon stosuje ją i praca jest skończona. Trzymaj zakres w katalogu, który naprawiasz; ponowne etykietowanie całego systemu plików jest wolne, zakłócające i zakopuje pierwotny błąd pod bardzo dużą zmianą.

Dla niestandardowego katalogu kolejność ma znaczenie, a jej odwrócenie daje polecenie, które zgłasza sukces, niczego nie zmieniając. Mapowanie należy do polityki, ponowne etykietowanie należy do końca, a przebieg próbny należy przed oboma. Pominięcie tej ostatniej części to sposób, w jaki ścieżka, która nigdy nie była błędna, i tak zostaje ponownie oznaczona.

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

restorecon stosuje mapowanie; nie potrafi go wymyślić. Jeśli żadna reguła nie opisuje ścieżki, nie ma z czego przywracać, dlatego trwałe mapowanie musi istnieć przed ponownym etykietowaniem. Zapisz, która konfiguracja posiada to mapowanie, bo inaczej późniejsze przeniesienie, aktualizacja pakietu lub ponowne etykietowanie znów tworzą usterkę i następna osoba zaczyna od zera.

Dlaczego chcon nie jest rozwiązaniem

chcon zapisuje kontekst bezpośrednio na pliku. Działa natychmiast i jest najmniej trwałą dostępną opcją, bo ponowne etykietowanie systemu plików stosuje politykę od nowa i wyrzuca ręczne zmiany bez pytania. Plik wygląda na naprawiony, a naprawa ma datę ważności, której nikt nie zapisał. Zamiast tego potrzebujesz reguły opisującej ścieżkę, aby każdy plik, który tam trafi, automatycznie otrzymał tę samą obsługę.

Co gorsza, uczy złej lekcji: bazowe mapowanie wciąż brakuje, więc usterka wraca tygodnie później bez wyraźnego wyzwalacza i bez pamięci o obejściu. Używaj chcon wyłącznie jako tymczasowego eksperymentu do potwierdzenia hipotezy, potem zastąp je mapowaniem, które przetrwa kolejne ponowne etykietowanie, i sprawdź, czy zamiennik rzeczywiście jest na miejscu.

Gdy etykieta jest poprawna, a dostęp nadal zawodzi

Zacznij od katalogów nadrzędnych. Uprawnienie przejścia jest sprawdzane na każdym elemencie ścieżki, więc poprawnie oznaczony certyfikat w katalogu, do którego usługa nie może wejść, pozostaje nieczytelny. Zarówno SELinux, jak i zwykłe uprawnienie muszą pozwalać na każdy krok, a naprawa jednego nie naprawia drugiego.

Następnie sprawdź tożsamość procesu i własny sandbox usługi. Jednostka z restrykcyjnym sandboxem może odmówić dostępu do pliku, na który polityka chętnie by pozwoliła, a z linii logu obie przyczyny wyglądają identycznie. Potwierdź, który proces naprawdę pyta, a nie który zakładasz, że pyta.

Pamiętaj, że reguły dontaudit mogą tłumić komunikaty o odmowie, więc pusty log audytu jest słabym dowodem, a nie dowodem. Jeśli polityka wygląda poprawnie, a dostęp nadal zawodzi, zbadaj sprawę przed wygenerowaniem szerokiego modułu zezwoleń i nie wyłączaj SELinux, aby objaw zniknął. Obie skróty dają system, który wydaje się działać, i postawę bezpieczeństwa, której nikt nie potrafi opisać. Krótkie śledztwo jest lepsze niż każde z nich.