executável de rastreamento sem permissões de leitura

Question

Encontrei algum comportamento surpreendente no Ubuntu 14.04 quando uso strace em um executável, no qual não tenho permissão de leitura. Eu me pergunto se isso é um bug, ou se algum padrão exige esse comportamento obscuro.

Primeiro, vamos ver o que acontece quando eu inicio um executável comum em segundo plano e anexo a ele. Como esperado, isso funciona:

$ /bin/sleep 100 &
[2] 8078
$ strace -p 8078
Process 8078 attached
restart_syscall(<... resuming interrupted call ...>

Em seguida, tento com um executável, no qual não tenho permissões de leitura:

---x--x--x 1 root root 26280 Sep  3 09:37 sleep*

Anexar a este processo em execução não é permitido:

$ ./sleep 100 &
[1] 8089
$ strace -p 8089
strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted

Isso também é o que eu esperaria. Conceder permissão de execução sem permissão de leitura não faria muito bem se eu pudesse simplesmente anexar um depurador ao processo e efetivamente ter permissões de leitura no executável dessa maneira.

Mas se eu iniciar o executável em um processo já rastreado, tenho permissão para fazer isso:

$ strace ./sleep 100
execve("./sleep", ["./sleep", "100"], [/* 69 vars */]) = 0
brk(0)                                  = 0x9b7a000

Isso é inesperado para mim. Isso é um bug de segurança ou é um recurso exigido por um padrão?

    

Answer 1

Isso não é uma resposta, e sim uma coleção de links e pensamentos, caso alguém queira estudar também. Porque isso é bem interessante.

Resposta relacionada no Unix & Linux mencionando que é (ou foi, não é possível testar com o kernel do vanilla right agora) possível despejar binários somente de leitura dessa maneira.

A Grsecurity estava tentando corrigir essa opção de configuração e the patch propriamente dito (embora possa ter mudado desde então)

Este commit realmente faz parecer que os desenvolvedores do kernel realmente se importam apenas com o despejo de binários suid.

Mas, na verdade, a partir dessa linha , eu acho que o kernel quer evitar banir os binários ilegíveis do status da SUID. E esta linha sugere que os binários que não são dumpable não devem ser rastreáveis.

Então, à primeira vista, parece que você encontrou um bug no kernel com implicações de segurança. Mas eu não sou desenvolvedor de kernel, então não posso dizer com certeza. Eu perguntaria em LKML.

Edit: mais uma descoberta, com relação ao depurador, mencionada nos comentários da postagem original - a partir do stracing rápido (novamente) parece-me que o gdb usa os binários rastreados e /proc/<pid>/mem . Quando o binário em execução não for legível, cat /proc/<pid>/mem retornará EPERM . Se o binário for legível, retornará EIO . (Testei isso no Ubuntu 14.10, que executa vários patches de segurança, então isso pode ser diferente do kernel vanilla. Novamente, eu não tenho o kernel vanilla funcionando em algum lugar acessível: ()