Zrezygnować z chroot czy skopiować iproute2 do jaila?

Usługa startuje, klient się kojarzy, a po stronie serwera nigdy nie pojawia się trasa. Albo demon odmawia startu i wskazuje polecenie, którego nie mógł wykonać. Oba wyniki wynikają z tych samych trzech linii, zwykle kopiowanych razem z poradnika hartowania: przejście na konto bez uprawnień, porzucenie grupy i zmiana katalogu głównego systemu plików. Tylko jedna z trzech ukrywa pliki, i tylko jedna z nich odbiera uprawnienie do zmiany tablicy routingu. Rozdzielenie ich to sposób, w jaki dowiadujesz się, której linii naprawdę chcesz.

Co jail zabiera, a demon nadal potrzebuje

Zmiana katalogu głównego następuje po starcie, więc demon zachowuje wszystko, co już otworzył, i traci wszystko, co otworzyłby później. Każdy pomocnik uruchamiany przez połączenie po tym momencie musi istnieć wewnątrz nowego katalogu głównego, wraz z bibliotekami współdzielonymi, które ładuje. Jail zbudowany z pliku konfiguracyjnego i certyfikatu nie ma ani jednego, ani drugiego.

Przejście na konto bez uprawnień to osobne ograniczenie. Proces, który zrezygnował z roota, może nie być w stanie zmieniać tras ani podnosić interfejsu, nawet gdy binarka jest tuż obok, więc obie awarie trzeba diagnozować osobno.

Trzy warunki decydują, jakiej poprawki potrzebujesz

Pierwszy warunek to sposób, w jaki twoja kompilacja instaluje trasy. Nowsze OpenVPN wydania konfigurują interfejs i tablicę routingu w procesie, podczas gdy starsze pakiety i własne konfiguracje opierają się na zewnętrznych narzędziach albo na skryptach up i down. Jeśli log wskazuje polecenie, w grze jest zewnętrzne narzędzie i jail je ukrywa. Jeśli log pokazuje błąd uprawnień, problemem jest konto.

Drugi to utrzymanie. Jail ze skopiowanymi binarkami trzeba odświeżać przy każdej aktualizacji pakietu, który je dostarcza, inaczej pierwsza aktualizacja zostawia za sobą zepsuty tunel. Trzeci to pytanie, czy konkretna kontrola naprawdę wymaga chroot; jeśli wymóg dotyczy w istocie rozdzielenia uprawnień, sama zmiana konta może wystarczyć.

Co musi zawierać działający jail

Jail, który uruchamia polecenia, potrzebuje binarki, każdej biblioteki, z którą się łączy, i każdego węzła urządzenia, który demon otwiera późno. Skopiuj elementy i przetestuj je bez VPN w tle:

ldd /usr/sbin/ip
chroot /etc/openvpn/jail /sbin/ip route show
chroot /etc/openvpn/jail /sbin/ip link set tun0 up

Pierwsze polecenie wymienia zależności i to jest to, które ludzie pomijają. Skopiowana binarka, która nie znajduje biblioteki, zawodzi z innym komunikatem niż brakująca binarka, a oba wyglądają jak awaria OpenVPN, gdy czyta się je od strony klienta. Ręczne uruchomienie polecenia w jailu odtwarza awarię bez restartowania usługi.

Skopiuj też konfigurację, certyfikaty i ewentualny CRL do jaila, bo plik, który demon chce odczytać ponownie po starcie, nie zostanie znaleziony po zmianie katalogu głównego. Zapisz, co skopiowałeś, ponieważ następna aktualizacja pakietu sieciowego zastępuje oryginały i zostawia jail na starej kopii.

Zamiast tego zmniejsz hartowanie

Jeśli jail istnieje tylko dlatego, że tak mówił poradnik, usunięcie tej jednej linii przy zachowaniu ograniczeń konta jest obronnym wynikiem. Demon zachowuje swój widok systemu plików i pozbywa się problemu, a obniżenie uprawnień nadal odbiera roota długowiecznemu procesowi.

Zapisz, co zostaje, i dlaczego. Konfiguracja, która po cichu straciła kontrolę bez notatki, to sposób, w jaki hartowanie dryfuje, a następny audyt zapyta, dlaczego linia zniknęła.

Podziel trzy linie, zanim wybierzesz

Skopiuj konfigurację, wyłącz wszystkie trzy dyrektywy i potwierdź, że klient się łączy i pojawiają się oczekiwane trasy. Potem włącz ponownie tylko linie konta, a następnie sam chroot. Krok, w którym tunel się psuje, wskazuje granicę, i unikasz odbudowy jaila, który nigdy nie był przyczyną.

Gdy znów routuje, uruchom jedną sesję klienta z większą szczegółowością i przeczytaj linię wskazującą polecenie lub uprawnienie, które zawiodło. Ta linia jest warta więcej niż limit czasu, który klient ostatecznie zgłasza.