Jedes System benötigt laufende Prozesse, um sein primäres Ziel zu erreichen. Aber manchmal gehen Dinge schief und ein Prozess kann abstürzen. Abhängig von der Konfiguration des Systems wird ein Core-Dump erstellt. Mit anderen Worten, ein Speicher-Snapshot des abgestürzten Prozesses wird gespeichert. Der Begriff Kern bezieht sich eigentlich auf den alten Magnetkernspeicher älterer Systeme. Obwohl diese Art von Speicher nicht mehr verwendet wird, verwenden wir diesen Begriff immer noch auf Linux-Systemen. Genug für die Geschichte, lassen Sie uns unser Linux-System so konfigurieren, dass es Core-Dumps richtig verarbeitet.
Inhaltsverzeichnis
Linux und Core Dumps
Auf den meisten Linux-Systemen sind Core Dumps standardmäßig aktiviert. Wie immer gibt es hier einen Kompromiss. Einerseits wollen wir Daten für eine verbesserte Stabilität und Fehlerbehebung sammeln. Auf der anderen Seite möchten wir die Debug-Daten einschränken und vermeiden, dass vertrauliche Daten verloren gehen.
Die erste Option eignet sich für Maschinen, auf denen instabile Programme untersucht werden müssen, z. B. die Workstation eines Entwicklers. Die zweite Option eignet sich besser für Produktionssysteme, die sensible Daten speichern oder verarbeiten.
Core-Dumps deaktivieren
Es ist sinnvoll, Core-Dumps unter Linux standardmäßig für alle Ihre Systeme zu deaktivieren. Dies liegt daran, dass die Dateien Speicherplatz beanspruchen und vertrauliche Daten enthalten können. Wenn Sie die Core-Dumps also nicht zur Fehlerbehebung benötigen, ist das Deaktivieren eine sichere Option.
Option 1: ulimit über die Konfigurationsdatei
Um Core-Dumps zu deaktivieren, müssen wir einen ulimit -Wert festlegen. Dies geschieht über die Datei /etc/security/limits.conf-Datei und definiert einige Shell-spezifische Einschränkungen.
Gut zu wissen ist, dass es weiche und harte Grenzen gibt. Ein hartes Limit kann niemals überschrieben werden, während ein weiches Limit möglicherweise nur für bestimmte Benutzer gilt. Wenn wir sicherstellen möchten, dass kein Prozess einen Core-Dump erstellen kann, können wir beide auf Null setzen. Obwohl es wie ein boolescher Wert aussieht (0 = False, 1 = True), gibt es tatsächlich die zulässige Größe an.
* weicher Kern 0
* harter Kern 0
Das Sternchen bedeutet, dass es für alle Benutzer gilt. In der zweiten Spalte wird angegeben, ob ein hartes oder weiches Limit verwendet werden soll, gefolgt von den Spalten mit der Einstellung und dem Wert.
Option 2: ulimit über Profil konfigurieren
Die Werte für ulimit können auch über /etc/profile oder eine benutzerdefinierte Datei in /etc/profile eingestellt werden.d Verzeichnis. Letzteres wird bevorzugt, wenn es verfügbar ist. Zum Beispiel durch Erstellen einer Datei namens /etc/profile.d/disable-coredumps.sh.
echo „ulimit -c 0 > /dev/null 2>&1“ > / etc/Profil.d/deaktivieren-coredumps.sh
Dieser Befehl fügt die Einstellung einer neuen Datei hinzu und setzt sowohl das Soft- als auch das Hard-Limit auf Null. Jeder Benutzer erhält diesen Wert beim Anmelden.
Neben den Ulimit-Einstellungen sind auch die Kernel-Einstellungen zu berücksichtigen. Die Auswahl einer der Optionen ist also der erste Schritt.
Option 3: Deaktivieren über systemd
Wenn Sie systemd und den systemd-coredump-Dienst verwenden, ändern Sie den Coredump.conf-Datei. Diese Datei befindet sich höchstwahrscheinlich unter /usr/lib/sysctl.d/50-Kernpumpe.conf. Da systemd eine Reihe von Dateien hat, überprüfen Sie die anderen wie:
Stellen Sie die Speichereinstellung auf ‚keine‘. Konfigurieren Sie dann ProcessSizeMax, um die maximale Größe auf Null zu begrenzen.
Speicher=keine
ProcessSizeMax=0
In der Regel reicht es aus, nur die Systemd-Konfiguration neu zu laden.
systemctl daemon-reload
Wenn dadurch immer noch ein Core-Dump erstellt wird, starten Sie das System neu.
Setuid-Prozesse deaktivieren, die ihren Speicher freigeben
Prozesse mit erhöhten Berechtigungen (oder dem setuid-Bit) können möglicherweise noch einen Core-Dump ausführen, abhängig von Ihren anderen Einstellungen. Da diese Prozesse normalerweise mehr Zugriff haben, enthalten sie möglicherweise empfindlichere Datensegmente im Speicher. Also Zeit, dies auch zu ändern. Das Verhalten kann mit einem sysctl-Schlüssel oder direkt über das Dateisystem /proc geändert werden. Für permanente Einstellungen wird normalerweise der Befehl sysctl und die Konfiguration verwendet. Eine Einstellung wird als ‚Schlüssel‘ bezeichnet, an die ein verwandter Wert angehängt ist (auch als Schlüssel-Wert-Paar bezeichnet).
Um das Programm mit dem setuid-Bit zu dump zu deaktivieren, setzen Sie den fs.suid_dumpable auf Null.
echo "fs.suid_dumpable=0" >> /etc/sysctl.conf
Laden Sie die sysctl-Konfiguration mit dem Flag -p neu, um alle vorgenommenen Änderungen zu aktivieren.
sysctl -p
Möchten Sie einfach testen, ohne dauerhafte Änderungen vorzunehmen? Verwenden Sie sysctl -w gefolgt von key=value.
Tipp: Mit sysctl können Sie Ihr System optimieren und den Linux-Kernel härten.
Core-Dumps aktivieren
Der Hauptgrund, Core-Dumps zuzulassen, ist die Fehlerbehebung. Der gespeicherte Speicher des Prozesses kann zum Debuggen von Problemen verwendet werden, normalerweise von erfahreneren Entwicklern. Ein Softwareanbieter kann Sie auffordern, Core-Dumps zu aktivieren. Normalerweise, um herauszufinden, warum ein Prozess überhaupt abgestürzt ist, und um die zugehörige Routine zu finden, die ihn verursacht hat.
Das Aktivieren von Core-Dumps unter Linux ähnelt dem Deaktivieren, mit der Ausnahme, dass einige spezifische Details konfiguriert werden sollten. Wenn Sie beispielsweise nur Details aus einem bestimmten Programm benötigen, können Sie weiche Grenzwerte verwenden. Dies geschieht mit -S, was darauf hinweist, dass es sich um ein weiches Limit handelt. Der -c gibt die Größe eines Core-Dumps an.
ulimit -S -c 0
Der nächste Schritt besteht darin, nur ‚my-program-to-troubleshoot‘ zuzulassen, um einen Core-Dump zu erstellen.
ulimit -S -c unlimited my-program-to-troubleshoot
Wenn Sie zulassen möchten, dass alle Prozesse Core-Dumps verwenden, verwenden Sie die obige Zeile ohne das Programm oder legen Sie ein Systemlimit in / etc /security /limits fest.conf
* soft core unlimited
Fehlerbehebung bei Setuid-Binärdateien
Binärdateien, für die ein Setuid-Bit festgelegt ist, können mit Root-Berechtigungen ausgeführt werden. Diese besondere Art des Zugriffs muss so weit wie möglich eingeschränkt werden. Auch für die Erstellung von Core-Dumps muss es ordnungsgemäß konfiguriert werden. Dies geschieht mit dem sysctl fs.suid_dumpable Schlüssel.
- 0 – deaktiviert
- 1 – aktiviert
- 2 – mit Einschränkungen aktiviert
Wenn Sie also Probleme mit Programmen mit einem setuid-Bitsatz beheben möchten, können Sie die fs vorübergehend ändern.suid_dumpable auf 1 oder 2. Die Einstellung auf 2 wird bevorzugt, da dadurch die Core-Dumps nur für den Root-Benutzer lesbar sind. Dies ist eine gute Alternative für Systeme mit sensiblen Daten. Die Einstellung der Option auf 1 ist besser für persönliche Entwicklungssysteme geeignet.
Normale Dump-Dateien erstellen
Eines der großen Rätsel bei Linux-Systemen ist, wo sich die Core-Dumps befinden. Linux hat einen Trick, um Core-Dumps zu erfassen. Diese spezielle Einstellung erfolgt über den sysctl-Kernel.core_pattern-Einstellung oder /proc/sys/kernel/core_pattern. Die meisten Systeme haben eine Pipe (|) in dieser Einstellung, um anzuzeigen, dass sich ein Programm um die generierten Daten kümmern muss. Also, wenn Sie sich fragen, wo Ihr Kern Dump geht, folgen Sie dem Rohr!
Core-Dumps auf Ubuntu-Systemen werden normalerweise angezeigt. Für Red Hat-basierte Systeme kann es zum Automatic Bug Reporting Tool (ABRT) umgeleitet werden.
Sie können diese Einstellung vorübergehend ändern, indem Sie „core“ in diese Datei wiederholen oder das Dienstprogramm sysctl verwenden.
sysctl -w kernel.core_pattern=core
Ein wichtiger Hinweis ist, dass diese Änderung möglicherweise nicht ausreicht. Es hängt auch von Ihrem fs ab.suid_dumpable Einstellung. In diesem Fall wird eine Warnung in Ihrem Kernel-Logger protokolliert.
Sep 06 15:51:18 hardening kernel: Unsicheres core_pattern verwendet mit suid_dumpable=2. Pipe-Handler oder voll qualifizierter Core-Dump-Pfad erforderlich.
Setzen Sie bei Bedarf Ihr core_pattern auf einen vollständigen Pfad, optional mit Variablen, die definieren, wer es ausgeführt hat, die PID usw.
sysctl -w-Kernel.core_pattern = / var / Absturz / Kern.%u.%e.%p
In diesem Beispiel enthalten unsere Dumps die Benutzer-ID, den Programmnamen und die Prozess-ID.
Systemd Core Dumps
Wenn Sie eine moderne Linux-Distribution verwenden, haben Sie höchstwahrscheinlich systemd aktiviert. Möglicherweise müssen Sie die Einstellungen über /etc/sysctl überschreiben.d/50-Kernpumpe.conf und definieren Sie, wie und wo Sie Ihre Core-Dumps speichern möchten.
Mit systemd-coredump
Ihr Kernel.core_pattern kann definiert werden, um das Dienstprogramm systemd-coredump zu verwenden. Der Standardpfad, in dem Core-Dumps gespeichert werden, befindet sich dann in /var/lib/systemd/coredump.
Testen Ihrer Konfiguration
Die meisten anderen Tutorials geben Ihnen nur die zu konfigurierenden Einstellungen. Aber wie würden Sie wissen, dass die Dinge wie erwartet funktionieren? Sie müssen es testen!
Erstellen Sie einen Core-Dump
Option 1: Erstellen Sie ein instabiles Programm
Erstellen wir ein einfaches Programm. Sein primäres Ziel ist es, bei der Ausführung abzustürzen und dann optional einen Core-Dump zu erstellen. Installieren Sie gcc auf Ihrem System und erstellen Sie einen Dateiabsturz.c in Ihrem Home-Verzeichnis.
int main(){ return 1/0;}
Dieses Programm startet die Hauptfunktion und gibt einen ganzzahligen Wert (Zahl) zurück. Es teilt jedoch 1 durch Null, was nicht erlaubt ist und abstürzt. Der nächste Schritt ist das Kompilieren unseres kleinen Buggy-Programms.
Unser instabiles kleines Programm
Selbst der Compiler zeigt an, dass unser Programm ein ernstes Problem enthält, und zeigt eine Warnung darüber an. Lassen Sie es uns nun ausführen und sehen, ob dies der Fall ist.
Ein schöner Crash!
Aus dieser einzigen Zeile können wir tatsächlich ein paar Dinge lernen. Zunächst wird es mit einer Ausnahme beendet, die sich speziell auf Gleitkommazahlen bezieht. Dies ist ein dezimales Zahlenformat für Programme, daher kann dies darauf hinweisen, dass während der Mathematik etwas passiert ist. Eine andere Schlussfolgerung ist, dass der Kern aufgrund der (Core Dumped) Zugabe am Ende abgeladen wird. Wenn Core Dumps deaktiviert wären, würde dies nicht angezeigt.
Großartig, mit diesem Absturz oben haben wir jetzt eine Dumped-Datei, oder? Nicht ganz. Abhängig von Ihrer Linux-Distribution sind die Dinge möglicherweise nicht so einfach, wie es aussieht. Jede Distribution behandelt Core-Dumps und die Standardeinstellungen unterschiedlich. Die neuesten Linux-Distributionen verwenden jetzt auch systemd und die Regeln wurden ebenfalls leicht geändert. Abhängig von Ihrer Konfiguration müssen Sie möglicherweise nach Ihren Core-Dumps suchen. Hier sind einige Tipps, um sicherzustellen, dass alles korrekt konfiguriert ist.
Option 2: Beenden eines laufenden Prozesses
Anstatt ein Testprogramm zu verwenden, können Sie auch einen vorhandenen Prozess beenden. Dies geschieht durch Verwendung des SIGSEGV, das für Segmentation Violation und auch als Segmentation Fault bezeichnet wird.
kill -s SIGSEGV PID
Wenn Sie PID durch „$$“ ersetzen, stürzt das aktuelle Programm (höchstwahrscheinlich Ihre Shell) ab. Alles für die Wissenschaft, oder?
Option 3: Verwenden von gdb
Wenn Sie das Entwickler-Debugging-Tool gdb installiert haben, hängen Sie es mithilfe seiner Prozess-ID (PID) an einen Prozess Ihrer Wahl an.
gdb -p 1234
Generieren Sie dann an der gdb-Eingabeaufforderung den Core-Dump, indem Sie die Anweisung generate-core-file aufrufen. Nachdem Sie diesen Befehl verwendet haben, sollte er Ihre Ausgabe zurückgeben.
Corefile-Kern gespeichert.1234
Check ulimit settings
Die ulimit-Einstellungen definieren, was passieren kann, wenn ein Programm abstürzt. Daher ist es sicher, dies zuerst für root und einen normalen nicht privilegierten Benutzer zu überprüfen.
Hartes Limit für Core-Dumps prüfen:
ulimit -H -c
Überprüfen Sie auch das Soft Limit:
ulimit -S -c
Überprüfen Sie das Kernmuster
Verwenden Sie das Dateisystem /proc, um den Wert zu erfassen und während des Tests vorübergehend zu ändern. Wenn Sie sysctl bevorzugen, fragen Sie den Kernel ab.core_pattern Schlüssel.
cat /proc/sys/kernel/core_pattern
Es könnte so etwas zeigen:
|/usr/share/apport/apport %p %s %c %P
In diesem Fall wird ein Absturz an das Dienstprogramm apport weitergeleitet. Dies bedeutet also, dass Abstürze von Apport analysiert werden. Normalerweise werden Abstürze in / var/crash gefunden, können aber auch in / var/spool oder / var/lib/systemd/coredump auf anderen Linux-Distributionen sein.
Überprüfen Sie das Journal (systemd)
In unserem Fall zeigt journalctl unseren Absturz, das ist also ein Anfang.
Nachdem Sie alle diese Einstellungen überprüft haben, sollten Sie in der Lage sein, einen schönen Core-Dump zu erstellen.
Fazit
Core-Dumps können zur Fehlerbehebung nützlich sein, sind jedoch eine Katastrophe, wenn vertrauliche Daten verloren gehen. Deaktivieren Sie Core-Dumps, wenn möglich, und aktivieren Sie sie nur, wenn sie wirklich benötigt werden. Überprüfen Sie in diesem Fall, ob die Dateien sicher gespeichert sind, sodass normale Benutzer die Daten nicht sehen können. Und unabhängig davon, welche Wahl Sie getroffen haben, testen Sie immer, ob Ihre Konfiguration genau so funktioniert, wie Sie es erwarten.