2015-04-16 14 views
13

Ho notato che alcuni dei miei utenti non hanno avuto un discredito dopo l'arresto anomalo, anche quando tutto il resto nella loro configurazione sembrava corretto.Eliminare i privilegi di root e generare ancora il numero di core

Dopo aver letto la pagina di core(5) uomo un mucchio di volte ho notato questo particolare punto:

[Un file core dump non viene prodotto se] Il processo è in esecuzione un set-user-ID (set -group-ID) programma di proprietà di un utente (gruppo) diverso dall'ID utente reale (gruppo) del processo.

mio demone non è setuid root, ma in un sacco di configurazioni che è iniziato come root, e se il file .conf specifica un nome utente, fa cadere i privilegi, con la solita combinazione di:

setgid(gid); 
setuid(uid); 

Quando esegue questa operazione, non si generano più coredumps. Tutto il resto nell'ambiente sembra essere corretto, rimuovendo quelle chiamate (e rimanendo come root) mi si ottiene come al solito.

Ho provato a cambiare l'uid "reale"/gid come pagina uomo sembrava suggerire, chiamando il meno-portatile setresgid/uid che sembrano essere suggerito spesso a cadere i privilegi in modo permanente:

setresgid(gid, gid, gid); 
setresuid(uid, uid, uid); 

Mi aspettavo che risolvesse il problema ma ... non migliorava affatto. Ancora niente salti.

Sooo ... ora cosa?


Codice di prova:

#include <stdlib.h> 

int main(int argc, char **argv) { 
     if (argc > 1) { 
       setgid(atoi(argv[2])); 
       setuid(atoi(argv[1])); 
     } 
     abort(); 
} 

Usage:

  • ./a.out come qualsiasi utente a poco interrompere senza setgid/setuid
  • ./a.out 1000 100 (dove 1000 è uid e 100 è gid) come root per rilasciare i privilegi e guardare i decadimenti non accadere.
  • Bonus funzione non intenzionale: passare un parametro, non due, per ottenere SIGSEGV anziché SIGABRT.

ho già provato questo in Arch Linux, CentOS 6.5 e OpenBSD 5.3

+0

E l'utente/gruppo non privilegiato non ha disabilitato i dump di core ('ulimit -c' non riporta' 0')? –

+0

Sì, illimitato da entrambi i lati. E eseguirlo come uid (0 e 1000) senza le chiamate setuid/gid si ottiene un risultato negativo. – dequis

+0

Devi davvero essere più specifico per questo genere di cose, le distribuzioni di Linux fanno cose diverse qui. In particolare, ci sono moduli PAM là fuori, ricorda Ubuntu, che interagiscono con la produzione di core dump. –

risposta

2

Per forzare un processo su core dump, utilizzare la chiamata di sistema prctl.

prctl(PR_SET_DUMPABLE, 1, 0, 0, 0); 
+0

Interessante! Lo proverò più tardi. Sembra essere linux specifico però, e anche i BSD hanno questo comportamento – dequis

+0

Su openbsd disinserire il bit KERN_NOSUIDCOREDUMP con sysctl() http://nixdoc.net/man-pages/OpenBSD/sysctl.3.html – clockley1

0

Devi abilitare core dump per le applicazioni che hanno cambiato i loro privilegi:

echo 2 > /proc/sys/fs/suid_dumpable 

consiglio che di mettilo in /etc/rc.local.


Per esempio, ecco quello che ho lì:

# This is to enable debugging as a normal user, rather than root 
sysctl kernel.yama.ptrace_scope=0 

# This is a convenient core file pattern 
# '%e' is the name of the process 
# '%p' is the pid of process 
sysctl kernel.core_pattern="/tmp/core.%e.%p" 

# Enable dump for processes with lowered privileges 
echo 2 > /proc/sys/fs/suid_dumpable 

# Remove limit for the size of core files 
ulimit -c unlimited 

Edit:

Si può dare un'occhiata a questa libreria pulito, che consente di scrivere manualmente core dump in un file personalizzato: https://code.google.com/p/google-coredumper/

Credo che sia esattamente ciò di cui hai bisogno.

+0

Grazie! Ma io sono solo lo sviluppatore del demone, non ho il controllo sui sistemi in cui verrà installato. Sto cercando di sistemarlo in modo da poter ottenere i coredumps dagli utenti che non si aspettavano un crash, quindi .. se dovessi dirglielo, potrei anche dirgli di eseguire gdb. Alla ricerca di qualcosa che posso risolvere nel mio codice. – dequis

+1

@dequis, sfortunatamente, non conosco il modo di farlo * dalla tua parte *. È una sorta di buco di sicurezza, ed è per questo che il core dumping è disabilitato, a meno che non lo abiliti manualmente (come un 'root'). Nel tuo caso cali i privilegi quindi, per quanto mi riguarda, sembra sicuro. Ma ci sono applicazioni che promuovono privilegi ('passwd'), e consentire loro di scaricare core è un rischio enorme. – GreenScape

+0

@dequis, leggi le mie ultime modifiche, speriamo che sia ciò di cui hai bisogno. – GreenScape