Почему не создается дамп ядра, если в приложении установлен SUID?

Я настроил свою среду на создание дампов ядра для всего, что дает сбой, однако, когда я запускаю программу с установленным SUID для другого пользователя, а не для исполняющего пользователя, он не создает дамп ядра. Есть идеи, почему это может быть? Я не смог найти его в Интернете, я думаю, что это какая-то функция безопасности, но я бы хотел отключить его ...

Проблема:

$ 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)

Редактировать: чтобы сделать его максимально безопасным, теперь у меня есть следующий скрипт для настройки среды:

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

Теперь все, что осталось сделать, это добавить ACL в / var / coredumps, чтобы пользователи могли только добавлять файлы, не изменять и не читать их никогда. Единственное сокращение состоит в том, что у меня все еще была бы проблема с приложениями chroot, которые нуждались бы в bind mountили что-то в этом роде.

Память программы setuid может (вероятно, даже) содержать конфиденциальные данные. Таким образом, дамп ядра должен быть доступен для чтения только пользователю root.

Если дамп ядра принадлежит root, я не вижу очевидной дыры в безопасности, хотя ядро ​​должно быть осторожно, чтобы не перезаписать существующий файл.

Linux отключает дампы ядра для программ setxid. Чтобы включить их, вам нужно сделать по крайней мере следующее (я не проверял, что этого достаточно):

• Включите дамп ядра setuid в целом, установив для fs.suid_dumpablesysctl значение 2, например, с помощью echo 2 >/proc/sys/fs/suid_dumpable. (Примечание: 2, а не 1; 1 означает «Я отлаживаю систему в целом и хочу удалить всю безопасность».)
• Звонок prctl(PR_SET_DUMPABLE, 1)из программы.

Дамп памяти содержит копию всего, что было в памяти во время ошибки. Если программа работает с suid, это означает, что ей нужен доступ к чему-то, к чему у вас как пользователя нет доступа. Если программа получит эту информацию, а затем сбросит ядро, вы сможете прочитать эту привилегированную информацию.

Из приведенного выше примера видно, что вы можете получить дамп ядра при запуске от имени пользователя root или при удалении повышения привилегий.

Хотя может быть удобным (только для разработчиков), чтобы иметь легкий доступ к coredump из программы setuid, это дыра в безопасности, и ее следует оставить на месте.

Я решил, что я также поделюсь своим случаем использования, пока я не забуду это. Это может быть полезно и для будущего меня, так как я решал ту же проблему несколько месяцев назад, и мне потребовалось слишком много времени, чтобы узнать еще раз. Ok. на самом деле это не core-dump, а трассировка стека, что также полезно.

Проблема: не знаю, что там происходит:

sudo id
Segmentation fault

Решение: переместить бит suid из sudoвvalgrind отлично работает:

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

Если debuginfo установлен, хорошая обратная трассировка записывается.