Comment fakeroot n'est pas une faille de sécurité sous Linux ?

Jusqu'à présent, ce que je peux comprendre, c'est que fakeroot est utilisé pour donner la propriété à un fichier qui doit être root lorsqu'il est décompressé/taré. Ma question, pourquoi ne pouvez-vous pas faire cela avec chown ?

Parce que vous ne pouvez pas faire ça avec chown , du moins pas en tant qu'utilisateur non root. (Et si vous exécutez en tant que root, vous n'avez pas besoin de fakeroot .) C'est tout l'intérêt de fakeroot :pour permettre aux programmes qui s'attendent à être exécutés en tant que root de s'exécuter en tant qu'utilisateur normal, tout en prétendant que les opérations nécessitant root réussissent.

Ceci est généralement utilisé lors de la construction d'un package, afin que le processus d'installation du package en cours d'installation puisse se dérouler sans erreur (même s'il exécute chown root:root , ou install -o root , etc.). fakeroot se souvient de la fausse propriété qu'il a prétendu donner aux fichiers, de sorte que les opérations ultérieures examinant la propriété voient ceci au lieu du vrai ; cela permet les tar suivants s'exécute par exemple pour stocker des fichiers appartenant à root.

Comment fakeroot arrête-t-il les élévations de privilèges indésirables sous Linux ? Si fakeroot peut inciter tar à créer un fichier appartenant à root, pourquoi ne pas faire quelque chose de similaire avec SUID ?

fakeroot ne trompe pas tar à faire quoi que ce soit, il préserve les modifications que la construction souhaite apporter sans laisser ces modifications prendre effet sur le système hébergeant la construction. Vous n'avez pas besoin de fakeroot pour produire une archive tar contenant un fichier appartenant à root et suid ; si vous avez un evilbinary binaire , exécutant tar cf evil.tar --mode=4755 --owner=root --group=root evilbinary , en tant qu'utilisateur régulier, créera une archive tar contenant evilbinary , appartenant à root et suid. Cependant, vous ne pourrez pas extraire cette archive et conserver ces autorisations à moins que vous ne le fassiez en tant que root :il n'y a pas d'escalade de privilèges ici. fakeroot est un privilège de -outil d'escalade :il vous permet d'exécuter une construction en tant qu'utilisateur normal, tout en préservant les effets que la construction aurait eus si elle avait été exécutée en tant que root, permettant à ces effets d'être rejoués plus tard. Appliquer les effets "pour de vrai" nécessite toujours des privilèges root ; fakeroot ne fournit aucune méthode pour les acquérir.

Pour comprendre l'utilisation de fakeroot plus en détail, considérez qu'une construction de distribution typique implique les opérations suivantes (parmi beaucoup d'autres) :

installer les fichiers appartenant à root
...
archiver ces fichiers, qui appartiennent toujours à root, de sorte que lorsqu'ils seront extraits, ils appartiendront à root

La première partie échoue évidemment si vous n'êtes pas root. Cependant, lors de l'exécution sous fakeroot , en tant qu'utilisateur normal, le processus devient

installer des fichiers, appartenant à root — cela échoue, mais fakeroot prétend qu'il réussit, et se souvient du changement de propriétaire
...
archiver ces fichiers, toujours propriété de root — quand tar (ou quel que soit l'archiveur utilisé) demande au système quel est le propriétaire du fichier, fakeroot modifie la réponse pour qu'elle corresponde à la propriété enregistrée précédemment

Ainsi, vous pouvez exécuter une construction de paquet sans être root, tout en obtenant les mêmes résultats que vous obtiendriez si vous exécutiez réellement en tant que root. Utilisation de fakeroot est plus sûr :le système ne peut toujours pas faire ce que votre utilisateur ne peut pas faire, donc un processus d'installation malveillant ne peut pas endommager votre système (au-delà de toucher vos fichiers).

Dans Debian, les outils de construction ont été améliorés pour ne plus en avoir besoin, et vous pouvez construire des paquets sans fakeroot . Ceci est pris en charge par dpkg directement avec le Rules-Requires-Root directive (voir rootless-builds.txt ).

Pour comprendre le but de fakeroot , et les aspects de sécurité liés à l'exécution en tant que root ou non, il peut être utile de considérer l'objectif de l'empaquetage. Lorsque vous installez un logiciel à partir de la source, pour une utilisation à l'échelle du système, vous procédez comme suit :

construire le logiciel (ce qui peut être fait sans privilèges)
installer le logiciel (ce qui doit être fait en tant que root, ou au moins en tant qu'utilisateur autorisé à écrire dans les emplacements système appropriés)

Lorsque vous empaquetez un logiciel, vous retardez la deuxième partie; mais pour le faire avec succès, vous devez toujours "installer" le logiciel, dans le package plutôt que sur le système. Ainsi, lorsque vous empaquetez un logiciel, le processus devient :

construire le logiciel (sans privilèges spéciaux)
faire semblant d'installer le logiciel (là encore sans privilèges spéciaux)
capturer l'installation du logiciel sous forme de package (idem)
rendre le package disponible (idem)

Maintenant, un utilisateur termine le processus en installant le package, ce qui doit être fait en tant que root (ou encore, un utilisateur avec les privilèges appropriés pour écrire aux emplacements appropriés). C'est là que le processus privilégié retardé est réalisé, et c'est la seule partie du processus qui nécessite des privilèges spéciaux.

fakeroot aide avec les étapes 2 et 3 ci-dessus en nous permettant d'exécuter des processus d'installation de logiciels et de capturer leur comportement, sans s'exécuter en tant que root.

NON. La fausse racine vous permet d'exécuter des outils de manipulation des autorisations et de création de rapports, il rapportera de manière cohérente. Cependant, il n'accordera pas réellement ces autorisations. Il semblera que vous les ayez (faux). Cela ne changera rien en dehors de l'environnement.

Il est utile, si vous souhaitez créer une structure de répertoires, qui contient la propriété et les autorisations, qui ne peuvent pas être définies par votre utilisateur, que vous allez ensuite tar, zip ou autre package.

Ce n'est pas vraiment élever les autorisations, c'est faux. Il ne vous permet pas de faire quoi que ce soit (supprimer, écrire, lire) que vous ne pourriez pas faire autrement. Vous pourriez produire le package (en théorie) sans lui. Vous pourriez obtenir un faux rapport (ls ) sans elle.

Ce n'est pas une faille de sécurité, car ce n'est pas le cas autoriser l'accès, ou tout ce que vous ne pouvez pas faire sans lui. Il fonctionne sans privilège. Tout ce qu'il faut, c'est intercepter les appels vers chown , chmod , etc. Cela en fait une non-opération, sauf qu'il enregistre ce qui se serait passé. Il intercepte également les appels au stat etc. afin qu'il signale les autorisations et la propriété, à partir de sa propre base de données interne, comme si les autres commandes avaient été effectuées. Ceci est utile, car si vous compressez ensuite le répertoire, il aura les fausses autorisations. Si vous décompressez ensuite, en tant que root, les autorisations deviendront réelles.

Tous les fichiers qui ne sont pas lisibles/inscriptibles auparavant resteront illisibles/inscriptibles. Tous les fichiers spéciaux (par exemple, les appareils) créés n'auront aucun pouvoir spécial. Tout set-uid (à un autre utilisateur), les fichiers ne seront pas set-uid. Toute autre élévation de privilèges ne fonctionnera pas.

C'est un type de machine virtuelle :une machine virtuelle, en général, peut simuler n'importe quel environnement/OS, mais ne peut rien faire à l'hôte, qu'aucune autre application ne pourrait faire. Dans la machine virtuelle, vous pouvez sembler faire n'importe quoi. Vous pouvez réinventer le système de sécurité pour qu'il soit identique ou différent, mais tout cela existera sur l'hôte, en tant que ressources appartenant à l'utilisateur/groupe du processus exécutant l'environnement virtuel.

Il y a déjà deux bonnes réponses très détaillées ici, mais je soulignerai simplement que le paragraphe d'introduction de l'original fakeroot La page de manuel l'explique en fait de manière assez claire et concise :

fausse racine exécute une commande dans un environnement dans lequel il semble avoir des privilèges root pour la manipulation de fichiers. Ceci est utile pour permettre aux utilisateurs de créer des archives (tar, ar, .deb, etc.) contenant des fichiers avec des autorisations/propriétés root. Sans fakeroot il faudrait avoir des privilèges root pour créer les fichiers constitutifs des archives avec les autorisations et la propriété correctes, puis les emballer, ou il faudrait construire les archives directement, sans utiliser l'archiveur.

Fakeroot permet à un utilisateur non root de créer des archives contenant des fichiers appartenant à root, ce qui est un élément essentiel de la génération et de la distribution de packages logiciels binaires sous Linux. Sans fakeroot , les archives de package doivent être générées lors de l'exécution en tant que racine réelle, afin qu'elles contiennent la propriété et les autorisations de fichier correctes. Cela serait être un risque pour la sécurité. La création et l'empaquetage de logiciels potentiellement non fiables sont une exposition énorme si cela est fait avec des privilèges root. Merci à fakeroot , un utilisateur non privilégié avec des fichiers non privilégiés peut toujours générer des archives contenant des fichiers appartenant à la racine.

Mais ce n'est pas un risque pour la sécurité, car rien dans l'archive n'est réellement appartenant à root jusqu'à ce que les fichiers soient EXTRAIT . Et même dans ce cas, les fichiers ne seront extraits avec leurs autorisations root intactes que si cela est fait par un utilisateur privilégié. Cette étape - où un fakeroot -l'archive assistée contenant les fichiers "racines" est extraite par un utilisateur privilégié - c'est là que la "fausse" racine devient enfin réelle. Jusqu'à ce point, aucun privilège racine réel n'est jamais obtenu ou contourné.

Remarques

Fakeroot a engendré des concurrents/imitateurs qui se feront passer pour fakeroot si installé, y compris fakeroot-ng et pseudo . Mais à mon humble avis, ni la page de manuel de "l'imitateur" n'est presque aussi claire pour aller droit au but sur cette question. Restez fidèle à l'original, le seul et unique fakeroot O.G.
D'autres distributions/systèmes d'emballage surmontent cela simplement en pas en utilisant la propriété root dans leurs archives de packages. Sur Fedora, par exemple, un logiciel peut être compilé, installé et empaqueté par un utilisateur non privilégié sans nécessiter fakeroot . Tout est fait dans le $HOME/rpmbuild/ de l'utilisateur espace, et étapes normalement privilégiées comme make install être redirigé (via des mécanismes comme --prefix et DESTDIR ) à un $HOME/rpmbuild/BUILDROOT/ hiérarchie qui pourrait être considérée comme une sorte d'espace "fakechroot" (sans utiliser réellement fakechroot ).

Mais même pendant make install , tout est exécuté en tant que propriété de l'utilisateur non privilégié. La propriété et les autorisations des fichiers extraits seront définies sur root,root et 0644 (ou 0755 pour les exécutables) par défaut, sauf s'il est remplacé dans la définition du package (.spec ) auquel cas ils sont stockés en tant que métadonnées dans le package final. Parce qu'aucune autorisation ou propriété n'est réellement appliquée jusqu'au processus d'installation (privilégié) du package rpm, ni root ni fakeroot est nécessaire lors de l'emballage. Mais fakeroot est vraiment juste un chemin différent vers ce même résultat.