Czytałem słynną Legendę odzyskiwania systemu Unix i przyszło mi do głowy, aby się zastanawiać:
Gdybym miał otwartą powłokę BusyBox, a sam plik binarny BusyBox zostałby usunięty, czy nadal będę mógł używać wszystkich poleceń zawartych w pliku binarnym BusyBox?
Oczywiście nie byłbym w stanie użyć wersji BB tych poleceń z innej działającej powłoki, takiej jak bash
, ponieważ sam plik BusyBox byłby niedostępny bash
do otwarcia i uruchomienia. Ale z działającej instancji BusyBox wydaje mi się, że mogą istnieć dwie metody, za pomocą których BB uruchamia polecenie:
- Może rozwidlać i wykonywać nową instancję BusyBox, wywołując ją przy użyciu odpowiedniej nazwy - i w tym celu odczytując plik BusyBox z dysku.
- Może rozwidlać i wykonywać wewnętrzną logikę, aby uruchomić określone polecenie (na przykład uruchamiając je jako wywołanie funkcji).
Jeśli (1) jest sposobem działania BusyBox, oczekiwałbym, że niektóre polecenia dostarczone przez BusyBox staną się niedostępne z działającej instancji BB po usunięciu pliku binarnego BB.
Jeśli (2) działa, BusyBox może być użyty nawet do odzyskania systemu, w którym usunięto sam BB - pod warunkiem, że nadal dostępna jest działająca instancja BusyBox.
Czy jest to gdziekolwiek udokumentowane? Jeśli nie, czy istnieje sposób na bezpieczne przetestowanie?
źródło
is there a way to safely test it?
Pobierz ogólnyopenwrt
obraz x86 i dołącz obraz do nowej maszyny VirtualBoxPATH
? Czy przyjmuje wartość domyślnąPATH
?Odpowiedzi:
Domyślnie BusyBox nie robi nic specjalnego w odniesieniu do wbudowanych apletów (komendy wymienione jako
busybox --help
).Jeśli jednak opcje
FEATURE_SH_STANDALONE
iFEATURE_PREFER_APPLETS
są włączone w czasie kompilacji, to gdy BusyBox sh¹ wykonuje polecenie o znanej nazwie apletu, nie wykonuje normalnegoPATH
wyszukiwania, ale uruchamia wbudowane aplety za pomocą skrótu:chgrp
,chmod
,chown
,cksum
,cp
,cut
,dd
,dos2unix
,env
,fold
,hd
,head
,hexdump
,ln
,ls
,md5sum
,mkfifo
,mknod
,sha1sum
,sha256sum
,sha3sum
,sha512sum
,sort
,tac
,unix2dos
.[[
,[
,basename
,cat
,dirname
,echo
,false
,fsync
,length
,logname
,mkdir
,printenv
,printf
,pwd
,rm
,rmdir
,seq
,sync
,test
,true
,usleep
,whoami
,yes
.fork
iexecve
), ale zamiastPATH
wyszukiwania, BusyBox wykonuje się/proc/self/exe
, jeśli są dostępne (co zwykle ma miejsce w Linuksie), a ścieżka jest zdefiniowana w innym czasie.Jest to udokumentowane bardziej szczegółowo w
docs/nofork_noexec.txt
. Deklaracje apletów znajdują się winclude/applets.src.h
kodzie źródłowym.Większość domyślnych konfiguracji wyłącza te funkcje, dzięki czemu BusyBox wykonuje polecenia zewnętrzne, jak każda inna powłoka. Debian włącza te funkcje zarówno w swoim pakiecie, jak
busybox
i wbusybox-static
pakietach.Więc jeśli masz skompilowany plik wykonywalny BusyBox,
FEATURE_SH_STANDALONE
iFEATURE_PREFER_APPLETS
możesz wykonać wszystkie polecenia BusyBox z powłoki BusyBox, nawet jeśli plik wykonywalny jest usunięty (z wyjątkiem apletów, które nie są wymienione powyżej, jeśli/proc/self/exe
nie są dostępne).¹ W BusyBox istnieją dwie implementacje „sh” - ash i hush - ale pod tym względem zachowują się tak samo.
źródło
FEATURE_PREFER_APPLETS
iFEATURE_SH_STANDALONE
są flagami czasu kompilacji, włączającymi lub wyłączającymi funkcje. Aplety są oznaczonenofork
inoexec
niezależnie od użytych flag. To, czy takie oznaczenia mają jakikolwiek wpływ, zależy odFEATURE_PREFER_APPLETS
włączenia. Stąd trzy możliwe zachowania: 1.FEATURE_PREFER_APPLETS
wyłączone, 2.FEATURE_PREFER_APPLETS
włączone i aplet jestnofork
, 3.FEATURE_PREFER_APPLETS
włączone i aplet jestnoexec
. Trzeci akapit w doktrynach ładnie to wyjaśnia. I ostatnia sekcja pokazuje możliwe przypadki.FEATURE_SH_STANDALONE
(która wymagaFEATURE_PREFER_APPLETS
).nofork
nie jest potrzebne. ZFEATURE_SH_STANDALONE
,/proc/self/exe
jest używany tam, gdzie ma to zastosowanie, więc będzie działać, nawet jeśli BB został usunięty . Można to sprawdzić się z dość minimalnym ryzyku na jakimkolwiek SYSTM Debian lub Arch Linux, perspektywiebusybox ash
,unset PATH
wykonaj polecenia Basin jest. To działa dobrze.cat
też niechmod
wymagają exec-ing na ścieżkę, można odzyskać plik wykonywalny wygląda następująco:cat /proc/self/exe > busybox; chmod 755 busybox
.tac
wymaga albo widocznego pliku wejściowego, który nie zawsze jest dostępny, albo wczytania całego wejścia do pamięci.cat
może odczytać dane wejściowe od początku do końca, odrzucając to, co już zostało przetworzone. Jest o wiele łatwiejszy do wdrożenia i jest również o wiele częściej używany, więc sensowniej jest go zoptymalizować.FEATURE_xxx
jest opcją kompilacji w czasie dla BusyBox jako całości. Wskazania nofork i noexec mają znaczenie tylko wtedy, gdyFEATURE_PREFER_APPLETS
są aktywne (przynajmniej w celu wykonania polecenia w powłoce są one również używane w innych kontekstach).is there a way to safely test it?
Z ogólnym obrazem openwrt x86:Większość poleceń nie jest wbudowana, ale niektóre są takie jak
echo
iprintf
. Plik binarny z dowolną zawartością można utworzyć za pomocąprintf
, alechmod +x
będzie to problem.źródło
/bin/ash -> busybox
.FEATURE_SH_STANDALONE
jest włączona, nie dostaniesz tego zachowania. Drugimv
będzie działał idealnie dobrze.