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


C'est un Question canonique à propos de l'autorisation de fichier et Pourquoi 777 est "destructif".

Je ne demande pas comment résoudre ce problème, car il existe déjà une tonne de références sur Fault Server (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?


246
2018-02-28 21:25


origine


J'ai retenu mon souffle quand j'ai vu cette question. - Alireza Savand


Réponses:


Tout d’abord une minuscule terminologie: chmod ne pas retirer autorisations. Il CHANGEMENTS leur.


Maintenant la viande du problème - La mode 777 signifie "Tout le monde peut lire, écrire ou exécuter ce fichier" - Vous avez donné la permission que quiconque fasse (effectivement) 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.
    • Adieu 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 login programme qui les laisse entrer à chaque fois).
    • Dites adieu à vos fichiers: un utilisateur mal dirigé 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 même ssh 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.
    La mode 777 est en fait 0777. Parmi les éléments de ce chiffre de tête figurent les setuid et setgid morceaux.
    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.
  4. Vous avez cassé /tmp et /var/tmp L’autre élément de ce chiffre octal qui a été mis à zéro est le sticky bit - Celui qui protège les fichiers en /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 comportés qui "nettoient" en faisant un rm -r /tmp/*, et sans le bit collant mis sur /tmp  vous pouvez dire adieu à 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 ravages dans /dev  /proc et systèmes de fichiers similaires
    C’est davantage un problème sur les anciens systèmes Unix où /devest un vrai système de fichiers et contient des fichiers spéciaux créés avec mknodSi les autorisations changent, les modifications seront conservées lors des redémarrages, mais sur tout système dont les autorisations de votre appareil changent, des problèmes importants peuvent survenir, allant des risques de sécurité évidents (tout le monde peut lire chaque téléscripteur) aux causes moins évidentes de la panique du noyau.
    Credit to @Tonny for pointing out this possibility
  6. Les sockets et les tuyaux peuvent se briser ou avoir d'autres problèmes Les sockets et les tuyaux 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
    Beaucoup de gens ont . dans leurs PATH variable d’environnement (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 make ou lset tentez de vous faire exécuter leur code malveillant.
    Credit to @RichHomolka for pointing out this possibility
  8. Sur certains systèmes chmod réinitialisera les listes de contrôle d'accès (ACL)
    Cela signifie que vous devrez peut-être recréer toutes vos listes de contrôle d'accès en plus de la fixation des autorisations partout (et il s'agit d'un exemple concret de commande destructive).
    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 dresseront leurs têtes laides.


335
2018-02-28 21:46



Au moins sur certains systèmes /tmp serait corrigé 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 corrige la /tmp autorisations. Il doit y avoir quelque chose dans un script de démarrage quelque part. - Zoredache
@Zoredache Systèmes qui utilisent tmpfs généralement réparer eux-mêmes, ceux qui ont / tmp sur le disque peut (dépend de leurs scripts de démarrage) - voretaq7
+1 pour signaler que setuid et setgid seraient éliminés. C'est un aspect extrêmement destructeur. Essayez de courir find / -perms -4000 -type f et find / -perms -2000 -type f pour voir différents fichiers binaires qui dépendent de ces drapeaux. - Kyle Smith
Taper quelque chose comme "less foo.txt" n’exécutera pas un fichier appelé less.txt, quel que soit le bit exécutable défini. Vous devez 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 fichier .txt. Pour appeler un fichier texte aléatoire avec un ensemble de bits exécutables, vous devez ./nameoffile.txt. - The Real Bill
@ Deji everyone est défini comme l'union de l'ensemble comprenant l'utilisateur à qui appartient le fichier, les utilisateurs du groupe à qui appartient le fichier et les utilisateurs qui ne répondent à aucun de ces critères (littéralement les trois chiffres de permission octaux: User, Group, et Other). En d'autres termes n'importe quel utilisateur ayant accès au système. ("Accès" dans ce contexte pourrait être un compte shell, c’est comment je l’adresserais normalement, mais cela inclut également l’accès via un formulaire Web / CGI qui écrit des données sur le disque: www l’utilisateur peut maintenant écrire dans n’importe quel fichier du système, ce qui signifie que les visiteurs peuvent en faire autant.) - voretaq7


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 avoir effectué une chmod 777 -R / il va démarrer et vous pouvez démarrer des processus sans vérification explicite des autorisations. Donc, le système n'est pas vraiment mort, juste un peu inutilisable intentionnellement.


100
2018-02-28 21:33