Dlaczego nie tworzy się zrzut pamięci, gdy aplikacja ma ustawiony identyfikator SUID?

Konfiguruję środowisko tak, aby utworzyć zrzut główny wszystkiego, co ulega awarii, jednak kiedy uruchamiam program z ustawionym SUID na innym użytkowniku niż użytkownik wykonujący, nie tworzy zrzutu podstawowego. Wiesz, dlaczego to może być? Nie mogłem go znaleźć nigdzie w sieci, myślę, że to jakaś funkcja bezpieczeństwa, ale chciałbym, aby był wyłączony ...

Problem:

$ cd /tmp
$ cat /etc/security/limits.conf | grep core
*     -     core     unlimited
root  -     core     unlimited

$ ls -l ohai
-rwsr-sr-x 1 root root 578988 2011-06-23 23:29 ohai

$ ./ohai
...
Floating point exception

$ sudo -i
# ./ohai
...
Floating point exception (core dumped)
# chmod -s ohai
# exit
$ ./ohai
...
Floating point exception (core dumped)

Edycja: Aby uczynić go tak bezpiecznym, jak to możliwe, mam teraz następujący skrypt do konfiguracji środowiska:

mkdir -p /var/coredumps/
chown root:adm /var/coredumps/
chmod 772 /var/coredumps/

echo "kernel.core_pattern = /var/coredumps/core.%u.%e.%p" >> /etc/sysctrl.conf
echo "fs.suid_dumpable = 2" >> /etc/sysctl.conf

echo -e "*\t-\tcore\tunlimited" >> /etc/security/limits.conf
echo -e "root\t-\tcore\tunlimited" >> /etc/security/limits.conf

Teraz pozostaje tylko dodać ACL do / var / coredumps, aby użytkownicy mogli tylko dodawać pliki i nie modyfikować ich ani nie czytać ponownie. Jedynym zmniejszeniem jest to, że nadal miałbym problem z aplikacjami chroot, które wymagałyby bind mountczegoś takiego.

Pamięć programu setuid może (prawdopodobnie nawet będzie zawierać) poufne dane. Zrzut rdzenia musiałby być czytelny tylko dla użytkownika root.

Jeśli zrzut pamięci jest własnością root, nie widzę oczywistej luki w zabezpieczeniach, chociaż jądro musiałoby uważać, aby nie zastąpić istniejącego pliku.

Linux wyłącza zrzuty pamięci dla programów setxid. Aby je włączyć, musisz wykonać co najmniej następujące czynności (nie sprawdziłem, czy to wystarczy):

• Zasadniczo włączaj zrzuty rdzeni setuid, ustawiając fs.suid_dumpablesysctl na 2, np echo 2 >/proc/sys/fs/suid_dumpable. (Uwaga: 2, nie 1; 1 oznacza „debuguję system jako całość i chcę usunąć wszelkie zabezpieczenia”).
• Zadzwoń prctl(PR_SET_DUMPABLE, 1)z programu.

Zrzut rdzenia zawiera kopię wszystkiego, co było w pamięci w momencie uszkodzenia. Jeśli program działa w trybie suid, oznacza to, że potrzebuje dostępu do czegoś, do czego ty, jako użytkownik, nie masz dostępu. Jeśli program pobierze te informacje, a następnie zrzuci rdzeń, będziesz mógł odczytać te uprzywilejowane informacje.

Z powyższego przykładu wygląda na to, że możesz uzyskać zrzut pamięci, gdy działasz jako root lub jeśli usuniesz eskalację uprawnień.

Chociaż może być przydatny (dla programistów tylko metinks) mieć łatwy dostęp do rdzenia z programu setuid, jest to luka w zabezpieczeniach i powinna pozostać na miejscu.

Zdecydowałem, że podzielę się również moim przypadkiem użycia, dopóki go nie zapomnę. Może być przydatny również dla mnie w przyszłości, ponieważ rozwiązałem ten sam problem kilka miesięcy temu i zajęło mi to zbyt dużo czasu, aby dowiedzieć się jeszcze raz. Dobrze. tak naprawdę nie jest to zrzut rdzenia, ale użyteczne jest również śledzenie stosu.

Problem: Nie mam pojęcia, co się tam dzieje:

sudo id
Segmentation fault

Rozwiązanie: przenieś bit suid z sudodo valgrinddziała dobrze:

chmod +s /usr/bin/valgrind
chmod -s /usr/bin/sudo
valgrind /usr/bin/sudo id

Jeśli zainstalowano debuginfo, zapisywany jest ładny ślad.