Como é que nenhum dump principal é criado quando uma aplicação tem o conjunto SUID?

Question

Eu configurei meu ambiente para criar um dump principal de tudo que falha, no entanto, quando executo um programa com SUID configurado em um usuário diferente do usuário em execução, ele não cria um dump principal. Alguma ideia de por que isso pode ser? Não consegui encontrá-lo em nenhum lugar da Web, acho que é algum tipo de recurso de segurança, mas gostaria de desativá-lo ...

Problema:

$ cd /tmp
$ cat /etc/security/limits.conf | grep core
*     -     core     unlimited
root  -     core     unlimited

$ ls -l ohai
-rwsr-sr-x 1 root root 578988 2011-06-23 23:29 ohai

$ ./ohai
...
Floating point exception

$ sudo -i
# ./ohai
...
Floating point exception (core dumped)
# chmod -s ohai
# exit
$ ./ohai
...
Floating point exception (core dumped)

Editar: Para que funcione da forma mais segura possível, agora tenho o seguinte script para configurar o ambiente:

mkdir -p /var/coredumps/
chown root:adm /var/coredumps/
chmod 772 /var/coredumps/

echo "kernel.core_pattern = /var/coredumps/core.%u.%e.%p" >> /etc/sysctrl.conf
echo "fs.suid_dumpable = 2" >> /etc/sysctl.conf

echo -e "*\t-\tcore\tunlimited" >> /etc/security/limits.conf
echo -e "root\t-\tcore\tunlimited" >> /etc/security/limits.conf

Agora, tudo o que resta fazer é adicionar ACL a / var / coredumps para que os usuários possam adicionar arquivos e não modificá-los e nem mesmo lê-los novamente. A única desvantagem é que eu ainda teria um problema com aplicativos chroot'ed que precisariam de um bind mount ou algo assim.

    

Answer 1

A memória de um programa setuid pode (provavelmente, até mesmo) conter dados confidenciais. Então, o core dump teria que ser legível apenas pelo root.

Se o dump principal for de propriedade de root, não vejo uma falha de segurança óbvia, embora o kernel tenha que ter cuidado para não substituir um arquivo existente.

O Linux desativa os core dumps para programas setxid. Para ativá-los, você precisa fazer pelo menos o seguinte (não verifiquei se isso é suficiente):

• Habilite os despejos de memória setuid em geral, definindo o fs.suid_dumpable sysctl como 2, por exemplo com echo 2 >/proc/sys/fs/suid_dumpable . (Nota: 2, não 1; 1 significa "Estou depurando o sistema como um todo e quero remover toda a segurança".)
• Ligue para prctl(PR_SET_DUMPABLE, 1) do programa.

Answer 2

O dump principal contém uma cópia de tudo o que estava na memória no momento da falha. Se o programa está rodando suid, isso significa que ele precisa de acesso a algo que você, como usuário, não tem acesso. Se o programa obtiver essa informação, então despejar o núcleo, você poderá ler essa informação privilegiada.

Do seu exemplo acima, parece que você pode obter um dump principal ao ser executado como root ou se você remover o escalonamento de privilégios.

Embora possa ser útil (para desenvolvedores apenas methinks) ter acesso fácil a um coredump de um programa setuid, isso é uma falha de segurança e deve ser deixado no lugar.

    

Answer 3

Eu decidi que também compartilharei meu caso de uso, até que eu esqueça. Pode ser útil também para o futuro desde que eu estava resolvendo o mesmo problema meses atrás e me levou muito tempo para descobrir mais uma vez. Está bem. não é, na verdade, core-dump, mas rastreamento de pilha que também é útil.

Problema: não faço ideia do que está acontecendo lá:

sudo id
Segmentation fault

Solução: Mova o bit suid de sudo para valgrind funciona bem:

chmod +s /usr/bin/valgrind
chmod -s /usr/bin/sudo
valgrind /usr/bin/sudo id

Se o debuginfo estiver instalado, um bom backtrace será escrito.