Pourquoi “chmod -R 777 /” est-il destructif?

255

C’est une question canonique sur l’autorisation de fichier et pourquoi 777 est "destructif".

Je ne vous demande pas comment résoudre ce problème, car il existe déjà une tonne de références sur Server Fault (réinstallez le système d'exploitation). Pourquoi fait-il quelque chose de destructeur?

Si vous avez déjà exécuté cette commande, vous détruisez presque immédiatement votre système d'exploitation. Je ne comprends pas pourquoi la suppression des restrictions a un impact sur les processus existants. Par exemple, si je n'ai pas accès en lecture à quelque chose et après un brouillage rapide dans le terminal, tout à coup, j'ai maintenant bien accès ... pourquoi cela cause-t-il une panne de Linux?

linux permissions chmod samwise
la source
2
J'ai retenu mon souffle quand j'ai vu cette question.
Alireza Savand

Réponses:

344

Tout d'abord, un nitpick de terminologie mineure: chmodne supprime pas les autorisations. Cela les change .

Maintenant le fond du problème - Le mode 777signifie "Tout le monde peut lire, écrire ou exécuter ce fichier" - Vous avez donné la permission à quiconque de faire (efficacement) ce qu'il veut.

Maintenant, pourquoi est-ce mauvais?

  1. Vous venez de laisser tout le monde lire / modifier tous les fichiers de votre système.
    • Fini la sécurité des mots de passe (tout le monde peut lire le fichier shadow et déchiffrer vos mots de passe, mais pourquoi s'en préoccuper? Il suffit de CHANGER le mot de passe! C'est beaucoup plus simple!).
    • Au revoir sécurité pour vos fichiers binaires (quelqu'un peut simplement écrire un nouveau loginprogramme qui les laisse entrer à tout moment).
    • Dites adieu à vos fichiers: un utilisateur vous dirige mal rm -r /et tout est fini. On a dit à l'OS de les laisser faire ce qu'ils voulaient!
  2. Vous avez pissé tous les programmes qui vérifient les autorisations sur les fichiers avant de commencer.
    sudo, sendmailet une foule d’autres ne commenceront tout simplement plus. Ils examineront les droits d'accès aux fichiers clés, constateront qu'ils ne sont pas ce qu'ils sont censés être et renverront un message d'erreur.
    De la même manière ssh, les disques casseront horriblement (les fichiers de clé doivent avoir des autorisations spécifiques, sinon ils sont "non sécurisés" et par défaut, SSH refusera de les utiliser.)
  3. Vous avez effacé les bits setuid / setgid sur les programmes qui les avaient.
    Le mode 777est réellement . Parmi les éléments de ce premier chiffre figurent les bits et . La plupart des programmes qui sont setuid / setgid ont ce bit défini car ils doivent s'exécuter avec certains privilèges. Ils sont cassés maintenant.0777setuidsetgid
  4. Vous avez cassé /tmpet/var/tmp L'autre élément de ce chiffre octal qui a été mis à zéro est le sticky bit- Cela protège les fichiers entre /tmp(et /var/tmp) d'être supprimés par des personnes qui ne les possèdent pas.
    Il y a (malheureusement) beaucoup de scripts mal conçus qui "nettoient" en faisant un rm -r /tmp/*, et sans le truc collant, /tmp vous pouvez embrasser tous les fichiers de ce répertoire.
    Faire disparaître des fichiers de travail peut vraiment perturber certains programmes mal écrits ...
  5. Vous avez causé des dégâts dans /dev /procdes systèmes de fichiers similaires.
    Il s'agit davantage d'un problème sur les systèmes Unix plus anciens, qui /devsont un système de fichiers réel, et les éléments qu'il contient sont des fichiers spéciaux créés avec mknod, car les modifications apportées aux autorisations seront préservées lors des redémarrages, mais sur tout système. le fait de modifier les autorisations de votre appareil peut entraîner des problèmes importants, allant des risques de sécurité évidents (tout le monde peut lire chaque ATS) aux causes moins évidentes d'une panique du noyau.
    Credit to @Tonny for pointing out this possibility
  6. Les sockets et les pipes peuvent se briser ou avoir d'autres problèmes Les sockets et les pipes peuvent se briser entièrement ou être exposés à une injection malveillante du fait de leur possibilité d'écriture.
    Credit to @Tonny for pointing out this possibility
  7. Vous avez créé chaque fichier sur votre exécutable système
    De nombreuses personnes ont .dans leur PATHenvironnement une variable (vous ne devriez pas!) - Cela pourrait causer une mauvaise surprise car tout le monde peut maintenant déposer un fichier nommé commodément comme une commande (par exemple, makeou ls, et avoir une chance de vous faire exécuter leur code malveillant.
    Credit to @RichHomolka for pointing out this possibility
  8. Sur certains systèmes chmod, les listes de contrôle d'accès (ACL) seront réinitialisées.
    Cela signifie que vous devrez peut-être recréer toutes vos listes de contrôle d'accès en plus de fixer les autorisations partout (ce qui constitue un exemple réel de destruction de la commande).
    Credit to @JamesYoungman for pointing out this possibility

Les parties du système en cours d'exécution continueront-elles à fonctionner? Probablement pendant au moins un moment.
Mais la prochaine fois que vous aurez besoin de lancer un programme, de redémarrer un service, ou encore, interdisez de redémarrer la boîte dans laquelle vous vous trouvez pour un monde blessé, car les n ° 2 et n ° 3 ci-dessus se dresseront la tête laide.

voretaq7
la source
1
Au moins sur certains systèmes /tmpseraient fixés après un redémarrage. Bien que beaucoup d'autres choses semblent être brisées. Au moins dans la VM que je viens de tester, il semble qu’un redémarrage ait corrigé les /tmpautorisations. Il doit y avoir quelque chose dans un script de démarrage quelque part.
Zoredache
@Zoredache Les systèmes qui utilisent tmpfshabituellement se règlent eux-mêmes, ceux qui ont / tmp sur le disque peuvent (cela dépend de leurs scripts de démarrage)
voretaq7
45
+1 pour signaler que setuid et setgid seraient éliminés. C'est un aspect extrêmement destructeur. Essayez de lancer find / -perms -4000 -type fet find / -perms -2000 -type fde voir divers fichiers binaires qui dépendent de ces indicateurs.
Kyle Smith
2
Taper quelque chose comme "less foo.txt" n’exécuterait pas un fichier appelé less.txt, quel que soit le bit exécutable défini. Vous devriez avoir le répertoire less.txt dans votre chemin et taper "less.txt foo.txt" - ce n'est pas vraiment une chose accidentelle. Même si vous utilisiez la complétion de shell, il s'arrêterait à moins et vous auriez toujours besoin d'ajouter le .txt. Pour appeler un fichier texte aléatoire avec un ensemble de bits d’exécutable, vous devez ./nameoffile.txt.
Le vrai Bill
3
@Deji everyoneest défini comme l'union de jeu , y compris l'utilisateur qui possède le fichier, les utilisateurs du groupe qui possède le fichier, et les utilisateurs qui ne répondent pas à l' un de ces critères (littéralement les trois chiffres d'autorisation octal: User, Groupet Other). En d'autres termes, tout utilisateur ayant accès au système . ("Access" dans ce contexte pourrait être un compte shell, c’est la façon dont je le traiterais normalement, mais il inclut également l’accès via un formulaire Web / CGI qui écrit des données sur le disque: l’ wwwutilisateur peut maintenant écrire dans n’importe quel fichier du système. , ce qui signifie que les visiteurs aléatoires peuvent aussi.)
voretaq7
102

Un aspect important est qu’il existe de nombreux outils comme ssh / sudo qui vérifient les autorisations du système de fichiers pour les fichiers de configuration clés. Si les autorisations sont incorrectes, ces outils sont conçus pour échouer, car cela indiquerait un grave problème de sécurité. Sur mon système de test Debian et peut-être sur d'autres, la capacité de connexion échoue, probablement parce que le binaire de connexion ou quelque chose dans PAM dispose de contrôles d'autorisation.

Ce n'est donc pas vraiment que le système est détruit, mais bien de nombreux outils sont conçus pour échouer immédiatement lorsque les autorisations sont erronées.

Si vous redémarrez un système après l'avoir effectué, chmod 777 -R /il démarrera, et vous pouvez démarrer des processus sans vérification explicite des autorisations. Ainsi, le système n'est pas vraiment mort, mais une conception un peu inutilisable .

Zoredache
la source