Attention ! ceci est un exercice de malice
je suis pas sûr de ne pas avoir tapé dans le terminal une commande qui va bien
Hé ! hé ! c'est forcément toi si tu es le seul
admin du Mac (à moins que quelqu'un n'ait opéré à ton insu dans ta session).
Pour substituer le
setuid_bit à l'
executable_bit sur le binaire
sudo [ou sur tout autre exécutable dont l'
user est
root] > une commande possible est :
Bloc de code:
sudo chmod u+s /usr/bin/sudo
- où sudo est appelé pour autoriser l'utilitaire chmod à neutraliser récursivement le protocole d'authentification sur le binaire sudo (ce que je trouve marrant)
Évidemment > un utilisateur malicieux commence toujours par établir un
setuid_bit sur le binaire
chmod par une commande du type :
ce qui fait que l'utilitaire
chmod appelé dans un
Terminal par l'utilisateur
machin est automatiquement exécuté avec l'identité de
root. Par suite > pour inscrire le
setuid_bit sur le binaire
sudo > il suffit de passer la commande simple :
(et ainsi de suite pour tous les autres binaires envisagés) - puisque
chmod étant exécuté automatiquement avec l'identité de
root grâce au
setuid_bit > il n'y a pas besoin de passer par une authentification
sudo pour modifier les permissions de...
sudo.
Évidemment (pour rester dans le sujet de ce fil) > il aurait suffi à l'avance d'inscrire un
setuid_bit sur le binaire
spctl par une commande de type :
Bloc de code:
chmod u+s /usr/sbin/spctl
(en supposant que
chmod porte le
setuid_bit pour opérer en
root sans
sudo) > et la commande de désactivation du sous-système policier de surveillance du Système aurait été simplement :
(sans avoir besoin de requête à
sudo).
Manifestement > la mode du temps actuel n'est guère à cette liberté de "désinvolture consciente" à l'égard des contraintes d'un Système (on ne parle plus partout que de "garanties" et de "protection" - le moindre gamin sur un vélo, par exemple, se trouve affublé d'un casque de vététiste en cloche à fromage et
tutti quanti). Donc évidemment la politique de la va dans le même sens d'un vissage logiciel : du
kext_signing de l'OS «
Yosemite» > au
SIP de l'OS «
El Capitan» ou «
Sierra» > au
SIP renforcé de l'OS «
High Sierra».
Un des effets du
SIP étant de verrouiller au chargement des répertoires du Système, les répertoires de binaires (comme
/usr/bin ou
/bin) tombent sous le
SIP. Donc un utilisateur (comme toi) qui veut inscrire un
setuid_bit sur
sudo > doit commencer par aller désactiver le
SIP dans le «
Terminal» de la
Recovery afin de déverrouiller le dossier
/usr/bin et pouvoir modifier les permissions sur
sudo.
J'en déduis qu'il t'a fallu être motivé à l'époque (si tu es dans un OS "avec
SIP") pour modifier les permissions de
sudo mais que par la suite... tu as oublié ta propre rouerie.
Je reconnais que tel est l'inconvénient de modifier (même légèrement) des fonctionnalités du Système de
macOS : il faut constamment garder présent à l'esprit - jusque dans le moindre détail - tout ce qu'on a modifié > ce, afin de ne pas se trouver débordé par les conséquences de ce qu'on a implémenté. Modifier
sudo en y attachant le
setuid_bit implique de toujours garder présent à l'esprit que
sudo va désormais toujours s'exécuter sans authentification - pof ! aussi directement qu'une commande
ls de listage.
Si tu voulais résilier le
setuid_bit sur
sudo > la commande serait chez toi :
Bloc de code:
sudo chmod u-s /usr/bin/sudo
(commande
sudo sans authentification grâce au
setuid_bit sur
sudo > pour retirer le
setuid_bit de
sudo et restaurer la demande d'authentification). À condition évidemment que le
SIP ne verrouille pas les répertoires du Système au chargement car si c'est le cas > il te faut faire un détour par le «
Terminal»
Recovery pour y désactiver le
SIP au préalable...