Dlaczego nosuid blokuje pomocnikowi VPN zostanie rootem

Szyfrowanie dysku i montowanie z nosuid brzmią jak warianty tego samego pomysłu, a wcale nie są ze sobą powiązane. Jedno chroni dane w spoczynku, a drugie decyduje, czy jądro uszanuje bit uprawnień w momencie, gdy program się uruchamia. Pomocnik, który nie osiąga oczekiwanej tożsamości, skarży się na to drugie. Założenie, że winne jest pierwsze, wysyła ludzi do reinstalowania klientów, które nigdy nie były zepsute.

Dwie Niepowiązane Właściwości

Szyfrowanie dysku odpowiada na pytanie, kto może czytać bloki, gdy maszyna jest wyłączona. Opcja montowania odpowiada na pytanie, co jądro zrobi z bitami trybu pliku, gdy ktoś go uruchomi. Nic w pierwszym nie ogranicza drugiego, a w pełni zaszyfrowany laptop może zamontować system plików ze wszystkimi ograniczeniami na miejscu.

Czytanie ich jako jednej właściwości tworzy teorię, że zaszyfrowany katalog domowy uniemożliwia dostęp roota. Ta teoria trwa, ponieważ oba objawy pojawiają się na tej samej maszynie, a nie dlatego, że mają wspólną przyczynę.

Co Naprawdę Tłumi Przejście

Dokumentacja execve opisuje, jak plik wykonywalny z set-user-ID zmienia efektywną tożsamość nowego procesu na tożsamość właściciela pliku. Ta sama strona wymienia warunki, które tłumią to przejście, oraz ich odpowiednik dla identyfikatorów grup: ustawienie no_new_privs, system plików zamontowany z nosuid i proces, który jest śledzony. Uprawnienia pliku są ignorowane w tych samych warunkach. Te cztery reguły obejmują niemal każde zgłoszenie tego rodzaju.

Ta lista wyjaśnia, dlaczego tryb wypisywany przez ls nigdy nie jest całą historią autoryzacji. Nie mówi, który warunek spowodował konkretny komunikat o błędzie, a aplikacja może zgłaszać niepowiązaną operację poświadczeń tymi samymi słowami. Zapisz dokładny program, program uruchamiający i sekwencję błędów, zanim wyciągniesz wniosek.

Zidentyfikuj plik wykonywalny zainstalowany przez obsługiwany pakiet, jego właściciela, jego rzeczywistą ścieżkę i politykę systemu plików, który go zawiera. Kopia w folderze pobranych plików nie jest zainstalowanym pomocnikiem, cokolwiek mówi jej tryb.

Czego Nie Robić

Ustawianie bitów set-user-ID na niezweryfikowanym pliku binarnym i przenoszenie go, aż ograniczenie zniknie, nie jest naprawą. Zastępuje politykę, której nie rozumiałeś, uprawnieniem, którego nie możesz zaudytować, a ta sama technika zastosowana do pomocnika to znana ścieżka eskalacji. Usunięcie nosuid z montowania jest gorsze, bo dotyczy każdego programu w tym systemie plików, a nie tylko jednego.

Obsługiwana droga to udokumentowana instalacja pomocnika lub usługi po stronie klienta, wykonywana przez administratora, która umieszcza plik binarny tam, gdzie polityka go oczekuje. Dzięki temu zostaje jeden mechanizm uprawnień zamiast dwóch.

Potwierdź Rzeczywisty Kontekst Uruchomienia

Po autoryzowanej poprawce uruchom pomocnika tak, jak uruchamia go produkt, a nie z powłoki roota. Sukces jako root niczego nie dowodzi o ścieżce zwykłego użytkownika, a różnica między tymi dwoma kontekstami jest dokładnie tym, czego dotyczył błąd.

Następnie potwierdź operację sieciową, dla której istnieje pomocnik. Pomocnik, który się uruchamia, ale nie potrafi skonfigurować interfejsu, przesunął problem o jeden etap dalej, a nie go rozwiązał.

findmnt -no TARGET,OPTIONS /home
getcap /usr/libexec/openvpn-helper 2>/dev/null; ls -l /usr/libexec/openvpn-helper

Zapisz opcje montowania i własność pomocnika w tej samej notatce. Inaczej kolejna osoba, która będzie to debugować, powtórzy teorię szyfrowania od początku.