Où macomaniac donne l'impression de parler Chinois bien qu'il s'agisse du Nouvel An occidental
Salut
bavava
ATTENTION : le fichier SUID « System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent » a été modifié et ne sera pas réparé.
c grave ????
Mais qu'avisé-je en ce matin de 1er Janvier ? - une question portant sur point de détail qui m'a toujours délecté au plus haut point : le
SUID_bit (ah ! ah ! ah !).
Il s'agit d'une modification délibérée du comportement exécutif standard de fichiers binaires UNIX (genre
chown,
chmod etc.) appelables dans des commandes du «
Terminal»).
Ces fichiers ont régulièrement comme droits :
Bloc de code:
-rwxr-x-r-x root wheel everyone
ce qui revient à dire que l'
executable bit x est institué pour tout accédant possible à ce fichier (
root ou un membre du groupe principal
wheel <ce qui revient à
root> ou un membre du groupe secondaire
eveyone <ce qui revient aux détenteurs d'un compte
admin ou
standard ici>) > tandis que le propriétaire fixe du fichier est
root, le
System Administrator.
Que se passe-t-il si un
admin quelconque (
macomaniac par exemple) appelle un tel exécutable (disons
chown) de manière brute dans une commande du «
Terminal» ? > le processus exécutif du fichier va s'effectuer comme approprié à l'identité (
UID :
User_IDentity) de l'agent opérateur :
macomaniac, ayant accédé au fichier en tant que membre du groupe «
everyone » > le pouvoir d'exécution du fichier sera donc cantonné aux permissions de l'agent opérateur
macomaniac.
Si le nommé
macomaniac veut exécuter le fichier
chown sur des objets protégés en écriture du Système > il va se faire jeter. À moins qu'il ne préface sa commande de
sudo (
substitute_user_do : opérer en tant qu'utilisateur subtitué =
root par défaut) > auquel cas le processus exécutif du fichier ne sera pas approprié à l'identité de l'
initiateur de la commande (
macomaniac) > mais à celle de l'
utilisateur substitué :
root > ce qui permet d'opérer sur des fichiers protégés en écriture du Système. L'ennui > c'est que
macomaniac va devoir
s'authentifier par un mot-de-passe pour cette commande
sudo [un véritable « ennui », oui : car ledit
macomaniac a un mot-de-passe de 32 caractères alpha-numériques - ce qui devient fatiguant à taper à la longue...].
Que peut faire le diabolique
macomaniac pour s'éviter l'« aria » d'avoir à s'authentifier par mot-de-passe dans des commandes
sudo ? > il peut
convertir le comportement de l'exécutable chown > en fixant sur le fichier un
SUID_bit.
Un
SUID_bit signifie en mode développé : «
set-user-ID-on-execution bit » = établissement de l'identité du propriétaire du fichier sur l'executable bit. Les droits du fichier binaire deviennent alors :
Bloc de code:
-rwsr-x-r-x root wheel everyone
> où l'on voit que l'
executable bit x du propriétaire
root du fichier a été converti à un
bit s (
set_user_id_on_exe- cution_bit).
Cette conversion signifie la chose suivante : lorsque
macomaniac appellera directement le binaire dans une commande du «
Terminal» > le processus exécutif du fichier ne sera pas approprié à son identité d'utilisateur initiataire > mais sera approprié à l'
identité de l'utilisateur en titre du fichier :
root. Bref : le diabolique
macomaniac grâce au
setuid_bit va pouvoir utiliser directement l'identité
root en exécution du fichier sans jamais avoir besoin besoin de s'authentifier par un
sudo.
root va être, automatiquement, son agent exécutif.
C'est un analogue de la dialectique du « Maître du Maître » dans la «Phénoménologie de l'Esprit» de Hegel (la métaphysique, chez les Américains, me donnant toujours l'impression de s'être réfugiée dans la casuistique informatique).
[Il suffit que
macomaniac commence par instaurer réflexivement un
SUID_bit sur le binaire
chmod par le binaire
chmod (qui est le moyen du
SUID_bit) > pour pouvoir continuer à essaimer des
SUID_bits via
chmod désormais exécutable directement en tant qu'approprié à l'identité
root. Les permissions standard d'un exécutable étant
755 root wheel everyone en valeur octale > la commande initiale à passer est donc :
Bloc de code:
sudo chmod 4755 /bin/chmod
> ce qui permet ensuite tous les :
Bloc de code:
chmod 4755 [PATH][EXECUTABLE]
qu'on voudra.]
Évidemment, le diabolique
macomaniac peut par ailleurs s'introniser membre du groupe
wheel (le groupe-Système, à parité avec
root, régulièrement son seul membre) > la conséquence en étant la capacité de passer des commandes
sudo sans jamais avoir besoin de s'authentifier par mot-de-passe. Ce qui implique quand même d'avoir à taper : «
sudo » en préface de l'utilitaire appelé dans la commande. L'instauration d'un
SUID_bit sur tel ou tel binaire exécutable > soustrait la nécessité de
sudo > en rendant possible l'emploi direct du binaire dont le processus exécutif sera
approprié automatiquement à l'identité de son propriétaire en titre (
root) et pas à celle de l'initiateur de ce processus (
macomaniac).
Ce que j'ai décrit ci-dessus > correspond à des modifications perfides que
macomaniac a apporté à l'
executable bit de fichiers binaires. Mais il arrive, tout a fait couramment, que certains fichiers exécutables soient affectés d'un
SUID_bit par le Système lui-même > afin de donner une certaine latitude exécutive aux utilisateurs standards, qui, sans avoir besoin de s'authentifier, pourront initier des processus exécutifs appropriés automatiquement à l'identité de
root. Il en va ainsi du notoire utilitaire
ARDAgent > sur lequel a toujours été fixé un
SUID_bit par le Système depuis les origines d'
OS X.
Lorsqu'une
vérification /
réparation des permissions était encore à l'ordre du jour (jusqu'à l'OS «
Yosemite 10.10») > la comparaison des permissions actuelles d'un fichier comme
ARDAgent (avec un
s bit) avec le paradigme d'archives d'installation
BOM attestant d'un
x bit > a toujours donné lieu à la
notification d'une modification du standard > sans
jamais aucune tentative de réparation (reconversion
s >
x) - le
SUID_bit étant toujours respecté (quelle que soit l'origine de son instauration).
[Je suspends là ces chinoiseries facétieuses sans creuser des sous-points de détail comme le caractère réfractaire au SUID_bit de certains binaires (genre diskutil), les problèmes de sécurité impliqués par la conversion de l'executable bit (x > s) ou encore le tour de vis introduit par le SIP en ce qui concerne ces aimables roueries d'antan...]
