Pourquoi les exécutables par exemple dans / usr / sbin sont-ils inscriptibles par root?

Pourriez-vous expliquer pourquoi un fichier binaire compilé (dans, par exemple, /usr/sbin) a une autorisation d'écriture pour l' rootutilisateur?

Pour moi, c'est compilé. Cela signifie que l'écriture directe n'a aucune utilité et peut exposer le fichier à un problème de sécurité.

Un script (par exemple un bashfichier) peut être accessible en écriture car il s'agit essentiellement d'un fichier texte, mais pourquoi est-il le même pour un fichier compilé où aucune écriture n'est réellement nécessaire pour autant que je sache?

Merci d'avance pour vos retours.

— t1m0th33
source

Juste pour clarifier, vous vous demandez pourquoi l'utilisateur roota la permission d'écrire sur un fichier binaire? Si rien d'autre ne serait utile lors de la mise à niveau de ce package.

— Eric Renouf

Notez que les fichiers binaires sont ironiquement les seuls fichiers que nous écrivons / modifions normalement directement sur le disque. Nous ne pouvons pas faire cela avec des fichiers texte comme des scripts car les modifications de texte impliquent de ne pas écrire dans le fichier mais d'ajouter des octets supplémentaires au milieu du fichier ou de supprimer des octets au milieu du fichier. C'est impossible à faire avec fseek fwrite. Donc, pour les fichiers texte, nous lisons normalement sur la RAM, puis supprimons l'ancien fichier et écrivons le contenu de la RAM sur le disque (c'est-à-dire que nous remplaçons). De plus, lorsque vous installez, déplacez ou remplacez des exécutables, vous écrivez sur le disque, vous avez donc besoin d'autorisations d'écriture.

— slebetman

@slebetman: vous pouvez modifier directement les fichiers texte. Par exemple, ouvrez le fichier, étendez-le, mappez-le en mémoire, utilisez memmove()pour déplacer la dernière partie jusqu'à la fin et ouvrez un trou, puis insérez un nouveau texte dans le trou. Ou vous pouvez utiliser une série de pread()/ pwrite()pour faire de même.

— Zan Lynx

@EricRenouf En fait, les autorisations d'écriture sur le fichier binaire ne sont pas nécessaires pour mettre à niveau le package qui le contient. Lors de la mise à niveau du package, l'ancien binaire n'est pas écrit; en fait, cela est impossible si le binaire est en cours d'exécution (recherche ETXTBSY). Au lieu de cela, l'ancien binaire est supprimé et le nouveau binaire est écrit dans un nouveau fichier du même nom. La suppression de fichiers ne nécessite pas d'autorisations d'écriture sur eux, simplement sur le répertoire contenant (c'est-à-dire /usr/sbin/).

— marcelm

@marcelm: À strictement parler, vous n'utilisez pas simplement fseek et write, vous mettez le reste en mémoire RAM. Vous pouvez également mettre le reste en mémoire tampon dans un autre fichier. Ou vous pouvez écrire du nouveau contenu dans un nouveau fichier. Rien de tout cela ne vous permet d'étendre les fichiers texte sans une sorte de grand tampon.

— slebetman

Peu importe si les fichiers /bin(ou tout autre répertoire standard où les exécutables sont conservés) sont accessibles en écriture par root ou non. Sur un serveur Linux que j'utilise, ils sont accessibles en écriture par root, mais sur ma machine OpenBSD, ils ne le sont pas.

Tant qu'ils ne sont pas accessibles en écriture par le groupe ou par "autre"!

Il n'y a pas de problème de sécurité, par exemple

-rwxr-xr-x 1 root root 126584 Feb 18  2016 /bin/ls

Si quelqu'un voulait l'écraser, il faudrait qu'il soit root, et si c'est le cas rootet l'écraser, alors ils sont soit

l'installation d'une nouvelle version, ou
maladroit, ou
un attaquant disposant déjà des droits root .

Une autre chose à considérer est que root peut écrire dans le fichier, qu'il soit protégé en écriture ou non, car ... root.

Notez également qu'un "script" est autant un exécutable qu'un fichier binaire. Un script n'a pas besoin d'être accessible en écriture "car il s'agit d'un fichier texte". Si quoi que ce soit, il devrait probablement avoir la même autorisation que les autres exécutables du même répertoire.

N'allez pas changer les autorisations sur tout maintenant! Cela peut provoquer toutes sortes de ravages et potentiellement confondre les gestionnaires de packages qui pourraient vérifier que les autorisations sont correctement définies. Cela peut également rendre le système vulnérable si vous modifiez accidentellement les autorisations de manière incorrecte sur une application critique pour la sécurité.

Supposons simplement que les autorisations sur les exécutables sont définies correctement, sauf si vous trouvez quelque chose qui semble vraiment étrange, auquel cas vous devriez probablement contacter le responsable du package pour vérifier plutôt que de commencer à changer des choses.

D'après les commentaires et sur le chat , il y a eu un appel pour un peu d'histoire.

L'historique des autorisations sur les binaires sous Linux n'est pas quelque chose que je sache. On peut supposer qu'ils ont simplement hérité des autorisations du répertoire, ou simplement de la valeur par défaut umaskde Linux, mais je ne sais vraiment pas.

Ce que je sais, c'est qu'OpenBSD installe les binaires dans le système de base ¹ avec le mode d'autorisation 555 par défaut ( -r-xr-xr-x). Ceci est spécifié dans un fragment Makefile dans /usr/share/mk/bsd.own.mklequel est défini BINMODEsur 555 (sauf s'il est déjà défini). Ceci est utilisé plus tard lors de l'installation des exécutables pendant make builddans /usr/src.

J'ai jeté un œil au journal CVS annoté de ce fichier et j'ai constaté que cette ligne du fichier était inchangée depuis son importation depuis NetBSD en 1995.

Sur NetBSD, le fichier a été placé pour la première fois dans CVS en 1993, avec BINMODEla valeur 555.

Le projet FreeBSD semble avoir utilisé exactement le même fichier que NetBSD depuis au moins 1994 , et avec une validation ultérieure ajoute un indice dans le message de validation que les anciens fichiers provenaient de la version 4.4BSD de Berkeley Software Distribution.

Au-delà, le CSRG de Berkeley a conservé les sources dans SCCS, mais leur référentiel est disponible sous forme Git sur GitHub ² . Le dossier que nous traitons ici semble avoir été commis par Keith Bostic (ou quelqu'un à proximité de lui) en 1990.

Voilà donc cette histoire. Si vous voulez le pourquoi , je suppose que nous devrons demander à Keith. J'espérais un peu voir un message de validation d'un changement disant " cela doit être 555 parce que ... ", mais non.

^{1 Les} _{systèmes BSD ont une division plus stricte en "système de base" et "packages tiers" (ports / packages) que Linux. Le système de base est une unité cohérente qui fournit un ensemble complet de fonctionnalités pour exécuter le système d'exploitation, tandis que les ports ou packages sont considérés comme des "logiciels locaux" et sont installés sous /usr/local.}

² _{Un référentiel GitHub plus complet des versions Unix à partir des années 70 est également disponible .}

— Kusalananda
source

Merci pour votre réponse. L'autorisation d'écriture est normale car elle n'a pas vraiment d'importance en tant qu'utilisateur root (il peut tout faire). Mais, comme cela n'a pas vraiment d'importance, pourquoi ne mettons-nous aucune autorisation d'écriture si c'est la même chose depuis le début? Est-ce une décision arbitraire?

— t1m0th33

@ t1m0th33 Je crois que cela peut être une décision arbitraire que quelqu'un a prise, oui. Comme je l'ai dit, sur mon système OpenBSD, les fichiers de ces emplacements ne sont pas accessibles en écriture par root.

— Kusalananda

Je ne pense pas que ce soit une décision consciente de quiconque. Par défaut, le gestionnaire de packages installe le fichier avec les bits d'autorisation avec lesquels il s'est retrouvé pendant le processus de génération; lors de la construction de l'éditeur de liens a créé les fichiers avec les autorisations 755, car c'est ce que vous obtenez lorsque vous soustrayez l'umask de 777, et la racine umask (sur les machines de construction du fournisseur du système d'exploitation) avait pendant la construction était 022 car 022 est l'umask par défaut pour tout le monde et la fabrication ce serait 222 car root serait un travail supplémentaire inutile.

— Henning Makholm

+1 pour "N'allez pas changer les autorisations sur tout maintenant!" Je vois tellement de questions comme ça sur Ubuntu où l' utilisateur Demandez a fait chmod -R sur /usrou /var, et la surprise - leur sudone fonctionne pas ou quelque chose ne fonctionne pas ailleurs.

— Sergiy Kolodyazhnyy

Historiquement, l'absence de permission d'écriture pour root n'aurait aucun effet (root peut chmod n'importe quoi, et n'a même pas besoin de le faire, car root n'obtient jamais un EPERM ouvert ou écrit de toute façon). Je me demande si ce 555 a commencé parce qu'il était devenu possible pour root d'être restreint (quand les niveaux de sécurité sont-ils apparus pour la première fois? En même temps que 4.4BSD ou au début 386BSD / NetBSD?)