php exec retornando 127 porque /bin/sh está recebendo "Permissão negada" no apache chroot

php exec retornando 127 porque /bin/sh está recebendo "Permissão negada" no apache chroot

Tenho um script php que está tentando usar exec (ou shell_exec) para executar um binário no sistema. O executivo está falhando com o código de retorno 127.

O código de retorno 127 normalmente significa comando não encontrado. Então, certifiquei-me de usar o caminho absoluto para o binário. Nenhuma mudança.

O Apache está configurado para rodar em um chroot usando o ChrootDir do Apache.

Certifiquei-me de copiar o binário para o caminho apropriado no chroot, bem como /bin/sh, e todas as bibliotecas vinculadas necessárias para ambos.

Apache (e portanto php) estão rodando como www-data. Confirmei que www-data tem permissão de leitura e execução para os binários (incluindo/bin/sh) e todas as pastas pai. Para confirmar que não é um problema de permissão de arquivo, executei o comando usando /bin/sh -c usando sudo:

sudo -u www-data /chrootdir/bin/sh -c /chrootdir/path/to/binary

E isso funciona sem problemas.

Usando strace, eu entendo isso:

execve("/bin/sh", ["sh", "-c", "/path/to/binary"], 0x7ffe436b3618 /* 11 vars */) = -1 EACCES (Permission denied)

Apenas para confirmar que o problema de permissão é para o binário sh (e aquele no chrootdir), tentei renomear /chrootdir/bin/sh para outra coisa e fiz o strace novamente e agora reclamou do arquivo não encontrado.

Então, agora sei que o problema está no acesso a /chrootdir/bin/sh quando executado via php através do apache, mas não é uma permissão do usuário www-data.

Não tenho certeza do que tentar a seguir.

Isso está rodando no Debian 10, apache 2.4.38 e php 7.3.11.

Limpei open_basedir e também desative_functions.

Confirmei que o Apache não está confinado ao apparmor, mas desativei-o mesmo assim.

Finalmente, se eu desabilitar o chroot do Apache, isso funciona.

Então, minha pergunta: existe alguma outra restrição em algum lugar que possa impedir o Apache de fazer isso?

Responder1

Graças ao comentário de @Michael Hampton acima, tentei usar o comando chroot para simplesmente fazer chroot para /chrootdir como root. Eu não era capaz de. Eu pegaria:

chroot: failed to run command ‘/bin/bash’: Permission denied

Eu também tentei, como ele sugeriu, executar /bin/sh -c /path/to/binary (mas como root, já que www-data não pode usar o comando chroot). E isso deu o mesmo erro de permissão negada.

O fato de ele ser executado corretamente quando eu usei sudo -u www-data /bin/sh ..., mas não com o comando chroot, isso significava que o problema deveria estar nas bibliotecas vinculadas.

Após uma investigação mais aprofundada, a biblioteca /chrootdir/lib64/ld-linux-x86-64.so.2 não era executável. Torná-lo executável resolveu o problema.

informação relacionada