Ogni sistema ha bisogno di processi in esecuzione per raggiungere il suo obiettivo primario. Ma a volte le cose vanno male e un processo può bloccarsi. A seconda della configurazione del sistema viene creato un core dump. In altre parole, viene memorizzata un’istantanea della memoria del processo arrestato. Il termine nucleo in realtà si riferisce alla vecchia memoria del nucleo magnetico da vecchi sistemi. Anche se questo tipo di memoria non viene più utilizzato, usiamo ancora questo termine sui sistemi Linux. Abbastanza per la storia, configuriamo il nostro sistema Linux per gestire correttamente i core dump.
Indice
Linux e core dump
La maggior parte dei sistemi Linux ha core dump abilitati per impostazione predefinita. Come sempre, c’è un compromesso da fare qui. Da un lato, vogliamo raccogliere dati per migliorare la stabilità e la risoluzione dei problemi. Dall’altro, vogliamo limitare i dati di debug ed evitare perdite di dati sensibili.
La prima opzione è buona per le macchine in cui è necessario indagare i programmi instabili, come la workstation di uno sviluppatore. La seconda opzione è più adatta per i sistemi di produzione che memorizzano o elaborano dati sensibili.
Disabilita core dump
Ha senso disabilitare qualsiasi core dump su Linux per impostazione predefinita per tutti i tuoi sistemi. Questo perché i file occupano spazio su disco e possono contenere dati sensibili. Quindi, se non hai bisogno dei core dump per la risoluzione dei problemi, disabilitarli è un’opzione sicura.
Opzione 1: ulimit tramite il file di configurazione
Per disabilitare i core dump dobbiamo impostare un valore ulimit. Questo viene fatto tramite / etc / security / limits.conf file e definisce alcune restrizioni specifiche della shell.
Buono a sapersi è che ci sono limiti soft e hard. Un limite rigido è qualcosa che non può mai essere sovrascritto, mentre un limite morbido potrebbe essere applicabile solo per utenti specifici. Se vogliamo assicurarci che nessun processo possa creare un core dump, possiamo impostarli entrambi a zero. Sebbene possa sembrare un booleano (0 = False, 1 = True), in realtà indica la dimensione consentita.
* nucleo morbido 0
* nucleo duro 0
Il segno asterisco significa che si applica a tutti gli utenti. La seconda colonna indica se si desidera utilizzare un limite rigido o morbido, seguito dalle colonne che indicano l’impostazione e il valore.
Opzione 2: configura ulimit tramite profilo
I valori di ulimit possono essere impostati anche tramite /etc/profile o un file personalizzato in /etc/profile.d directory. Quest’ultimo è preferito quando è disponibile. Ad esempio creando un file denominato /etc/profile.d/disable-coredumps.sh.
eco “ulimit-c 0 > / dev / null 2>&1” > /ecc / profilo.d / disable-coredumps.sh
Questo comando aggiunge l’impostazione a un nuovo file e imposta il limite soft e hard a zero. Ogni utente ottiene questo valore quando accede.
Oltre alle impostazioni ulimit, ci sono anche le impostazioni del kernel da considerare. Quindi scegliere una delle opzioni è il primo passo.
Opzione 3: disabilitare tramite systemd
Quando si utilizza systemd e il servizio systemd-coredump, modificare coredump.file conf. Questo file si trova molto probabilmente in / usr/lib / sysctl.d / 50-carotaggio.conf. Poiché systemd ha un set di file, assicurati di controllare gli altri come:
Impostare l’impostazione di archiviazione su ‘nessuno’. Quindi configurare ProcessSizeMax per limitare la dimensione massima a zero.
Storage = none
ProcessSizeMax=0
In genere è sufficiente ricaricare la configurazione systemd.
systemctl daemon-reload
Se questo crea ancora un core dump, quindi riavviare il sistema.
Disattiva i processi setuid scaricando la loro memoria
I processi con autorizzazioni elevate (o il bit setuid), potrebbero essere ancora in grado di eseguire un core dump, a seconda delle altre impostazioni. Poiché questi processi di solito hanno più accesso, potrebbero contenere segmenti di dati più sensibili in memoria. Quindi è ora di cambiare anche questo. Il comportamento può essere modificato con una chiave sysctl o direttamente tramite il file system / proc. Per le impostazioni permanenti, in genere vengono utilizzati il comando e la configurazione sysctl. Un’impostazione è chiamata “chiave”, a cui è associato un valore correlato (noto anche come coppia chiave-valore).
Per disabilitare il programma con il bit setuid da scaricare, impostare fs.suid_dumpabile a zero.
echo "fs.suid_dumpable=0" >> /etc/sysctl.conf
Ricarica la configurazione sysctl con il flag-p per attivare le modifiche apportate.
sysctl -p
Vuoi solo testare senza apportare modifiche permanenti? Usa sysctl -w seguito dalla chiave = valore.
Suggerimento: Usando sysctl puoi sintonizzare il tuo sistema ed è un buon modo per indurire il kernel Linux.
Abilita core dump
Il motivo principale per consentire core dump è per scopi di risoluzione dei problemi. La memoria scaricata del processo può essere utilizzata per problemi di debug, di solito da sviluppatori più esperti. Un fornitore di software può chiedere di abilitare core dump. Di solito per scoprire perché un processo si è schiantato in primo luogo e trovare la routine correlata che lo ha causato.
Abilitare i core dump su Linux è simile a disabilitarli, tranne che alcuni dettagli specifici dovrebbero essere configurati. Ad esempio, se hai solo bisogno di dettagli da un particolare programma, puoi utilizzare i limiti soft. Questo viene fatto usando -S che indica che si tratta di un limite morbido. -c indica la dimensione di un core dump.
ulimit -S -c 0
Il prossimo passo è consentire solo ‘my-program-to-troubleshoot’ per creare un core dump.
ulimit -S -c unlimited my-program-to-troubleshoot
Se si desidera consentire a tutti i processi di utilizzare i core dump, utilizzare la riga sopra senza il programma o impostare un limite di sistema in /etc/security/limits.conf
* soft core unlimited
Risoluzione dei problemi dei binari setuid
I binari che hanno un set di bit setuid possono essere eseguiti con i permessi di root. Questo particolare tipo di accesso deve essere limitato il più possibile. Anche per la creazione di core dump, deve essere configurato correttamente. Questo viene fatto con sysctl fs.chiave suid_dumpable.
- 0 – disabilitato
- 1 – abilitato
- 2 – abilitato con restrizioni
Quindi, se si desidera risolvere i programmi con un set di bit setuid, è possibile modificare temporaneamente il fs.suid_dumpabile a 1 o 2. Impostandolo su 2 è preferibile in quanto ciò rende i dump core leggibili solo all’utente root. Questa è una buona alternativa per i sistemi con dati sensibili. Impostare l’opzione su 1 è più adatto per i sistemi di sviluppo personale.
Crea normali file di dump
Uno dei grandi misteri con i sistemi Linux è dove si trovano i core dump. Linux ha un trucco in atto per catturare core dump. Questa particolare impostazione viene eseguita tramite il kernel sysctl.impostazione core_pattern o / proc/sys/kernel / core_pattern. La maggior parte dei sistemi avrà una pipe (|) in questa impostazione per indicare che un programma deve occuparsi dei dati generati. Quindi, se ti chiedi dove va il tuo core dump, segui il tubo!
I core dump sui sistemi Ubuntu sono in genere in Apport. Per i sistemi basati su Red Hat può essere reindirizzato a Automatic Bug Reporting Tool (ABRT).
È possibile modificare temporaneamente questa impostazione, facendo eco “core” a quel file, o utilizzare l’utilità sysctl.
sysctl -w kernel.core_pattern=core
Una nota importante è che questo cambiamento potrebbe non essere sufficiente. Dipende anche dal tuo fs.impostazione suid_dumpable. Un avviso verrà registrato sul tuo logger del kernel se questo è il caso.
Sep 06 15:51:18 hardening kernel: Unsafe core_pattern usato con suid_dumpable=2. Gestore di tubi o percorso di scarico del nucleo completamente qualificato richiesto.
Quando necessario imposta core_pattern su un percorso completo, facoltativamente con variabili che definiscono chi lo stava eseguendo, il PID, ecc.
kernel sysctl-w.core_pattern= / var / crash / nucleo.%u.%e. % p
In questo esempio, i nostri dump conterranno l’ID utente, il nome del programma e l’ID del processo.
Systemd core dump
Quando si utilizza una moderna distribuzione Linux è molto probabile che systemd sia abilitato. Potrebbe essere necessario sovrascrivere le impostazioni tramite / etc / sysctl.d / 50-carotaggio.conf e definire come e dove si desidera memorizzare i core dump.
Usando systemd-coredump
Il tuo kernel.core_pattern può essere definito per utilizzare l’utilità systemd-coredump. Il percorso predefinito in cui sono memorizzati i core dump è quindi in / var/lib/systemd / coredump.
Testare la configurazione
La maggior parte degli altri tutorial ti dà solo le impostazioni da configurare. Ma come faresti a sapere che le cose funzionano come previsto? Avrete bisogno di testarlo!
Crea un core dump
Opzione 1: Crea un programma instabile
Creiamo un programma semplice. Il suo obiettivo principale è quello di bloccarsi quando viene eseguito e quindi creare opzionalmente un core dump. Installa gcc sul tuo sistema e crea un crash del file.c nella tua home directory.
int main(){ return 1/0;}
Questo programma avvierà la funzione principale e restituirà un valore intero (numero). Tuttavia, sta dividendo 1 per zero, che non è consentito e si bloccherà. Il prossimo passo è compilare il nostro piccolo programma buggy.
Il nostro piccolo programma instabile
Anche il compilatore mostra che il nostro programma contiene un problema serio e visualizza un avviso a riguardo. Ora eseguiamo e vediamo se questo è il caso.
Un bel incidente!
Da questa singola riga, possiamo effettivamente imparare alcune cose. Prima di tutto che ha chiuso con un’eccezione, in particolare riferendosi ai punti mobili. Questo è un formato numerico decimale per i programmi, quindi potrebbe indicare che qualcosa è successo mentre si faceva un po ‘ di matematica. Un’altra conclusione è che il nucleo viene scaricato a causa dell’aggiunta (core dumped) alla fine. Se i core dump fossero disabilitati, questo non apparirebbe.
Ottimo, quindi con questo crash sopra abbiamo ora un file scaricato, giusto? Non esattamente. A seconda della distribuzione Linux le cose potrebbero non essere così semplici come sembra. Ogni distribuzione si occupa in modo diverso con core dump e le impostazioni predefinite. Le distribuzioni Linux più recenti usano anche systemd ora e le regole sono state leggermente modificate anche con questo. A seconda della configurazione, potrebbe essere necessario cercare i core dump. Quindi, ecco alcuni suggerimenti per garantire che tutto sia configurato correttamente.
Opzione 2: uccidere un processo in esecuzione
Invece di utilizzare un programma di test, è anche possibile terminare un processo esistente. Questo viene fatto utilizzando il SIGSEGV, che è l’abbreviazione di segmentation violation e noto anche come segmentation fault.
kill -s SIGSEGV PID
Se sostituisci PID con ” $ $ ” il programma corrente (molto probabilmente la tua shell) si bloccherà. Tutto per la scienza, giusto?
Opzione 3: utilizzo di gdb
Se è installato lo strumento di debug per sviluppatori gdb, collegarlo a un processo di scelta utilizzando il relativo ID processo (PID).
gdb -p 1234
Quindi, quando al prompt gdb, genera il core dump richiamando l’istruzione generate-core-file. Dopo aver usato questo comando, dovrebbe restituire l’output.
Salvato core file cor.1234
Controllare Impostazioni ulimit
Le impostazioni ulimit definiscono cosa può accadere quando un programma si blocca. Quindi è sicuro controllare prima questo, sia per root che per un normale utente non privilegiato.
Controlla il limite rigido per le discariche core:
ulimit -H -c
Controllare limite morbido pure:
ulimit -S -c
Controllare il core pattern
Utilizzare il file system /proc per raccogliere il valore e modificarlo temporaneamente durante il test. Se si preferisce utilizzare sysctl, quindi interrogare il kernel.chiave core_pattern.
cat /proc/sys/kernel/core_pattern
Potrebbe mostrare qualcosa del genere:
|/usr/share/apport/apport %p %s %c %P
In questo caso, un arresto anomalo verrà reindirizzato all’utilità apport. Quindi questo significa che gli arresti anomali verranno analizzati da Apport. Normalmente i crash si trovano in / var / crash, ma possono anche essere in / var / spool o / var / lib / systemd / coredump su altre distribuzioni Linux.
Controlla il journal (systemd)
Nel nostro caso journalctl mostra il nostro crash, quindi è un inizio.
Dopo aver controllato tutte queste impostazioni dovresti essere in grado di creare un bel core dump.
Conclusione
I core dump possono essere utili per la risoluzione dei problemi, ma un disastro per la perdita di dati sensibili. Disabilita i core dump quando possibile e abilitali solo quando veramente necessario. In tal caso verificare se i file sono memorizzati in modo sicuro, in modo che gli utenti normali non possono vedere i dati. E indipendentemente da quale scelta hai fatto, verifica sempre se la tua configurazione funziona esattamente come ti aspetti che funzioni.