Mount Namespace

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Podstawowe informacje

Mount namespace to funkcja jądra Linux, która zapewnia izolację punktów montowania systemu plików widocznych dla grupy procesów. Każdy mount namespace ma swój własny zestaw punktów montowania systemu plików, a zmiany w punktach montowania w jednym namespace nie wpływają na inne namespace. Oznacza to, że procesy działające w różnych mount namespaces mogą mieć różne widoki hierarchii systemu plików.

Mount namespaces są szczególnie przydatne w konteneryzacji, gdzie każdy kontener powinien mieć swój własny system plików i konfigurację, izolowaną od innych kontenerów i systemu gospodarza.

Jak to działa:

1. Gdy nowy mount namespace jest tworzony, jest inicjowany kopią punktów montowania z jego nadrzędnego namespace. Oznacza to, że w momencie utworzenia nowy namespace dzieli ten sam widok systemu plików co jego nadrzędny. Jednak wszelkie późniejsze zmiany w punktach montowania w obrębie namespace nie wpłyną na nadrzędny ani inne namespaces.

2. Gdy proces modyfikuje punkt montowania w swoim namespace, na przykład montując lub odmontowując system plików, zmiana jest lokalna dla tego namespace i nie wpływa na inne namespaces. Umożliwia to każdemu namespace posiadanie własnej niezależnej hierarchii systemu plików.

3. Procesy mogą przechodzić między namespaces za pomocą wywołania systemowego setns(), lub tworzyć nowe namespaces za pomocą wywołań systemowych unshare() lub clone() z flagą CLONE_NEWNS. Gdy proces przechodzi do nowego namespace lub go tworzy, zacznie używać punktów montowania związanych z tym namespace.

4. Deskryptory plików i inody są współdzielone między namespaces, co oznacza, że jeśli proces w jednym namespace ma otwarty deskryptor pliku wskazujący na plik, może przekazać ten deskryptor pliku do procesu w innym namespace, a oba procesy będą miały dostęp do tego samego pliku. Jednak ścieżka pliku może nie być taka sama w obu namespaces z powodu różnic w punktach montowania.

Laboratorium:

Utwórz różne namespaces

CLI

sudo unshare -m [--mount-proc] /bin/bash

Mountując nową instancję systemu plików /proc, używając parametru --mount-proc, zapewniasz, że nowa przestrzeń montowania ma dokładny i izolowany widok informacji o procesach specyficznych dla tej przestrzeni.

Błąd: bash: fork: Nie można przydzielić pamięci

Gdy unshare jest wykonywane bez opcji -f, napotykany jest błąd z powodu sposobu, w jaki Linux obsługuje nowe przestrzenie nazw PID (identyfikator procesu). Kluczowe szczegóły i rozwiązanie są opisane poniżej:

1. Wyjaśnienie problemu:

• Jądro Linuxa pozwala procesowi na tworzenie nowych przestrzeni nazw za pomocą wywołania systemowego unshare. Jednak proces, który inicjuje tworzenie nowej przestrzeni nazw PID (nazywany "procesem unshare"), nie wchodzi do nowej przestrzeni; tylko jego procesy potomne to robią.

• Uruchomienie %unshare -p /bin/bash% uruchamia /bin/bash w tym samym procesie co unshare. W konsekwencji, /bin/bash i jego procesy potomne znajdują się w oryginalnej przestrzeni nazw PID.

• Pierwszy proces potomny /bin/bash w nowej przestrzeni staje się PID 1. Gdy ten proces kończy działanie, uruchamia czyszczenie przestrzeni, jeśli nie ma innych procesów, ponieważ PID 1 ma specjalną rolę przyjmowania osieroconych procesów. Jądro Linuxa następnie wyłączy przydzielanie PID w tej przestrzeni.

2. Konsekwencja:

• Zakończenie PID 1 w nowej przestrzeni prowadzi do wyczyszczenia flagi PIDNS_HASH_ADDING. Skutkuje to niepowodzeniem funkcji alloc_pid w przydzieleniu nowego PID podczas tworzenia nowego procesu, co skutkuje błędem "Nie można przydzielić pamięci".

3. Rozwiązanie:

• Problem można rozwiązać, używając opcji -f z unshare. Ta opcja sprawia, że unshare fork'uje nowy proces po utworzeniu nowej przestrzeni nazw PID.

• Wykonanie %unshare -fp /bin/bash% zapewnia, że polecenie unshare samo staje się PID 1 w nowej przestrzeni. /bin/bash i jego procesy potomne są następnie bezpiecznie zawarte w tej nowej przestrzeni, co zapobiega przedwczesnemu zakończeniu PID 1 i umożliwia normalne przydzielanie PID.

Zapewniając, że unshare działa z flagą -f, nowa przestrzeń nazw PID jest prawidłowo utrzymywana, co pozwala /bin/bash i jego podprocesom działać bez napotkania błędu przydzielania pamięci.

Docker

docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash

Sprawdź, w jakiej przestrzeni nazw znajduje się twój proces

ls -l /proc/self/ns/mnt
lrwxrwxrwx 1 root root 0 Apr  4 20:30 /proc/self/ns/mnt -> 'mnt:[4026531841]'

Znajdź wszystkie przestrzenie montowania

sudo find /proc -maxdepth 3 -type l -name mnt -exec readlink {} \; 2>/dev/null | sort -u
# Find the processes with an specific namespace
sudo find /proc -maxdepth 3 -type l -name mnt -exec ls -l  {} \; 2>/dev/null | grep <ns-number>

Wejście do przestrzeni nazw montowania

nsenter -m TARGET_PID --pid /bin/bash

Również, możesz wejść do innej przestrzeni procesów tylko jeśli jesteś root. I nie możesz wejść do innej przestrzeni bez deskryptora wskazującego na nią (jak /proc/self/ns/mnt).

Ponieważ nowe montaże są dostępne tylko w obrębie przestrzeni, możliwe jest, że przestrzeń zawiera wrażliwe informacje, które mogą być dostępne tylko z niej.

Zamontuj coś

# Generate new mount ns
unshare -m /bin/bash
mkdir /tmp/mount_ns_example
mount -t tmpfs tmpfs /tmp/mount_ns_example
mount | grep tmpfs # "tmpfs on /tmp/mount_ns_example"
echo test > /tmp/mount_ns_example/test
ls /tmp/mount_ns_example/test # Exists

# From the host
mount | grep tmpfs # Cannot see "tmpfs on /tmp/mount_ns_example"
ls /tmp/mount_ns_example/test # Doesn't exist

Odniesienia

• https://stackoverflow.com/questions/44666700/unshare-pid-bin-bash-fork-cannot-allocate-memory

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Wsparcie dla HackTricks

• Sprawdź plany subskrypcyjne!

• Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @hacktricks_live.

• Dziel się trikami hackingowymi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów na githubie.