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

Après avoir lu quelques jolies réponses à cette question , je ne sais toujours pas pourquoi vous voudriez prétendre que vous êtes root sans obtenir aucun des avantages d'être réellement root.

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, est pourquoi ne pouvez-vous pas simplement faire ça avec chown?

Une discussion de Google Groupes ici souligne que vous avez besoin de fakeroot pour compiler un noyau Debian (si vous voulez le faire à partir d'un utilisateur non privilégié). Mon commentaire est que, la raison pour laquelle vous devez être root pour compiler est probablement parce que les autorisations de lecture n'ont pas été définies pour les autres utilisateurs. Si c'est le cas, n'est-ce pas une violation de sécurité que fakeroot autorise pour la compilation (ce qui signifie que gcc peut maintenant lire un fichier qui était pour root)?

Cette réponse décrit ici que les appels système réels sont effectués avec le vrai uid / gid de l'utilisateur , donc là encore où fakeroot aide-t-il?

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

D'après ce que j'ai rassemblé, fakeroot est juste utile lorsque vous souhaitez changer le propriétaire de tous les fichiers de package que vous avez créés pour rooter. Mais vous pouvez le faire avec chown, alors où suis-je manquant dans ma compréhension de la façon dont ce composant est censé être utilisé?

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, est pourquoi ne pouvez-vous pas simplement faire ça avec chown?

Parce que vous ne pouvez pas le faire 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 fakeroot.) C'est tout l'intérêt de fakeroot: 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 la racine 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 poursuivre sans erreur (même s'il s'exécute chown root:root, ou install -o root, etc.). fakerootse souvient de la fausse propriété qu'il prétendait donner aux fichiers, donc les opérations ultérieures qui regardent la propriété voient cela au lieu de la vraie; cela permet aux tarexécutions suivantes, par exemple, de stocker des fichiers appartenant à root.

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

fakerootne tarfait rien pour faire quoi que ce soit, il préserve les modifications que le build veut faire sans laisser ces changements prendre effet sur le système hébergeant le build. Vous n'avez pas besoin fakerootde produire une archive tar contenant un fichier appartenant à root et suid; si vous avez un binaire evilbinary, l'exécution tar cf evil.tar --mode=4755 --owner=root --group=root evilbinary, en tant qu'utilisateur normal, créera une archive tar contenant evilbinary, détenue par root et suid. Cependant, vous ne pourrez pas extraire cette archive tar 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. fakerootest un privilège de-outil d'escalade: il vous permet d'exécuter une build en tant qu'utilisateur normal, tout en préservant les effets que la build aurait eu si elle avait été exécutée en tant que root, permettant à ces effets d'être rejoués plus tard. L'application des effets «pour de vrai» nécessite toujours des privilèges root; fakerootne fournit aucune méthode pour les acquérir.

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

• installer des fichiers, appartenant à root
• ...
• archiver ces fichiers, toujours détenus par 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 fakerootprétend qu'il réussit et se souvient du changement de propriétaire
• ...
• archiver ces fichiers, toujours détenus par root - lorsque tar(ou quel que soit l'archiveur utilisé) demande au système quelle est la propriété du fichier, fakerootmodifie la réponse pour correspondre à la propriété enregistrée précédemment

Ainsi, vous pouvez exécuter une génération de package sans être root, tout en obtenant les mêmes résultats que si vous exécutiez vraiment en tant que root. L'utilisation fakerootest plus sûre: le système ne peut toujours rien faire que votre utilisateur ne puisse pas faire, donc un processus d'installation non autorisé ne peut pas endommager votre système (au-delà de toucher vos fichiers).

Dans Debian, les outils de construction ont été améliorés afin de ne plus en avoir besoin, et vous pouvez construire des paquets sansfakeroot . Ceci est supporté par dpkgdirectement avec la Rules-Requires-Rootdirective (voir rootless-builds.txt).

Pour comprendre l'objectif fakerootet les aspects de sécurité de 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:

1. construire le logiciel (ce qui peut se faire sans privilèges)
2. installer le logiciel (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:

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

Maintenant, un utilisateur termine le processus en installant le package, 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 aux étapes 2 et 3 ci-dessus en nous permettant d'exécuter des processus d'installation de logiciels et de capturer leur comportement, sans exécuter en tant que root.

NON. La fausse racine vous permet d'exécuter des outils de manipulation et de génération de rapports, il rendra compte de manière cohérente. Cependant, il n'accordera pas réellement ces autorisations. Il semblerait 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 utilisiez ensuite tar, zip ou tout autre package.

Cela n'augmente pas vraiment les autorisations, c'est faux. Il ne vous laisse rien faire (supprimer, écrire, lire) que vous ne pourriez pas faire autrement. Vous pourriez produire le paquet (en théorie) sans lui. Vous pourriez obtenir un faux rapport ( ls) sans lui.

Ce n'est pas un défaut de sécurité, car il ne permet pas l' accès, ou tout ce que vous ne pouvez pas faire sans. Il fonctionne sans privilège. Tout ce qu'il dose, c'est intercepter les appels à chown, chmodetc. Cela en fait une non-opération, sauf qu'il enregistre ce qui se serait passé. Il intercepte également les appels vers statetc. afin de signaler les autorisations et la propriété, à partir de sa propre base de données interne, comme si les autres commandes avaient été exécutées. C'est utile, car si vous zippez 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 n'étaient pas lisibles / inscriptibles auparavant resteront non lisibles / 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.

Il s'agit d'un type de machine virtuelle: une machine virtuelle, en général, peut simuler n'importe quel environnement / système d'exploitation, mais ne peut rien faire à l'hôte, ce 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 détenues par 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 la page de manuel originale ^{1 l'} explique en fait assez clairement et de manière concise:fakeroot

fakeroot 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.) avec des fichiers avec des autorisations / propriété root. Sans fakeroot, il faudrait avoir les privilèges root pour créer les fichiers constitutifs des archives avec les autorisations et la propriété appropriées, 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 cela fakeroot, les archives de packages devraient ê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 appropriées. Ce serait un risque pour la sécurité. La création et le conditionnement de logiciels potentiellement non fiables représentent une énorme exposition s'ils sont effectués avec des privilèges root. Grâce à fakeroot, un utilisateur non privilégié avec des fichiers non privilégiés peut toujours générer des archives contenant des fichiers appartenant à root. ²

Mais ce n'est pas un risque pour la sécurité, car rien dans l'archive n'appartient réellement à root tant que les fichiers ne sont PAS EXTRAITS . Et même alors, les fichiers ne seront extraits avec leurs autorisations root intactes que si cela est fait par un utilisateur privilégié. Cette étape - où une fakerootarchive assistée contenant des fichiers "root" est extraite par un utilisateur privilégié - est où la "fausse" racine devient enfin réelle. Jusque-là, aucun privilège root réel n'est jamais obtenu ou contourné.

Remarques

1. Fakeroot a engendré certains concurrents / imitateurs qui se feront passer pour fakeroots'ils étaient installés, y compris fakeroot-nget pseudo. Mais à mon humble avis, ni la page de manuel d '«imitateur» n'est presque aussi claire pour aller droit au but sur cette question. Restez avec l'original, un seul et unique fakerootOG

2. D'autres distributions / systèmes d'emballage surmontent ce problème en n'utilisant simplement pas 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 se fait dans l'espace de l'utilisateur $HOME/rpmbuild/, et des étapes normalement privilégiées comme make installse redirigent (via des mécanismes comme --prefixet DESTDIR) vers une $HOME/rpmbuild/BUILDROOT/hiérarchie qui pourrait être considérée comme une sorte d'espace "fakechroot" (sans réellement l'utiliser fakechroot).

   Mais même pendant make install, tout est exécuté comme et appartenant à l'utilisateur non privilégié. La propriété et les autorisations des fichiers extraits seront définies sur root,rootet 0644(ou 0755pour les exécutables) par défaut, sauf si elles sont remplacées dans le .specfichier de définition de package ( ), auquel cas elles sont stockées en tant que métadonnées dans le package final. Étant donné 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 fakerootn'est nécessaire pendant l'empaquetage. Mais fakerootc'est vraiment juste un chemin différent vers ce même résultat.