fiecare sistem are nevoie de procese care rulează pentru a-și îndeplini obiectivul principal. Dar uneori lucrurile merg prost și un proces se poate prăbuși. În funcție de configurația sistemului, se creează un depozit de bază. Cu alte cuvinte, este stocat un instantaneu de memorie al procesului prăbușit. Termenul de bază se referă de fapt la vechea memorie de bază magnetică din sistemele mai vechi. Deși acest tip de memorie nu mai este utilizat, folosim în continuare acest termen pe sistemele Linux. Suficient pentru istorie, să configurăm sistemul nostru Linux pentru a gestiona corect depozitele de bază.
cuprins
Linux și Core haldele
cele mai multe sisteme Linux au haldele de bază activate în mod implicit. Ca întotdeauna, există un compromis de făcut aici. Pe de o parte, dorim să colectăm date pentru o stabilitate îmbunătățită și depanare. Pe de altă parte, dorim să limităm datele de depanare și să evităm scurgerea datelor sensibile.
prima opțiune este bună pentru mașinile în care trebuie investigate programe instabile, cum ar fi stația de lucru a unui dezvoltator. A doua opțiune este mai potrivită pentru sistemele de producție care stochează sau prelucrează date sensibile.
dezactivați depozitele de bază
este logic să dezactivați în mod implicit orice depozite de bază pe Linux pentru toate sistemele dvs. Acest lucru se datorează faptului că fișierele ocupă spațiu pe disc și pot conține date sensibile. Deci, dacă nu aveți nevoie de depozitele de bază în scopuri de depanare, dezactivarea acestora este o opțiune sigură.
opțiunea 1: ulimit prin fișierul de configurare
pentru a dezactiva depozitele de bază trebuie să setăm o valoare ulimit. Acest lucru se face prin /etc/security/limits.conf fișier și definește unele restricții specifice shell.
bine de știut este că există limite moi și dure. O limită hard este ceva care nu poate fi niciodată anulat, în timp ce o limită soft ar putea fi aplicabilă numai pentru anumiți utilizatori. Dacă dorim să ne asigurăm că niciun proces nu poate crea un depozit de bază, le putem seta pe amândouă la zero. Deși poate arăta ca un boolean (0 = fals, 1 = adevărat), indică de fapt dimensiunea permisă.
* miez moale 0
* miez dur 0
semnul asterisc înseamnă că se aplică tuturor utilizatorilor. A doua coloană afirmă dacă dorim să folosim o limită hard sau soft, urmată de coloanele care indică setarea și valoarea.
Opțiunea 2: Configurați ulimit prin profil
valorile pentru ulimit pot fi setate și prin /etc/profile sau un fișier personalizat în /etc/profile.D Director. Acesta din urmă este preferat atunci când este disponibil. De exemplu, prin crearea unui fișier numit /etc/profile.d/disable-coredumps.sh.
ecou „ulimit-c 0 > / dev / null 2>&1” > /etc / profil.d / dezactivați-coredumps.sh
această comandă adaugă setarea la un fișier nou și stabilește atât limita soft cât și hard la zero. Fiecare utilizator primește această valoare atunci când se conectează.
pe lângă setările ulimit, trebuie luate în considerare și setările kernel-ului. Deci, alegerea uneia dintre opțiuni este primul pas.
Opțiunea 3: dezactivați prin systemd
când utilizați systemd și serviciul systemd-coredump, schimbați coredump.fișier conf. Acest fișier este cel mai probabil localizat la /usr/lib/sysctl.d / 50-coredump.conf. Deoarece systemd are un set de fișiere, asigurați-vă că le verificați pe celelalte:
setați setarea de stocare la ‘none’. Apoi configurați ProcessSizeMax pentru a limita dimensiunea maximă la zero.
Storage = none
ProcessSizeMax=0
de obicei, este suficient să reîncărcați doar configurația systemd.
systemctl daemon-reload
dacă acest lucru creează încă o descărcare de bază, reporniți sistemul.
Disable setuid processes dumping memoria lor
procese cu permisiuni crescute (sau bit setuid), ar putea fi încă în măsură să efectueze o imagine de bază, în funcție de alte setări. Deoarece aceste procese au de obicei mai mult acces, ele pot conține segmente de date mai sensibile în memorie. Deci, timp pentru a schimba acest lucru, de asemenea. Comportamentul poate fi modificat cu o cheie sysctl sau direct prin sistemul de fișiere /proc. Pentru setările permanente, comanda și configurația sysctl sunt de obicei utilizate. O setare se numește ‘cheie’, care are o valoare înrudită atașată acesteia (cunoscută și sub numele de pereche cheie-valoare).
pentru a dezactiva programul cu bitul setuid la dump, setați fs.suid_dumpable la zero.
echo "fs.suid_dumpable=0" >> /etc/sysctl.conf
Reîncărcați configurația sysctl cu steagul-p pentru a activa orice modificări pe care le-ați făcut.
sysctl -p
vrei doar să testezi fără să faci schimbări permanente? Utilizați sysctl -w urmată de cheie = valoare.
sfat: folosind sysctl puteți regla sistemul dvs. și este o modalitate bună de a întări nucleul Linux.
Enable core haldele
motivul principal pentru a permite haldele de bază este în scopuri de depanare. Memoria dumped a procesului poate fi folosit pentru probleme de depanare, de obicei, de către dezvoltatori mai experimentați. Un furnizor de software poate solicita activarea depozitelor de bază. De obicei, pentru a descoperi de ce un proces sa prăbușit în primul rând și pentru a găsi rutina aferentă care a provocat-o.
activarea depozitelor de bază pe Linux este similară cu dezactivarea acestora, cu excepția faptului că ar trebui configurate câteva detalii specifice. De exemplu, dacă aveți nevoie doar de detalii dintr-un anumit program, puteți utiliza limite soft. Acest lucru se face folosind -Scare indică faptul că este o limită moale. -c denotă dimensiunea unui depozit de bază.
ulimit -S -c 0
următorul pas este de a permite doar ‘my-program-to-troubleshoot’ pentru a crea un depozit de bază.
ulimit -S -c unlimited my-program-to-troubleshoot
dacă doriți să permiteți tuturor proceselor să utilizeze haldele de bază, Utilizați linia de mai sus fără program sau setați o limită de sistem în /etc/security/limits.conf
* soft core nelimitat
depanarea binare setuid
binare care au un set de biți setuid, poate rula cu permisiuni root. Acest tip special de acces trebuie restricționat cât mai mult posibil. De asemenea, pentru crearea depozitelor de bază, trebuie să fie configurată corect. Acest lucru se face cu sysctl fs.cheie suid_dumpable.
- 0 – dezactivat
- 1 – activat
- 2 – activat cu restricții
deci, dacă doriți să depanați programele cu un set de biți setuid, puteți modifica temporar fs.suid_dumpable la 1 sau 2. Setarea la 2 este preferată, deoarece acest lucru face ca gropile de bază să poată fi citite doar de utilizatorul root. Aceasta este o alternativă bună pentru sistemele cu date sensibile. Setarea opțiunii la 1 este mai potrivită pentru sistemele de dezvoltare personală.
creați fișiere normale de descărcare
unul dintre marile mistere cu sistemele Linux este locul în care se află depozitele de bază. Linux are un truc pentru a captura depozitele de bază. Această setare specială se face prin kernel-ul sysctl.setarea core_pattern sau / proc/sys/kernel / core_pattern. Majoritatea sistemelor vor avea o conductă (|) în această setare pentru a indica faptul că un program trebuie să aibă grijă de datele generate. Deci, dacă vă întrebați unde se duce groapa de bază, urmați conducta!
haldele de bază de pe sistemele Ubuntu sunt de obicei de gând să Apport. Pentru sistemele bazate pe Red Hat poate fi redirecționat către instrumentul automat de raportare a erorilor (ABRT).
puteți modifica temporar această setare, repetând „core” la acel fișier sau utilizați utilitarul sysctl.
sysctl -w kernel.core_pattern=core
o notă importantă este că această schimbare ar putea să nu fie suficientă. Depinde și de fs.setarea suid_dumpable. Un avertisment va fi conectat la kernel logger dacă este cazul.
Sep 06 15:51:18 nucleu de întărire: core_pattern nesigur utilizat cu suid_dumpable=2. Pipe handler sau calea de bază complet calificat dump necesare.
când este necesar setați core_pattern-ul la o cale completă, opțional cu variabile care definesc cine îl rulează, PID-ul etc.
nucleu sysctl-W.core_pattern= / var/accident / miez.% u. % e. % p
în acest exemplu, depozitele noastre vor conține ID-ul de utilizator, numele programului și ID-ul procesului.
Systemd core dumps
când utilizați o distribuție Linux modernă, cel mai probabil veți avea systemd activat. Poate fi necesar să înlocuiți setările prin /etc/sysctl.d / 50-coredump.conf și definiți cum și unde doriți să stocați haldele de bază.
folosind systemd-coredump
kernel-ul.core_pattern poate fi definit pentru a utiliza utilitarul systemd-coredump. Calea implicită în care sunt stocate depozitele de bază este apoi în /var/lib/systemd/coredump.
testarea configurației
majoritatea celorlalte tutoriale vă oferă doar setările care trebuie configurate. Dar de unde știi că lucrurile funcționează așa cum era de așteptat? Va trebui să-l testați!
creați o imagine de bază
opțiunea 1: Creați un program instabil
să creăm un program simplu. Scopul său principal este să se prăbușească atunci când este executat și apoi să creeze opțional un depozit de bază. Instalați gcc pe sistemul dvs. și creați un accident de fișier.c în directorul de acasă.
int main(){ return 1/0;}
acest program va porni funcția principală și va returna o valoare întreagă (număr). Cu toate acestea, se împarte 1 la zero, ceea ce nu este permis și se va prăbuși. Următorul pas este compilarea micului nostru program de buggy.
programul nostru instabil mic
chiar și compilatorul arată programul nostru conține o problemă serioasă și afișează un avertisment cu privire la aceasta. Acum să-l rulăm și să vedem dacă acesta este cazul.
un accident frumos!
din această singură linie, putem învăța de fapt câteva lucruri. În primul rând că a renunțat cu o excepție, referindu-se în mod specific la puncte plutitoare. Acesta este un format de număr zecimal pentru programe, deci poate indica faptul că s-a întâmplat ceva în timp ce faceți niște matematică. O altă concluzie este că miezul este aruncat din cauza adăugării (core dumping) la sfârșit. Dacă depozitele de bază ar fi dezactivate, acest lucru nu ar apărea.
grozav, deci cu acest accident de mai sus avem acum un fișier aruncat, nu? Nu chiar. În funcție de distribuția Linux, lucrurile s-ar putea să nu fie atât de simple pe cât pare. Fiecare distribuție se ocupă diferit de depozitele de bază și de setările implicite. Cele mai recente distribuții Linux folosesc și systemd acum, iar regulile au fost ușor modificate și cu asta. În funcție de configurația dvs., poate fi necesar să căutați depozitele de bază. Deci, iată câteva sfaturi pentru a vă asigura că totul este configurat corect.
Opțiunea 2: ucideți un proces care rulează
în loc să utilizați un program de testare, puteți, de asemenea, să terminați un proces existent. Acest lucru se face prin utilizarea SIGSEGV, care este prescurtarea de la încălcarea segmentare și, de asemenea, cunoscut ca un defect de segmentare.
kill -s SIGSEGV PID
dacă înlocuiți PID-ul cu”$$”, programul curent (cel mai probabil shell-ul dvs.) se va prăbuși. Totul pentru știință, nu?
Opțiunea 3: Utilizarea gdb
dacă aveți instrumentul de depanare pentru dezvoltatori gdb instalat, apoi atașați la un proces de alegere folosind ID-ul său de proces (PID).
gdb -p 1234
apoi, atunci când la promptul gdb, genera groapa de bază prin invocarea instrucțiunea genera-core-file. După utilizarea acestei comenzi, ar trebui să vă returneze ieșirea.
salvat de bază corefile.1234
verificați setările ulimit
setările ulimit definesc ce se poate întâmpla atunci când un program se blochează. Deci, este sigur să verificați mai întâi acest lucru, atât pentru root, cât și pentru un utilizator normal non-privilegiat.
verificați limita hard pentru haldele de bază:
ulimit -H -c
Verificați și limita soft:
ulimit -S -c
verificați modelul de bază
utilizați sistemul de fișiere /proc pentru a aduna valoarea și a o modifica temporar în timpul testării. Dacă preferați să utilizați sysctl, interogați nucleul.core_pattern cheie.
cat /proc/sys/kernel/core_pattern
s-ar putea arăta ceva de genul asta:
|/usr/share/apport/apport %p %s %c %P
în acest caz, un accident va fi direcționat către utilitarul apport. Deci, acest lucru înseamnă că accidentele vor fi analizate de Apport. În mod normal, blocările se găsesc în /var/crash, dar pot fi și în /var/spool sau /var/lib/systemd/coredump pe alte distribuții Linux.
Verificați jurnalul (systemd)
în cazul nostru journalctl arată accidentul nostru, deci acesta este un început.
după verificarea toate aceste setări ar trebui să fie capabil de a crea un depozit de bază frumos.
concluzie
depozitele de bază pot fi utile pentru depanare, dar un dezastru pentru scurgerea datelor sensibile. Dezactivați depozitele de bază atunci când este posibil și activați-le numai atunci când este cu adevărat necesar. În acest caz, verificați dacă fișierele sunt stocate în siguranță, astfel încât utilizatorii normali nu pot vedea datele. Și independent de alegerea pe care ați făcut-o, testați întotdeauna dacă configurația dvs. funcționează exact așa cum vă așteptați să funcționeze.