Pourquoi chroot (2) n'est pas disponible pour les users non privilégiés?

Pourquoi chroot(2) n'est pas disponible pour les users non privilégiés?

Je ne comprends pas les réponses existantes sur Internet. Par exemple celui-ci https://lists.freebsd.org/pipermail/freebsd-security/2003-April/000123.html .

Est-ce que sudo fonctionnerait vraiment si /etc/sudoers et /etc n'appartenaient pas à root? Un user non privilégié ne peut pas simplement créer des binarys setuid root à l'intérieur de chroot, peut-elle?

Exactement comment un user non privilégié peut-il subvertir l'environnement chroot?

Je ne peux penser qu'à quelque chose comme ça

 ln /mnt/backup/XYZ/etc/sudoers $CHROOT/etc/sudoers ln /usr/bin/sudo $CHROOT/usr/bin/sudo 

XYZ dénote une instance de sauvegarde où admin a vraiment foiré et a permis à mon user quelque chose de dangereux. Mais c'est un peu spécial. Existe-t-il un moyen plus simple d'exploiter chroot(2) s'il était disponible pour les users non privilégiés?

Un user ordinaire ne peut pas créer un binary setuid, mais rien ne l'empêche de créer un lien dur vers un binary setuid existant. Donc, s'il a la permission d'écrire dans un directory sur le même système de files que /usr/bin , il peut placer la prison dans ce directory, créer un lien dur vers su ou sudo et mettre un /etc/passwd et /etc/sudoers dans la prison.

Peut-être que cela ne marchera pas pour sudo , car il pourrait vérifier que /etc/sudoers appartient à root. Mais je parie que su ne vérifie pas la propriété de /etc/passwd .

Selon Brad Spengler sur https://forums.grsecurity.net/viewtopic.php?f=7&t=2522 , il existe un moyen sortingvial d'escalader vers uid 0 en utilisant CAP_SYS_CHROOT (la possibilité d'utiliser chroot(2) :

CAP_SYS_CHROOT: generic: De Julien Tinnes / Chris Evans: si vous avez un access en écriture au même système de files qu'un suid root binary, configurez un environnement chroot avec une libc backdoored et exécutez un binary racine de suid dans votre chroot privilèges grâce à votre porte dérobée