Os comandos do BusyBox são realmente integrados?

Question

Eu estava lendo a famosa Lenda de recuperação do Unix , e me ocorreu pensar :

Se eu tivesse um shell BusyBox aberto, e o binário do BusyBox fosse ele mesmo deletado, eu ainda seria capaz de usar todos os comandos incluídos no binário do BusyBox?

É claro que eu não seria capaz de usar a versão BB desses comandos a partir de outro shell em execução como bash , já que o arquivo BusyBox em si não estaria disponível para bash abrir e corre. Mas de dentro da instância em execução do BusyBox, parece-me que poderia haver dois métodos pelos quais o BB executaria um comando:

1. Poderia bifurcar e executar uma nova instância do BusyBox, chamando-o usando o nome apropriado - e lendo o arquivo BusyBox do disco para fazer isso.
2. Ele poderia bifurcar e executar alguma lógica interna para executar o comando especificado (por exemplo, executando-o como uma chamada de função).

Se (1) é a maneira como o BusyBox funciona, eu esperaria que certos comandos fornecidos pelo BusyBox ficassem indisponíveis a partir de uma instância em execução do BB depois que o binário BB fosse deletado.

Se (2) é como funciona, o BusyBox pode ser usado até mesmo para a recuperação de um sistema onde o próprio BB tenha sido excluído - desde que ainda haja uma instância em execução do BusyBox acessível.

Isso é documentado em algum lugar? Se não, existe uma maneira de testá-lo com segurança?

    

Answer 1

Por padrão, o BusyBox não faz nada de especial com relação aos applets que ele embutiu (os comandos listados com busybox --help ).

No entanto, se as opções FEATURE_SH_STANDALONE e FEATURE_PREFER_APPLETS estiverem habilitadas em tempo de compilação, quando BusyBox sh¹ executa um comando que é um nome de applet conhecido, ele não executa a% normalPATH lookup, mas executa seus applets integrados por meio de um atalho:

• Os applets declarados como “noexec” no código-fonte são executados como chamadas de função em um processo bifurcado. A partir do BusyBox 1.22, os seguintes applets são noexec: 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 .
• Os applets declarados como “nofork” no código-fonte são executados como chamadas de função no mesmo processo. A partir do BusyBox 1.22, os seguintes applets são nofork: [[ , [ , basename , cat , dirname , echo , false , fsync , length , logname , mkdir , printenv , printf , pwd , rm , rmdir , seq , sync , test , true , usleep , whoami , yes .
• Outros applets são realmente executados (com fork e execve ), mas em vez de fazer uma pesquisa PATH , BusyBox executa /proc/self/exe , se disponível (o que normalmente é o caso no Linux), e um caminho definido em tempo de compilação.

Isso está documentado em mais detalhes em docs/nofork_noexec.txt . As declarações do applet estão em include/applets.src.h no código-fonte.

A maioria das configurações padrão desativa esses recursos, para que o BusyBox execute comandos externos como qualquer outro shell. O Debian ativa esses recursos nos pacotes busybox e busybox-static .

Portanto, se você tiver um executável do BusyBox compilado com FEATURE_SH_STANDALONE e FEATURE_PREFER_APPLETS , poderá executar todos os comandos do BusyBox a partir de um shell do BusyBox, mesmo que o executável seja excluído (exceto os applets que não estão listados acima, se/proc/self/exe não está disponível).

¹ _{Na verdade, existem duas implementações de "sh" no BusyBox - ash e hush - mas elas se comportam da mesma maneira a esse respeito.}

    

Answer 2

is there a way to safely test it? com a imagem genérica do x86 openwrt:

A maioria dos comandos não é interna, mas alguns são, como echo e printf . Um arquivo binário com conteúdo arbitrário pode ser criado usando printf , mas chmod +x será um problema.