Jak Fakeroot nie stanowi naruszenia bezpieczeństwa w systemie Linux?

Po przeczytaniu kilku fajnych odpowiedzi na to pytanie , wciąż zastanawiam się , dlaczego chcesz udawać, że jesteś rootem, nie uzyskując żadnych korzyści z bycia rootem.

Do tej pory mogę zebrać, że fakeroot służy do nadania własności plikowi, który musi być rootowany, gdy jest rozpakowany / tar'owany. Moje pytanie, dlaczego nie możesz tego zrobić z chownem?

Google Groups dyskusja tutaj wskazuje, że musi pan fakeroot skompilować jądro Debiana (jeśli chcesz to zrobić z nieuprzywilejowany użytkownika). Mój komentarz jest taki, że powód, dla którego musisz być rootem, aby się kompilować, prawdopodobnie dlatego, że uprawnienia odczytu nie zostały ustawione dla innych użytkowników. Jeśli tak, to czy nie jest to naruszenie bezpieczeństwa, które fakeroot zezwala na kompilację (co oznacza, że ​​gcc może teraz odczytać plik przeznaczony dla roota)?

Ta odpowiedź tutaj opisuje, że rzeczywiste wywołania systemowe są wykonywane z prawdziwym identyfikatorem użytkownika / identyfikatora użytkownika , więc gdzie jeszcze pomaga Fakeroot?

W jaki sposób fakeroot zatrzymuje niechciane eskalacje uprawnień w systemie Linux? Jeśli fakeroot może oszukać tar do utworzenia pliku, który był własnością roota, dlaczego nie zrobić czegoś podobnego z SUID?

Z tego, co zebrałem, fakeroot jest po prostu użyteczny, gdy chcesz zmienić właściciela dowolnych plików pakietów, które zbudowałeś do rootowania. Ale możesz to zrobić za pomocą Chown, więc gdzie brakuje mi zrozumienia, w jaki sposób ten składnik ma być używany?

Do tej pory mogę zebrać, że fakeroot służy do nadania własności plikowi, który musi być rootowany, gdy jest rozpakowany / tar'owany. Moje pytanie, dlaczego nie możesz tego zrobić z chownem?

Ponieważ nie możesz tego po prostu zrobić chown, przynajmniej nie jako użytkownik inny niż root. (A jeśli działasz jako root, nie potrzebujesz fakeroot). Chodzi o to, fakerootaby pozwolić programom, które oczekują, że będą uruchamiane jako root, jak normalny użytkownik, udając, że operacje wymagające roota powiodły się.

Jest używany zazwyczaj podczas budowania pakietu, dzięki czemu proces instalacji pakietu jest zainstalowana można kontynuować bez błędu (nawet jeśli to działa chown root:root, albo install -o root, etc.). fakerootpamięta fałszywą własność, którą udawał, że przekazuje pliki, więc kolejne operacje dotyczące własności widzą to zamiast prawdziwej; umożliwia to tarna przykład kolejne uruchomienia do przechowywania plików należących do roota.

W jaki sposób fakeroot zatrzymuje niechciane eskalacje uprawnień w systemie Linux? Jeśli fakeroot może oszukać tar do utworzenia pliku, który był własnością roota, dlaczego nie zrobić czegoś podobnego z SUID?

fakerootnie stara tarsię niczego robić, zachowuje zmiany, które chce wprowadzić kompilacja, nie pozwalając, by zmiany te wpłynęły na system, na którym kompilacja jest wykonywana. Nie musisz fakeroottworzyć tarballa zawierającego plik należący do roota i suid; jeśli masz plik binarny evilbinary, działając tar cf evil.tar --mode=4755 --owner=root --group=root evilbinaryjako zwykły użytkownik, utworzy plik archiwalny zawierający evilbinarywłasność użytkownika root i suid. Jednak nie będziesz mógł wyodrębnić tego archiwum i zachować tych uprawnień, chyba że zrobisz to jako root: tutaj nie ma eskalacji uprawnień. fakerootjest przywilejem deNarzędzie do skalowania: umożliwia uruchamianie kompilacji jako zwykły użytkownik, przy jednoczesnym zachowaniu efektów, jakie miałaby kompilacja, gdyby była uruchomiona jako root, umożliwiając późniejsze odtworzenie tych efektów. Zastosowanie efektów „na żywo” zawsze wymaga uprawnień roota; fakerootnie zapewnia żadnej metody ich uzyskania.

Aby zrozumieć fakerootbardziej szczegółowo użycie , należy wziąć pod uwagę, że typowa kompilacja dystrybucji obejmuje następujące operacje (między innymi):

• instaluj pliki, których właścicielem jest root
• ...
• zarchiwizuj te pliki, które nadal należą do roota, aby po ich rozpakowaniu były własnością roota

Pierwsza część oczywiście kończy się niepowodzeniem, jeśli nie jesteś rootem. Jednak podczas działania fakerootjako normalny użytkownik staje się procesem

• instaluj pliki, których właścicielem jest root - to się nie fakerootudaje , ale udaje, że się powiodło, i pamięta o zmianie własności
• ...
• zarchiwizuj te pliki, które nadal należą do roota - kiedy tar (lub jakikolwiek inny archiwizator jest używany) pyta system, co to jest własność pliku, fakerootzmienia odpowiedź, aby pasowała do własności zarejestrowanej wcześniej

W ten sposób można uruchomić kompilację pakietu bez uprawnień użytkownika root, uzyskując takie same wyniki, jakie można uzyskać, jeśli naprawdę działa się jako użytkownik root. Korzystanie fakerootjest bezpieczniejsze: system nadal nie może zrobić nic, czego użytkownik nie może zrobić, więc nieuczciwy proces instalacji nie może uszkodzić systemu (poza dotknięciem plików).

W Debianie narzędzia do kompilacji zostały ulepszone, aby już tego nie wymagały, i można budować pakiety bezfakeroot . Jest to obsługiwane dpkgbezpośrednio przez Rules-Requires-Rootdyrektywę (patrzrootless-builds.txt ).

Aby zrozumieć cel fakerooti aspekty bezpieczeństwa działania jako root, czy nie, pomocne może być rozważenie celu pakowania. Podczas instalowania oprogramowania źródłowego do użytku ogólnosystemowego postępujesz w następujący sposób:

1. zbudować oprogramowanie (co można zrobić bez uprawnień)
2. zainstaluj oprogramowanie (które należy wykonać jako root, lub przynajmniej jako użytkownik, który może pisać w odpowiednich lokalizacjach systemu)

Kiedy pakujesz oprogramowanie, opóźniasz drugą część; ale aby to zrobić pomyślnie, nadal musisz „zainstalować” oprogramowanie w pakiecie, a nie w systemie. Kiedy więc pakujesz oprogramowanie, proces staje się:

1. zbudować oprogramowanie (bez specjalnych uprawnień)
2. udawaj, że instalujesz oprogramowanie (ponownie bez specjalnych uprawnień)
3. przechwycić instalację oprogramowania jako pakiet (to samo)
4. udostępnij pakiet (podobnie)

Teraz użytkownik kończy proces instalując pakiet, który należy wykonać jako root (lub ponownie, użytkownik z odpowiednimi uprawnieniami do pisania w odpowiednich lokalizacjach). Tutaj realizowany jest opóźniony uprzywilejowany proces i jest to jedyna część procesu, która wymaga specjalnych uprawnień.

fakeroot pomaga w krokach 2 i 3 powyżej, umożliwiając nam uruchamianie procesów instalacji oprogramowania i rejestrowanie ich zachowania, bez uruchamiania jako root.

NIE. Fałszywy root pozwala uruchamiać narzędzia do manipulacji uprawnieniami i raportowania, będzie raportować konsekwentnie. Jednak tak naprawdę nie przyzna tych uprawnień. Będzie to wyglądało tak, jakbyś je miał (fałszywe). Nie zmieni niczego poza środowiskiem.

Jest to przydatne, jeśli chcesz utworzyć strukturę katalogów, która zawiera własność i uprawnienia, których użytkownik nie może ustawić, a następnie spakujesz, spakuj lub zapakuj.

To tak naprawdę nie podnosi uprawnień, jest fałszywe. Nie pozwala ci nic robić (usuwać, pisać, czytać), czego inaczej nie możesz zrobić. Możesz wyprodukować pakiet (teoretycznie) bez niego. Możesz otrzymać fałszywy raport (lsBez niego ).

To nie jest usterka bezpieczeństwa, ponieważ to nie pozwala na dostęp ani nic, bez czego nie można się obejść. Działa bez uprawnień. Wszystko to dawka jest do wywołania przecięcia chown, chmoditd To czyni je nie-działanie, poza tym, że rejestruje, co by się stało. Przechwytuje również połączenia zstat itp., Tak że zgłasza uprawnienia i własność z własnej wewnętrznej bazy danych, tak jakby inne polecenia zostały wykonane. Jest to przydatne, ponieważ jeśli następnie spakujesz katalog, będzie on miał fałszywe uprawnienia. Jeśli następnie rozpakujesz jako root, uprawnienia staną się rzeczywiste.

Wszelkie pliki, które nie były wcześniej możliwe do odczytu / zapisu, pozostaną nie do odczytu / zapisu. Wszelkie utworzone pliki specjalne (np. Urządzenia) nie będą miały żadnych specjalnych uprawnień. Każdy set-uid (dla innego użytkownika), pliki nie będą ustawione na UID. Żadna inna eskalacja uprawnień nie będzie działać.

Jest to rodzaj maszyny wirtualnej: Ogólnie maszyna wirtualna może symulować dowolne środowisko / system operacyjny, ale nie może nic zrobić z hostem, czego nie mogłaby zrobić żadna inna aplikacja. W maszynie wirtualnej możesz wydawać się robić wszystko. Możesz zmienić system zabezpieczeń, aby był taki sam lub inny, jednak wszystko to będzie istnieć na hoście, jako zasoby należące do użytkownika / grupy procesu uruchamiającego środowisko wirtualne.

Istnieją już dwie dobre i bardzo szczegółowe odpowiedzi, ale zaznaczę, że akapit wprowadzający oryginalnej fakeroot strony podręcznika ¹ faktycznie wyjaśnia to dość jasno i zwięźle:

fakeroot uruchamia polecenie w środowisku, w którym wydaje się, że ma uprawnienia administratora do manipulowania plikami. Jest to przydatne, aby umożliwić użytkownikom tworzenie archiwów (tar, ar, .deb itp.) Z plikami w nich z uprawnieniami / prawami roota. Bez fakeroot należałoby mieć uprawnienia roota, aby tworzyć pliki składowe archiwów z odpowiednimi uprawnieniami i prawem własności, a następnie spakować je, lub trzeba byłoby tworzyć archiwa bezpośrednio, bez korzystania z archiwizatora.

Fakeroot pozwala użytkownikom innym niż root tworzyć archiwa zawierające pliki należące do roota, co jest kluczową częścią generowania i dystrybucji binarnych pakietów oprogramowania w systemie Linux. Bez tego fakerootarchiwa pakietów musiałyby zostać wygenerowane podczas działania jako rzeczywisty katalog główny, aby zawierały poprawne prawa własności i uprawnienia do plików. To byłoby zagrożenie bezpieczeństwa. Budowanie i pakowanie potencjalnie niezaufanego oprogramowania jest ogromną ekspozycją, jeśli jest wykonywane przy użyciu root rootów. Dzięki temu fakerootnieuprzywilejowany użytkownik z nieuprzywilejowanymi plikami może nadal generować archiwa zawierające pliki z prawami roota. ²⁾

Ale to nie stanowi zagrożenia bezpieczeństwa, ponieważ nic w archiwum nie jest faktycznie własnością root, dopóki pliki nie zostaną WYCIĄGNIĘTE . I nawet wtedy pliki zostaną wyodrębnione z nienaruszonymi uprawnieniami roota tylko wtedy, gdy zrobi to uprzywilejowany użytkownik. Ten krok - gdzie afakeroot archiwum wspomagane zawierające pliki „root” jest wyodrębniane przez uprzywilejowanego użytkownika - w tym momencie „fałszywy” root staje się rzeczywisty. Do tego momentu żadne rzeczywiste uprawnienia roota nie są nigdy uzyskiwane ani omijane.

Uwagi

1. Fakeroot odrodził niektórych konkurentów / naśladowców, którzy będą maskować się, fakerootjakby byli zainstalowani, w tym fakeroot-ngi pseudo. Ale strona podręcznika IMHO ani strona „naśladowcy” nie jest tak jasna, aby dojść do sedna tego pytania. Trzymaj się oryginalnego, jedynego fakerootOG

2. Inne systemy dystrybucji / pakowania rozwiązują ten problem, po prostu nie używając własności root w swoich archiwach pakietów. Na przykład w Fedorze oprogramowanie może być kompilowane, instalowane i pakowane przez nieuprzywilejowanego użytkownika bez konieczności fakeroot. Wszystko to odbywa się w przestrzeni użytkownika $HOME/rpmbuild/, a normalnie uprzywilejowane kroki, takie jak make installprzekierowanie (za pośrednictwem mechanizmów takich jak --prefixi DESTDIR) do $HOME/rpmbuild/BUILDROOT/hierarchii, którą można uznać za rodzaj przestrzeni „fakechroot” (bez faktycznego użyciafakechroot ).

   Ale nawet podczas tego make installwszystko jest wykonywane jako własność nieuprzywilejowanego użytkownika. Wyodrębniona własność i uprawnienia do pliku będą domyślnie ustawione na root,rooti 0644(lub 0755dla plików wykonywalnych), chyba że zostaną zastąpione w .specpliku definicji pakietu ( ), w którym to przypadku są przechowywane jako metadane w końcowym pakiecie. Ponieważ do momentu instalacji (uprzywilejowanego) procesu instalacji pakietu rpm nie są stosowane żadne uprawnienia ani prawa własności, ani root, ani nie fakerootsą potrzebne podczas pakowania. Ale fakeroottak naprawdę jest to tylko inna ścieżka do tego samego rezultatu.