Comment se fait-il qu'aucun vidage de mémoire ne soit créé lorsqu'une application a défini SUID?

J'ai configuré mon environnement pour créer un vidage de mémoire de tout ce qui se bloque, mais lorsque j'exécute un programme avec SUID défini sur un utilisateur différent de l'utilisateur exécutant, il ne crée pas de vidage de mémoire. Une idée de pourquoi cela pourrait être? Je ne l'ai trouvé nulle part sur le Web, je pense que c'est une sorte de fonctionnalité de sécurité, mais j'aimerais la désactiver ...

Problème:

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

Edit: Pour le faire fonctionner aussi sécurisé que possible, j'ai maintenant le script suivant pour configurer l'environnement:

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

Maintenant, tout ce qui reste à faire est d'ajouter ACL à / var / coredumps pour que les utilisateurs puissent seulement ajouter des fichiers et ne plus les modifier ni les lire. La seule réduction, c'est que j'aurais toujours un problème avec les applications chrootées qui auraient besoin d'un bind mountou quelque chose comme ça.

La mémoire d'un programme setuid peut (est susceptible, même) contenir des données confidentielles. Le core dump devrait donc être lisible par root uniquement.

Si le vidage de mémoire appartient à root, je ne vois pas de faille de sécurité évidente, bien que le noyau doive faire attention à ne pas écraser un fichier existant.

Linux désactive les vidages mémoire pour les programmes setxid. Pour les activer, vous devez au moins effectuer les opérations suivantes (je n'ai pas vérifié que cela est suffisant):

• Activez les fs.suid_dumpablevidages de mémoire setuid en général en définissant sysctl sur 2, par exemple avec echo 2 >/proc/sys/fs/suid_dumpable. (Remarque: 2, pas 1; 1 signifie «Je débogue le système dans son ensemble et je veux supprimer toute sécurité».)
• Appelez prctl(PR_SET_DUMPABLE, 1)depuis le programme.

Le vidage de mémoire contient une copie de tout ce qui était en mémoire au moment de la panne. Si le programme fonctionne suid, cela signifie qu'il a besoin d'accéder à quelque chose auquel vous, en tant qu'utilisateur, n'avez pas accès. Si le programme obtient ces informations puis décharge le noyau, vous pourrez lire ces informations privilégiées.

D'après votre exemple ci-dessus, il semble que vous puissiez obtenir un vidage de mémoire lors de l'exécution en tant que root ou si vous supprimez l'escalade de privilèges.

Bien qu'il puisse être pratique (pour les développeurs uniquement de penser) d'avoir un accès facile à un coredump à partir d'un programme setuid, c'est un trou de sécurité, et devrait être laissé en place.

J'ai décidé de partager mon cas d'utilisation jusqu'à ce que je l'oublie. Cela pourrait également être utile pour moi, car je résolvais le même problème il y a des mois et cela m'a pris trop de temps pour le découvrir une fois de plus. D'accord. ce n'est pas réellement un vidage de mémoire, mais une trace de pile qui est également utile.

Problème: aucune idée de ce qui se passe là-bas:

sudo id
Segmentation fault

Solution: Déplacer le bit suid de sudod' valgrindœuvres bien:

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

Si debuginfo est installé, une belle trace est écrite.