Błędy uprawnień występujące wyłącznie w podprocesach pojawiają się, gdy agent uruchamia procesy potomne z inną tożsamością, środowiskiem, przestrzenią nazw, widokiem systemu plików lub polityką bezpieczeństwa.
Proces agenta może pomyślnie odczytać plik domowy lub wywołać narzędzie, a następnie otrzymać odmowę dostępu, gdy ta sama czynność zostanie wykonana przez powłokę, proces roboczy Pythona, kontener lub piaskownicę. Proces potomny może utracić dodatkowe grupy, dane uwierzytelniające, zmienne środowiskowe, uprawnienia, dostęp do gniazd, widoczność punktów montowania lub uprawnienia do wykonywania plików. Tekst polecenia jest identyczny, ale jego kontekst bezpieczeństwa już nie.
Proces potomny może odziedziczyć inną tożsamość użytkownika i zestaw danych uwierzytelniających
Programy uruchamiające mogą ustawiać UID, GID, dodatkowe grupy, maskę umask, katalog roboczy, środowisko i deskryptory plików. Menedżery usług, pomocnicze programy setuid, kontenery i pule procesów roboczych mogą celowo obniżać uprawnienia przed wykonaniem wygenerowanego kodu. Ta różnica pozostaje widoczna podczas późniejszych testów domowych.
Praktyczna analiza kontekstu bezpieczeństwa procesu zaczyna się od sprawdzenia tożsamości, polityki bezpieczeństwa i przestrzeni nazw, zamiast zakładać, że bity trybu Uniksa wyjaśniają wszystko. Charakterystyczne są inne identyfikatory, grupy, maska umask lub dostępność danych uwierzytelniających wewnątrz procesu potomnego.
Uruchomienie procesu nadrzędnego jako root nie gwarantuje nieograniczonych uprawnień procesu potomnego, a identyfikatory liczbowe mogą być mapowane inaczej w kontenerach lub udziałach sieciowych. Porównaj efektywną tożsamość podczas kończącego się niepowodzeniem wywołania systemowego. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja za nim podąży.
Przestrzenie nazw, punkty montowania i piaskownice zmieniają widok systemu plików
Proces potomny może wejść do kontenera lub piaskownicy, w której ścieżki są tylko do odczytu, ukryte, przemapowane, zamontowane z opcją noexec albo należą do innego identyfikatora liczbowego. Gniazda Uniksa i pliki urządzeń mogą być nieobecne, nawet gdy zwykłe pliki są widoczne.
Przypadek rozwiązywania problemów z piaskownicą pokazuje uprawnienia gniazd piaskownicy, gdy proces potomny nie może uzyskać dostępu do przekazanego gniazda, którego potrzebuje. Wniosek jest taki, że odmowa dostępu może opisywać łączność lub politykę przestrzeni nazw, a nie tylko zawartość plików. Tę granicę należy mierzyć osobno w realistycznych warunkach działania.
Jeśli proces potomny widzi inny i-węzeł, opcje montowania lub ścieżkę, zmiana uprawnień hosta może na niego nie wpłynąć. Rozwiąż ścieżkę i sprawdź tożsamość punktu montowania z poziomu kończącego się niepowodzeniem kontekstu. Praktyczne konsekwencje stają się widoczne, gdy kilka źródeł konkuruje o ograniczony kontekst.
Uprawnienia i obowiązkowe polityki mogą odrzucać operacje dozwolone przez bity trybu
Uprawnienia Linuksa dzielą uprawnienia roota, a SELinux, AppArmor, seccomp i reguły piaskownicy mogą odrzucać operacje mimo bitów odczytu lub wykonywania dla właściciela. Częstymi granicami są operacje sieciowe, ptrace, urządzenia i montowanie. Ta zależność powinna pozostać jawna w końcowym interfejsie.
Model uprawnień i etykiet bezpieczeństwa przedstawia mechanizmy kontroli UID i GID obok uprawnień oraz etykiet bezpieczeństwa. Te niezależne warstwy wyjaśniają, dlaczego samo chmod może nie usunąć błędu podprocesu. Wynik należy zatem sprawdzić względem pierwotnych dowodów.
Granica błędu to komunikat o uprawnieniach wygenerowany przez aplikację, który nie odpowiada odmowie systemu operacyjnego. Zarejestruj errno, dzienniki audytu i dokładne wywołanie systemowe, zanim osłabisz politykę piaskownicy lub udostępnisz pliki wszystkim użytkownikom. Ta różnica pozostaje widoczna podczas późniejszych testów domowych.
Porównaj konteksty bezpieczeństwa procesu nadrzędnego i potomnego podczas kończącego się niepowodzeniem wywołania
Zarejestruj ścieżkę pliku wykonywalnego, argumenty, katalog roboczy, UID, GID, grupy, maskę umask, nazwy zmiennych środowiskowych, deskryptory plików, identyfikatory przestrzeni nazw, tabelę punktów montowania, i-węzeł ścieżki, tryb, ACL, etykietę bezpieczeństwa, uprawnienia, stan seccomp, obecność gniazda, errno i decyzję audytu w procesie nadrzędnym i potomnym.
Użyj mechanizmów kontroli uprawnień agenta, aby powiązać wynik z zakresem narzędzi agenta. Odtwórz problem za pomocą minimalnego procesu potomnego, a następnie dodawaj warstwy programu uruchamiającego, kontenera i piaskownicy pojedynczo. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja za nim podąży.
Przyznaj tylko brakujące uprawnienie, grupę, punkt montowania, gniazdo lub ścieżkę. Zachowaj ograniczenie, jeśli odzwierciedla zamierzoną izolację; błąd podprocesu może świadczyć o tym, że granica zaufania domowej AI działa prawidłowo. Tę granicę należy mierzyć osobno w realistycznych warunkach działania.
Centrum Technologii i Sztucznej Inteligencji
Więcej do przeczytania

Co powoduje, że agent AI do planowania powtarza już wykonane kroki?
Śledź powtarzające się kroki planera, analizując trwałość stanu, dowody ukończenia, analizę wyników narzędzi, zachowanie kontekstu, ponowne próby, przeplanowywanie i warunki zatrzymania.

Co powoduje przeciążenie procesora, gdy sprzętowe transkodowanie i sztuczna inteligencja wideo działają jednocześnie?
Śledź wysycenie procesora w zakresie odciążania kodeków, konwersji pikseli, kopiowania klatek, wstępnego przetwarzania AI, dźwięku, napisów, pamięci masowej i planowania procesów.

Co powoduje, że ten sam lokalny LLM zwraca niespójne schematy JSON?
Zdiagnozuj niespójny lokalny JSON, zamrażając ścieżkę modelu, prompt, schemat, ograniczenia dekodera, próbkowanie, kontekst, warunki zatrzymania i warstwę naprawczą.

