Come mai nessun core dump viene creato quando un'applicazione ha impostato SUID?

Configuro il mio ambiente per creare un dump principale di tutto ciò che si arresta in modo anomalo, tuttavia quando eseguo un programma con SUID impostato su un utente diverso rispetto all'utente che esegue non crea un dump principale. Qualche idea sul perché questo potrebbe essere? Non sono riuscito a trovarlo da nessuna parte sul Web, penso che sia una sorta di funzione di sicurezza, ma vorrei disabilitarlo ...

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)

Modifica: per farlo funzionare nel modo più sicuro possibile ora ho il seguente script per configurare l'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

Ora non resta che aggiungere ACL a / var / coredumps in modo che gli utenti possano solo aggiungere file e non modificarli né leggerli mai più. L'unico aspetto negativo è che avrei ancora un problema con le applicazioni chroot che avrebbero bisogno di bind mountqualcosa del genere.

La memoria di un programma setuid potrebbe (probabilmente, anche) contenere dati riservati. Quindi il dump del core dovrebbe essere leggibile solo da root.

Se il dump principale è di proprietà di root, non vedo un evidente buco nella sicurezza, anche se il kernel dovrebbe stare attento a non sovrascrivere un file esistente.

Linux disabilita i core dump per i programmi setxid. Per abilitarli, è necessario eseguire almeno le seguenti operazioni (non ho verificato che ciò sia sufficiente):

• Abilitare i dump core setuid in generale impostando fs.suid_dumpablesysctl su 2, ad es echo 2 >/proc/sys/fs/suid_dumpable. Con . (Nota: 2, non 1; 1 significa "Sto eseguendo il debug del sistema nel suo insieme e voglio rimuovere tutta la sicurezza".)
• Chiama prctl(PR_SET_DUMPABLE, 1)dal programma.

Il dump principale contiene una copia di tutto ciò che era in memoria al momento dell'errore. Se il programma è in esecuzione suid, ciò significa che deve accedere a qualcosa a cui l'utente non ha accesso. Se il programma ottiene tali informazioni quindi scarica il core, sarai in grado di leggere quelle informazioni privilegiate.

Dal tuo esempio sopra, sembra che tu sia in grado di ottenere un dump principale quando esegui come root o se rimuovi l'escalation dei privilegi.

Mentre potrebbe essere utile (per gli sviluppatori solo pensare) avere un facile accesso a un coredump da un programma setuid, è un buco nella sicurezza e dovrebbe essere lasciato sul posto.

Ho deciso che condividerò anche il mio caso d'uso, fino a quando non lo dimenticherò. Potrebbe essere utile anche per il mio futuro poiché stavo risolvendo lo stesso problema mesi fa e mi ci è voluto troppo tempo per scoprirlo ancora una volta. Ok. in realtà non è core-dump, ma stack trace che è anche utile.

Problema: non ho idea di cosa stia succedendo lì:

sudo id
Segmentation fault

Soluzione: spostare il bit di suid da sudoper valgrindfunzionare correttamente:

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

Se è installato debuginfo, viene scritto un bel backtrace.