Dlaczego chroot jest uważany za niepewny?

Bawię się pudełkiem CentOS od kilku lat. Więc jestem całkiem zadowolony z terminalu. Jednak czytałem wiele postów na blogu, twierdząc, że chroot jest niepewny, a liczba tych postów przeraża. Czy to naprawdę tak jest? Dlaczego?

Używam chroot do blokowania użytkowników korzystających wyłącznie z SFTP w określonym kontekście, bez żadnej powłoki lub poleceń. Więc tak naprawdę, jaki jest problem z bezpieczeństwem?

Pytanie zostało wygnane z StackOverflow .

— Aleksandr Makov
źródło

Po pierwsze: pytanie nie zostało zamknięte / migrowane w przypadku przepełnienia stosu , ale jest tam wyraźnie OT. Właściwym działaniem byłoby poczekać, aż zostanie zmigrowany lub oflagować go i poprosić mod, aby to zrobił, a nie publikować go w innej witrynie. Ale po drugie: jeśli „bawisz się CentOS”, również tutaj się mylisz. Ta strona jest przeznaczona dla profesjonalnych administratorów systemu, a nie hobbystów - zobacz nasze FAQ .

— Sven

@ SvenW dzięki, będę pamiętać o twoim napiwku na przyszłość. A co do „drugiego”, cóż, przepraszam, ale nie widzę, jak moje pytanie narusza FAQ. Po dwukrotnym przeczytaniu teraz mogę powiedzieć, że nie. Jeśli chodzi o frazę „baw się z CentOS”, cóż, pomyślałem, że to całkiem oczywiste, że chrootowanie i użytkownicy korzystający wyłącznie z SFTP oraz rozważanie kwestii bezpieczeństwa jest bardzo poważnym tematem, z którego profesjonaliści mogą skorzystać również w swojej firmie lub w jakimkolwiek innym ” środowiska profesjonalne.

— Aleksandr Makov

@ nawet jeśli nie wiesz, SF zostało usunięte z listy migracji SO z powodu liczby złych pytań, które nam przesłali.

— MDMarra,

Odpowiedzi:

Ponieważ w większości przypadków proces rootowania może łatwo wyjść z chroot. Jest to zgodne z projektem, ponieważ chroot nigdy nie był przeznaczony do zabezpieczenia.

Alan Cox w pewnym sensie zniesławił programistę, który przesłał łatkę do jądra, aby „naprawić” to zachowanie, twierdząc, że chroot został wykorzystany jako urządzenie zabezpieczające, ale nigdy nie miał nim być.

— MDMarra
źródło

Doskonały! Dziękuję Ci bardzo. Jest to kwestia procesów root, które są obecne w katalogu głównym lub są z niego dostępne. Dzięki.

— Aleksandr Makov

Właśnie zweryfikowałem, że uruchamiając program C pokazany na unixwiz.net/techtips/mirror/chroot-break.html jako root w Linuksie 4.18, można uciec od chroota.

— pkt

Więc nie rozdawaj uprawnień roota. Nawet zwykłe „bezpieczne” systemy mają konta root.

— Cees Timmerman,

Znam przynajmniej jeden przykład, dlaczego uważa się to za niepewne. Środowisko chroot /procnie jest izolowane, więc dostęp do zasobów nie posiadanych przez procesy uruchomione w chroot jest dość łatwy.

Używanie chrootowanego środowiska dla SFTP jest w porządku i znacznie poprawia poziom bezpieczeństwa. Po prostu nie nadużywaj go jako wirtualizacji opartej na kontenerach, która zapewnia wyższy poziom bezpieczeństwa. Podkreślam w tym, co znajduje się w odpowiedzi @ MDMarra.

— gertvdijk
źródło

Dziękuję Ci. Teraz staje się bardziej jasne, że sam chroot nie jest zły pod względem bezpieczeństwa, ale raczej jego bezpieczeństwo zależy od środowiska, w którym jest skonfigurowane.

— Aleksandr Makov

W rzeczywistości chroot nie jest zły pod względem bezpieczeństwa, ponieważ nigdy nie miał być urządzeniem zabezpieczającym. Miało to być narzędzie programistyczne do uruchamiania wielu wersji tych samych plików binarnych obok siebie z różnymi zależnościami. Nie zastępuje to właściwego zabezpieczenia usług - chociaż może być pomocne w pewnych okolicznościach, o ile rozumiesz, co to jest, a co nie.

— MDMarra,

MDMarra, więc w zasadzie chroot nie jest przeznaczony do przechwytywania połączeń SSH. Czy Twoim zdaniem „chrootowanie przychodzących połączeń SSH” wydaje Ci się nieprofesjonalne i czy należy tego unikać?

— Aleksandr Makov

Nie, niekoniecznie, po prostu zdaj sobie sprawę, że każdy exploit, który mógłby doprowadzić do podniesienia uprawnień lub jakikolwiek proces działający jako root w chroocie, byłby trywialny. Z pewnością może to być element układanki, ale nie powinien to być całość.

— MDMarra,