każdy system potrzebuje uruchomionych procesów, aby spełnić swój główny cel. Ale czasami coś pójdzie nie tak i proces może ulec awarii. W zależności od konfiguracji systemu tworzony jest zrzut rdzenia. Innymi słowy, zapisywana jest migawka pamięci zawieszonego procesu. Termin core odnosi się do starej pamięci magnetycznej ze starszych systemów. Chociaż ten rodzaj pamięci nie jest już używany, nadal Używamy tego terminu na systemach Linux. Wystarczy dla historii, skonfigurujmy nasz system Linux, aby poprawnie obsługiwał zrzuty rdzenia.
spis treści
Linux i zrzuty rdzeni
Większość Systemów Linux ma domyślnie włączone zrzuty rdzeni. Jak zawsze, jest tu kompromis. Z jednej strony chcemy zbierać dane w celu poprawy stabilności i rozwiązywania problemów. Z drugiej strony chcemy ograniczyć dane debugowania i uniknąć wycieku poufnych danych.
pierwsza opcja jest dobra dla maszyn, w których trzeba zbadać niestabilne programy, takie jak Stacja robocza programisty. Druga opcja jest lepiej dostosowana do systemów produkcyjnych przechowujących lub Przetwarzających wrażliwe dane.
Wyłącz zrzuty rdzenia
ma sens, aby domyślnie wyłączyć wszystkie zrzuty rdzenia na Linuksie dla wszystkich systemów. Dzieje się tak dlatego, że pliki zajmują miejsce na dysku i mogą zawierać poufne dane. Jeśli więc nie potrzebujesz zrzutów rdzenia do rozwiązywania problemów, ich wyłączenie jest bezpieczną opcją.
Opcja 1: ulimit poprzez plik konfiguracyjny
aby wyłączyć zrzuty rdzenia musimy ustawić wartość ulimit. Odbywa się to poprzez /etc/security/limits.plik conf i definiuje pewne ograniczenia specyficzne dla powłoki.
dobrze wiedzieć, że istnieją miękkie i twarde ograniczenia. Ograniczenie twarde jest czymś, czego nigdy nie można przesłonić, podczas gdy ograniczenie miękkie może mieć zastosowanie tylko dla określonych użytkowników. Jeśli chcemy mieć pewność, że żaden proces nie może utworzyć zrzutu rdzenia, możemy ustawić oba na zero. Chociaż może wyglądać jak boolean (0 = False, 1 = True), w rzeczywistości wskazuje dozwolony rozmiar.
* miękki rdzeń 0
* twardy rdzeń 0
znak gwiazdki oznacza, że dotyczy wszystkich użytkowników. Druga kolumna określa, czy chcemy użyć ograniczenia twardego lub miękkiego, a następnie kolumny określające ustawienie i wartość.
Opcja 2: Skonfiguruj ulimit za pomocą profilu
wartości dla ulimit można również ustawić za pomocą /etc/profile lub niestandardowego pliku w /etc/profile.katalog D. Ten ostatni jest preferowany, gdy jest dostępny. Na przykład poprzez utworzenie pliku o nazwie /etc/profile.d/disable-coredumps.sh.
echo „ulimit-C 0 > /dev / null 2>&1” > /etc / profil.d / disable-coredumps.SH
to polecenie dodaje ustawienie do nowego pliku i ustawia zarówno miękkie, jak i twarde ograniczenie na zero. Każdy użytkownik otrzymuje tę wartość podczas logowania.
oprócz ustawień ulimit, są też Ustawienia jądra do rozważenia. Więc wybór jednej z opcji jest pierwszym krokiem.
Opcja 3: Wyłącz przez systemd
podczas korzystania z systemd i usługi systemd-coredump Zmień zrzut ekranu.plik conf. Ten plik najprawdopodobniej znajduje się w /usr/lib/sysctl.D / 50-coredump.conf. Ponieważ systemd ma zestaw plików, sprawdź inne, takie jak:
Ustaw ustawienie pamięci na „brak”. Następnie skonfiguruj ProcessSizeMax, aby ograniczyć maksymalny rozmiar do zera.
Storage=none
ProcessSizeMax=0
zazwyczaj wystarczy przeładować konfigurację systemd.
systemctl daemon-reload
jeśli to nadal tworzy zrzut rdzenia, uruchom ponownie system.
Wyłącz procesy setuid zrzucające ich pamięć
procesy z podwyższonymi uprawnieniami (lub bitem setuid) mogą nadal być w stanie wykonać zrzut rdzenia, w zależności od innych ustawień. Ponieważ procesy te mają zwykle większy dostęp, mogą zawierać bardziej wrażliwe segmenty danych w pamięci. Czas to zmienić. Zachowanie może być zmienione za pomocą klucza sysctl lub bezpośrednio przez system plików /proc. W przypadku stałych ustawień zwykle używane jest polecenie i konfiguracja sysctl. Ustawienie nazywa się „kluczem”, do którego dołączona jest powiązana wartość (znana również jako para klucz-wartość).
aby wyłączyć program z bitem setuid do zrzutu, Ustaw fs.suid_dumpable do zera.
echo "fs.suid_dumpable=0" >> /etc/sysctl.conf
Wczytaj ponownie konfigurację sysctl z opcją-p, aby aktywować wprowadzone zmiany.
sysctl -p
po prostu chcesz przetestować bez wprowadzania trwałych zmian? Użyj sysctl -w, po której następuje klucz = wartość.
Wskazówka: używając sysctl możesz dostroić swój system i jest to dobry sposób na utwardzenie jądra Linuksa.
Włącz zrzuty rdzenia
głównym powodem zezwalania na zrzuty rdzenia jest rozwiązywanie problemów. Porzucona pamięć procesu może być używana do debugowania problemów, zwykle przez bardziej doświadczonych programistów. Dostawca oprogramowania może poprosić o włączenie zrzutów rdzenia. Zwykle, aby dowiedzieć się, dlaczego proces zawiesił się w pierwszej kolejności i znaleźć związane z tym procedury, które go spowodowały.
Włączanie zrzutów rdzeni w Linuksie jest podobne do wyłączania ich, z tą różnicą, że należy skonfigurować kilka konkretnych szczegółów. Na przykład, jeśli potrzebujesz tylko szczegółów z określonego programu, możesz użyć miękkich limitów. Odbywa się to za pomocą -S, co oznacza, że jest to miękki limit. -c oznacza wielkość zrzutu rdzenia.
ulimit -S -c 0
następnym krokiem jest umożliwienie tylko’ my-program-to-troubleshoot ’ utworzenia zrzutu rdzenia.
ulimit -S -c unlimited my-program-to-troubleshoot
jeśli chcesz zezwolić wszystkim procesom na używanie zrzutów rdzenia, użyj powyższej linii bez programu lub ustaw limit systemu w /etc/security / limits.conf
* soft core unlimited
Rozwiązywanie problemów z plikami binarnymi setuid
pliki binarne, które mają ustawiony bit setuid, mogą być uruchamiane z uprawnieniami roota. Ten specjalny rodzaj dostępu musi być w jak największym stopniu ograniczony. Również do tworzenia zrzutów rdzenia, musi być poprawnie skonfigurowany. Odbywa się to za pomocą sysctl fs.suid_dumpable key.
- 0 – wyłączona
- 1 – włączona
- 2-włączona z ograniczeniami
więc jeśli chcesz rozwiązywać problemy z programami z ustawionym bitem setuid, możesz tymczasowo zmienić fs.suid_dumpable do 1 lub 2. Ustawienie go na 2 jest preferowane, ponieważ sprawia, że zrzuty rdzenia są czytelne tylko dla użytkownika root. Jest to dobra alternatywa dla Systemów z danymi wrażliwymi. Ustawienie opcji na 1 jest lepiej dostosowane do systemów rozwoju osobistego.
twórz normalne pliki zrzutów
jedną z największych tajemnic Systemów Linux jest to, gdzie znajdują się zrzuty rdzenia. Linux ma sztuczkę, aby przechwytywać zrzuty rdzenia. To ustawienie odbywa się za pośrednictwem jądra sysctl.ustawienie core_pattern lub /proc/sys/kernel/core_pattern. Większość systemów będzie miała rurę (|) w tym ustawieniu, aby wskazać, że program musi zająć się wygenerowanymi danymi. Więc jeśli zastanawiasz się, gdzie jest twój zrzut rdzenia, podążaj za rurą!
zrzuty rdzenia w systemach Ubuntu Zwykle będą się zgadzać. Dla systemów opartych na Red Hat może być przekierowany do automatycznego narzędzia do raportowania błędów (ABRT).
możesz tymczasowo zmienić to ustawienie, powtarzając „rdzeń” do tego pliku lub używając narzędzia sysctl.
sysctl -w kernel.core_pattern=core
ważne jest, że ta zmiana może nie wystarczyć. To zależy również od Twojego fs.ustawienie suid_dumpable. W takim przypadku do twojego rejestratora jądra zostanie zarejestrowane Ostrzeżenie.
Wrz 06 15:51:18 hartowanie jądra: niebezpieczne core_pattern używane z suid_dumpable=2. Wymagana obsługa rur lub w pełni wykwalifikowana ścieżka zrzutu rdzenia.
w razie potrzeby ustaw swój core_pattern na pełną ścieżkę, opcjonalnie ze zmiennymi określającymi, kto go uruchamiał, PID itp.
jądro sysctl-W.core_pattern=/var / crash / core.%u.%e. % p
w tym przykładzie nasze zrzuty będą zawierały id użytkownika, nazwę programu i ID procesu.
zrzuty rdzenia Systemd
podczas korzystania z nowoczesnej dystrybucji Linuksa najprawdopodobniej masz włączoną funkcję systemd. Może być konieczne zastąpienie ustawień przez /etc / sysctl.D / 50-coredump.conf i określ, jak i gdzie chcesz przechowywać zrzuty rdzenia.
używając systemd-coredump
twojego jądra.core_pattern może być zdefiniowany tak, aby używał narzędzia systemd-coredump. Domyślna ścieżka, w której przechowywane są zrzuty pamięci, znajduje się w /var/lib/systemd/coredump.
testowanie konfiguracji
większość innych samouczków podaje tylko ustawienia do skonfigurowania. Ale skąd wiesz, że wszystko działa zgodnie z oczekiwaniami? Musisz go przetestować!
Utwórz zrzut rdzenia
Opcja 1: Utwórz niestabilny program
stwórzmy prosty program. Jego głównym celem jest awaria podczas wykonywania, a następnie opcjonalnie utworzenie zrzutu rdzenia. Zainstaluj gcc w systemie i utwórz awarię pliku.c w katalogu domowym.
int main(){ return 1/0;}
ten program uruchomi główną funkcję i zwróci wartość całkowitą (liczbę). Jednak dzieli 1 przez zero, co jest niedozwolone I ulegnie awarii. Następnym krokiem jest skompilowanie naszego małego programu buggy.
nasz niestabilny mały program
nawet kompilator pokazuje, że nasz program zawiera poważny problem i wyświetla ostrzeżenie o nim. Sprawdźmy, czy tak jest.
niezły wypadek!
z tej jednej linii możemy nauczyć się kilku rzeczy. Przede wszystkim, że rezygnuje z wyjątku, konkretnie odnosząc się do punktów zmiennoprzecinkowych. Jest to format liczby dziesiętnej dla programów, więc może wskazywać, że coś się stało podczas robienia matematyki. Innym wnioskiem jest to, że rdzeń jest wyrzucany z powodu dodania (core dumped) na końcu. Jeśli zrzuty rdzenia zostaną wyłączone, nie będzie to widoczne.
świetnie, więc z tą awarią powyżej mamy teraz wyrzucony plik, prawda? Niezupełnie. W zależności od dystrybucji Linuksa sprawy mogą nie być tak proste, jak się wydaje. Każda dystrybucja działa inaczej z zrzutami rdzenia i ustawieniami domyślnymi. Najnowsze dystrybucje Linuksa również używają systemd teraz i zasady zostały nieco zmienione z tym, jak również. W zależności od konfiguracji może być konieczne wyszukanie zrzutów rdzenia. Oto kilka wskazówek, aby upewnić się, że wszystko jest poprawnie skonfigurowane.
Opcja 2: Zabij działający proces
zamiast używać programu testowego, możesz również zakończyć istniejący proces. Odbywa się to za pomocą SIGSEGV, który jest skrótem od naruszenia segmentacji i znany również jako błąd segmentacji.
kill -s SIGSEGV PID
jeśli zamienisz PID na „$ $ ” bieżący program (najprawdopodobniej twoja powłoka) ulegnie awarii. Wszystko dla nauki, prawda?
Opcja 3: Korzystanie z gdb
jeśli masz zainstalowane narzędzie do debugowania dewelopera gdb, dołącz do wybranego procesu za pomocą jego identyfikatora procesu (PID).
gdb -p 1234
następnie, gdy pojawi się monit gdb, Wygeneruj zrzut rdzenia, wywołując instrukcję generate-core-file. Po użyciu tego polecenia, powinno zwrócić Dane wyjściowe.
zapisany rdzeń corefile.1234
Sprawdź ustawienia ulimit
ustawienia ulimit określają, co może się zdarzyć, gdy program ulegnie awarii. Więc jest to bezpieczne, aby najpierw sprawdzić, zarówno dla Roota, jak i normalnego nieuprzywilejowanego użytkownika.
Sprawdź twardy limit dla zrzutów rdzenia:
ulimit -H -c
Sprawdź również miękki limit:
ulimit -S -c
Sprawdź wzór rdzenia
Użyj systemu plików / proc, aby zebrać wartość i zmienić ją tymczasowo podczas testowania. Jeśli wolisz używać sysctl, odpytaj jądro.klucz core_pattern.
cat /proc/sys/kernel/core_pattern
to może pokazać coś takiego:
|/usr/share/apport/apport %p %s %c %P
w takim przypadku awaria zostanie przekierowana do narzędzia apport. Oznacza to, że awarie będą analizowane przez aport. Zwykle awarie znajdują się w /var/crash, ale mogą być również w /var/spool lub /var/lib/systemd/coredump w innych dystrybucjach Linuksa.
Sprawdź dziennik (systemd)
w naszym przypadku journalctl pokazuje naszą awarię, więc to początek.
po sprawdzeniu wszystkich tych ustawień powinieneś być w stanie stworzyć ładny zrzut rdzenia.
wniosek
zrzuty rdzenia mogą być przydatne do rozwiązywania problemów, ale katastrofa dla wycieku poufnych danych. Wyłącz zrzuty rdzenia, jeśli to możliwe, i włącz je tylko wtedy, gdy jest to naprawdę potrzebne. W takim przypadku sprawdź, czy pliki są bezpiecznie przechowywane, aby normalni użytkownicy nie mogli zobaczyć danych. Niezależnie od tego, jakiego wyboru dokonałeś, zawsze testuj, czy Twoja konfiguracja działa dokładnie tak, jak tego oczekujesz.