Hvert system trenger kjørende prosesser for å oppfylle sitt primære mål. Men noen ganger går det galt, og en prosess kan krasje. Avhengig av konfigurasjonen av systemet opprettes en kjernedump. Med andre ord lagres et minnebilde av den krasjet prosessen. Begrepet kjerne refererer faktisk til det gamle magnetiske kjerneminnet fra eldre systemer. Selv om denne typen minne ikke lenger brukes, bruker vi fortsatt dette begrepet På Linux-systemer. Nok for historien, la Oss konfigurere Vårt Linux-system for å håndtere kjernedumper riktig.
Innholdsfortegnelse
Linux og kjernedumper
De Fleste Linux-systemer har kjernedumper aktivert som standard. Som alltid, det er en avveining å gjøre her. På den ene siden ønsker vi å samle inn data for forbedret stabilitet og feilsøking. På den annen side vil vi begrense feilsøkingsdataene og unngå å lekke sensitive data.
det første alternativet er bra for maskiner der ustabile programmer må undersøkes, som arbeidsstasjonen til en utvikler. Det andre alternativet er bedre egnet for produksjonssystemer som lagrer eller behandler sensitive data.
Deaktiver kjernedumper
det er fornuftig å deaktivere noen kjernedumper På Linux som standard for alle systemene dine. Dette skyldes at filene tar opp diskplass og kan inneholde sensitive data. Så hvis du ikke trenger kjernedumpene for feilsøkingsformål, er deaktivering av dem et trygt alternativ.
Alternativ 1: ulimit via konfigurasjonsfilen
for å deaktivere kjernedumper må vi sette en ulimit – verdi. Dette gjøres via / etc / security / limits.conf fil og definerer noen shell spesifikke restriksjoner.
Godt å vite er at det er myke og harde grenser. En hard grense er noe som aldri kan overstyres, mens en myk grense kanskje bare gjelder for bestemte brukere. Hvis vi ønsker å sikre at ingen prosess kan skape en kjernedump, kan vi sette dem begge til null. Selv om det kan se ut som en boolsk (0 = False, 1 = True), indikerer den faktisk tillatt størrelse.
* myk kjerne 0
* hard kjerne 0
stjernetegnet betyr at det gjelder for alle brukere. Den andre kolonnen sier om vi vil bruke en hard eller myk grense, etterfulgt av kolonnene som angir innstillingen og verdien.
Alternativ 2: konfigurer ulimit via profil
verdiene for ulimit kan også settes via / etc / profil eller en tilpasset fil i/etc / profilen.d directory. Sistnevnte er foretrukket når den er tilgjengelig. For eksempel ved å opprette en fil som heter /etc/profile.d/disable-coredumps.sh.
ekko «ulimit-c 0 > / dev / null 2>&1» > /etc / profil.d / deaktiver-coredumps.sh
denne kommandoen legger innstillingen til en ny fil og setter både myk og hard grense til null. Hver bruker får denne verdien når du logger inn.
Foruten ulimit-innstillinger, er det også kjerneinnstillinger å vurdere. Så å velge ett av alternativene er det første trinnet.
Alternativ 3: deaktiver via systemd
når du bruker systemd og systemd-coredump-tjenesten, endrer du coredump.conf-fil. Denne filen er mest sannsynlig plassert på / usr / lib / sysctl.d / 50-kjernedump.conf. Som systemd har et sett med filer, sørg for å sjekke de andre som:
Sett Lagringsinnstillingen til ‘ingen’. Konfigurer Deretter ProcessSizeMax for å begrense maksimal størrelse til null.
Lagring = ingen
ProcessSizeMax=0
Vanligvis er det tilstrekkelig å bare laste systemetd-konfigurasjonen.
systemctl daemon-reload
hvis dette fortsatt skaper en kjernedump, må du starte systemet på nytt.
Deaktiver setuid-prosesser dumping av minnet
Prosesser med forhøyede tillatelser (eller setuid-biten), kan fortsatt utføre en kjernedump, avhengig av dine andre innstillinger. Da disse prosessene vanligvis har mer tilgang, kan de inneholde mer sensitive datasegmenter i minnet. På tide å endre dette også. Oppførselen kan endres med en sysctl-nøkkel, eller direkte via / proc-filsystemet. For permanente innstillinger brukes vanligvis sysctl-kommandoen og konfigurasjonen. En innstilling kalles en nøkkel, som har en relatert verdi knyttet til den(også kjent som et nøkkelverdipar).
for å deaktivere programmet med setuid-biten å dumpe, sett fs.suid_dumpable til null.
echo "fs.suid_dumpable=0" >> /etc/sysctl.conf
Oppdater sysctl-konfigurasjonen med-p-flagget for å aktivere eventuelle endringer du har gjort.
sysctl -p
vil du bare teste uten å gjøre permanente endringer? Bruk sysctl -w etterfulgt av nøkkelen=verdi.
Tips: Ved hjelp av sysctl kan du stille systemet ditt og er en god måte å herde Linux-kjernen på.
Aktiver kjernedumper
den primære grunnen til å tillate kjernedumper er for feilsøkingsformål. Det dumpet minnet av prosessen kan brukes til feilsøkingsproblemer, vanligvis av mer erfarne utviklere. En programvareleverandør kan be om å aktivere kjernedumper. Vanligvis å oppdage hvorfor en prosess krasjet i utgangspunktet og finne den relaterte rutinen som forårsaket den.
Aktivering av kjernedumper På Linux ligner på å deaktivere dem, bortsett fra at noen få spesifikke detaljer skal konfigureres. For eksempel, hvis du bare trenger detaljer fra et bestemt program, kan du bruke myke grenser. Dette gjøres ved å bruke -Ssom indikerer at det er en myk grense. -c angir størrelsen på en kjernedump.
ulimit -S -c 0
Neste trinn er å bare tillate ‘my-program-to-feilsøke’ for å lage en kjernedump.
ulimit -S -c unlimited my-program-to-troubleshoot
hvis du vil tillate at alle prosesser bruker kjernedumper, bruk linjen over uten programmet, eller sett en systemgrense i / etc / security / limits.conf
* soft core unlimited
Feilsøk setuid-binærfiler
Binærfiler som har et setuid-bitsett, kan kjøre med rottillatelser. Denne spesielle typen tilgang må begrenses så mye som mulig. Også for opprettelse av kjernedumper, må den konfigureres riktig. Dette gjøres med sysctl fs.suid_dumpable nøkkel.
- 0 – deaktivert
- 1-aktivert
- 2-aktivert med begrensninger
Så hvis du liker å feilsøke programmer med et setuid-bitsett, kan du midlertidig endre fs.suid_dumpable til 1 eller 2. Å sette den til 2 er foretrukket da dette gjør kjernedumpene bare lesbare for rotbrukeren. Dette er et godt alternativ for systemer med sensitive data. Innstilling av alternativet til 1 er bedre egnet for personlig utviklingssystemer.
Opprett normale dumpfiler
En av De store mysteriene Med Linux-systemer er hvor kjernedumpene er plassert. Linux har et triks på plass for å fange kjernedumper. Denne bestemte innstillingen gjøres via sysctl-kjernen.core_pattern innstilling eller / proc/sys/kernel / core_pattern. De fleste systemer vil ha et rør (|) i denne innstillingen for å indikere at et program må ta vare på de genererte dataene. Så hvis du lurer på hvor kjernen dump går, følg røret!
Kjernedumper på Ubuntu-systemer går vanligvis Til Apport. For Red Hat-baserte systemer kan det bli omdirigert Til Automatic Bug Reporting Tool (ABRT).
du kan midlertidig endre denne innstillingen ved å ekko» kjerne » til den filen, eller bruke sysctl – verktøyet.
sysctl -w kernel.core_pattern=core
Et viktig notat er at denne endringen kanskje ikke er nok. Det avhenger også av din fs.suid_dumpable innstilling. En advarsel vil bli logget til kjernen logger hvis det er tilfelle.
September 06 15:51: 18 herding kernel: Usikre core_pattern brukes med suid_dumpable=2. Rørhåndterer eller fullt kvalifisert kjernedumpbane kreves.
når det er nødvendig, sett core_pattern til en full bane, eventuelt med variabler som definerer hvem som kjørte DEN, PID, etc.
sysctl-w-kjernen.core_pattern= / var / krasj / kjerne.%u.%e. % p
i dette eksemplet vil våre dumper inneholde bruker-id, programnavn og prosess-id.
Systemd core dumper
når du bruker en moderne Linux-distribusjon, vil du mest sannsynlig ha systemd aktivert. Du må kanskje overstyre innstillingene via / etc / sysctl.d / 50-kjernedump.konfigurer og definer hvordan og hvor du vil lagre kjernedumpene dine.
Bruke systemd-coredump
kjernen din.core_pattern kan defineres for å bruke systemd-coredump-verktøyet. Standardbanen der kjernedumper er lagret, er da i /var / lib / systemd / coredump.
Testing av konfigurasjonen
De fleste andre opplæringsprogrammer gir deg bare innstillingene som skal konfigureres. Men hvordan vet du at ting fungerer som forventet? Du må teste det!
Opprett en kjernedump
Alternativ 1: Opprett et ustabilt program
la oss lage et enkelt program. Dens primære mål er å krasje når den blir henrettet og deretter eventuelt opprette en kjerne dump. Installer gcc på systemet ditt og opprett en filkrasj.c i hjemmekatalogen din.
int main(){ return 1/0;}
dette programmet starter hovedfunksjonen og returnerer en heltallsverdi (tall). Det deler imidlertid 1 med null, som ikke er tillatt og vil krasje. Det neste trinnet er å kompilere vårt lille buggy-program.
vårt ustabile lille program
selv kompilatoren viser at vårt program inneholder et alvorlig problem og viser en advarsel om det. La oss nå kjøre det og se om dette er tilfelle.
en fin krasj!
fra denne ene linjen kan vi faktisk lære noen ting. Først av alt at det slutter med et unntak, spesielt med henvisning til flytende punkter. Dette er et desimaltallformat for programmer, så det kan tyde på at noe skjedde mens du gjorde litt matte. En annen konklusjon er at kjernen er dumpet på grunn av (kjerne dumpet) tillegg på slutten. Hvis kjernedumper ble deaktivert, ville dette ikke vises.
Flott, så med denne krasjen over har vi nå en dumpet fil, ikke sant? Ikke akkurat. Avhengig Av Linux-distribusjonen kan det ikke være så enkelt som det ser ut. Hver distribusjon avtaler annerledes med kjerne dumper og standardinnstillingene. De nyeste Linux-distribusjonene bruker også systemd nå, og reglene er litt endret med det også. Avhengig av konfigurasjonen må du kanskje søke etter kjernedumpene dine. Så her er noen tips for å sikre at alt er konfigurert riktig.
Alternativ 2: drep en kjørende prosess
I Stedet for å bruke et testprogram, kan du også avslutte en eksisterende prosess. DETTE gjøres VED Å bruke SIGSEGV, som er kort for segmenteringsbrudd og også kjent som en segmenteringsfeil.
kill -s SIGSEGV PID
hvis DU erstatter PID med»$$», vil det nåværende programmet (mest sannsynlig ditt skall) krasje. Alt for vitenskap, ikke sant?
Alternativ 3: bruk gdb
hvis du har utviklerens feilsøkingsverktøy gdb installert, legger du til en valgfri prosess ved hjelp av prosess-ID (pid).
gdb -p 1234
så når du er i gdb-spørringen, generer du kjernedumpen ved å påkalle generer-core-file instruction. Etter å ha brukt denne kommandoen, bør den returnere deg.
Lagret corefile kjerne.1234
Sjekk ulimit-innstillinger
ulimit-innstillingene definerer hva som kan skje når et program krasjer. Så det er trygt å først sjekke dette, for både rot og en vanlig ikke-privilegert bruker.
Kontroller hard grense for kjernedumper:
ulimit -H -c
Sjekk myk grense også:
ulimit -S -c
Kontroller kjernemønsteret
Bruk / proc-filsystemet til å samle verdien og endre den midlertidig under testingen. Hvis du foretrekker å bruke sysctl, spør du kjernen.core_pattern nøkkel.
cat /proc/sys/kernel/core_pattern
Det kan vise noe slikt:
|/usr/share/apport/apport %p %s %c %P
I dette tilfellet vil et krasj bli rørført til apport-verktøyet. Så dette betyr at krasjer skal analyseres Av Apport. Normalt krasjer finnes i /var / crash, men kan også være i / var / spool eller / var / lib / systemd / coredump på Andre Linux-distribusjoner.
Sjekk journalen (systemd)
i vårt tilfelle journalctl viser vår krasj, så det er en start.
etter å ha sjekket alle disse innstillingene, bør du kunne lage en fin kjernedump.
Konklusjon
Kjernedumper kan være nyttige for feilsøking, men en katastrofe for å lekke sensitive data. Deaktiver kjernedumper når det er mulig, og bare aktivere dem når det virkelig trengs. I så fall sjekk om filene er lagret trygt, slik at vanlige brukere ikke kan se dataene. Og uavhengig av hvilket valg du har gjort, må du alltid teste om konfigurasjonen din fungerer akkurat som du forventer at den skal fungere.