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
où 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