Mauvais réglage chmod / 777. Des problèmes?


33

J'essayais de courir, chmod -R 777 ./mais j'ai fini par taper chmod -R 777 /et mettre 777tout mon ordinateur. Qu'est-ce qui peut aller mal? Comment puis-je le réparer?



qu'est-ce qui peut mal tourner dans le système? va-t-il cesser de fonctionner?
Vinnycx

6
Bien sûr, il y a des problèmes. SSH va échouer par exemple.
Ceving

2
SSH se ferme si le répertoire de base est lisible par tout le monde. Régler tout sur 777 revient à tout faire en tant que root.
Ceving

3
Voir aussi serverfault.com/questions/364677/why-is-chmod-r-777-destructive qui donne plus de détails sur ce qui va mal se passer.
Gilles, arrête de faire le mal '25

Réponses:


46

Problèmes? Oui beaucoup. Peut-il être réparé? Sûr. Plus rapide que de réinstaller? Probablement pas.

Ma recommandation est de réinstaller. Conservez une sauvegarde du système existant et restaurez la liste des paquetages et le contenu des fichiers dans /etcet /var. Pour /usr/local, vous pouvez probablement restaurer les autorisations manuellement. Pour /homeet /srv, vous devrez restaurer les autorisations à partir de sauvegardes.

S'il s'agit d'un système avec plusieurs utilisateurs locaux, notez que rendre certains fichiers lisibles pour tout le monde a révélé certaines choses qui auraient dû rester confidentielles.

  • Votre liste de mots de passe est maintenant compromise: les utilisateurs locaux ont accès à la liste de mots de passe hachés et peuvent essayer de les forcer brutalement. Avertissez vos utilisateurs de cela.
  • Toutes les données utilisateur privées (clés SSH, mots de passe stockés, e-mail, tout ce que les utilisateurs pourraient considérer comme confidentiel) ont été exposées à tous les utilisateurs locaux. Avertissez vos utilisateurs de cela.

Si vous voulez vraiment essayer de réparer (plus un exercice d'apprentissage qu'un itinéraire de récupération pratique), restaurez d'abord les autorisations de quelques fichiers. Notez que bien que la plupart des fichiers soient maintenant trop ouverts, il manque quelques bits setuid nécessaires . Voici les étapes à suivre avant toute autre chose. Notez qu'il ne s'agit pas d'une liste exhaustive, mais simplement d'une tentative de rendre le système à peine fonctionnel.

chmod -R go-w /
chmod 440 /etc/sudoers
chmod 640 /etc/shadow /etc/gshadow
chmod 600 /etc/ssh/*_key /etc/ssh*key   # whichever matches
chmod 710 /etc/ssl/private /etc/cups/ssl
chmod 1777 /tmp /var/tmp /var/lock
chmod 4755 /bin/su /usr/bin/passwd /usr/bin/sudo /usr/bin/sudoedit
chmod 2755 /var/mail /var/spool/mail

Ensuite, vous devrez restaurer toutes les autorisations partout. Pour les fichiers situés sous /usr, vous pouvez réinstaller les packages à l'aide de l'une des commandes suivantes, en fonction de votre distribution:

  • Si vous utilisez Debian, Ubuntu ou une autre distribution basée sur APT, vous pouvez exécuter apt-get --reinstall install
  • Si vous utilisez Arch Linux, vous pouvez exécuter pacman -S $(pacman -Qq --dbpath /newarch/var/lib/pacman) --root /newarch --dbpath /newarch/var/lib/pacman, à condition que vous soyez dans un Live CD et que votre installation d’Arch soit montée /newarch.

Pour les fichiers sous /etcet /var, cela ne fonctionnera pas, car il en restera beaucoup: vous devrez répliquer les autorisations sur une installation opérationnelle. Pour les fichiers sous /srvet /home, vous devrez quand même restaurer à partir de sauvegardes. Comme vous pouvez le constater, vous pouvez aussi bien réinstaller.


6
D'accord, à moins d'être un expert, vous n'avez presque aucune chance de réparer cette situation sans une réinstallation complète ou une restauration à partir de sauvegardes. Il est trop dangereux de laisser le système fonctionner tel quel.
Arrowmaster

3
S'il y a des utilisateurs sur le système, je les plains.
Jürgen A. Erhard

19

Vous ne le remarquerez peut-être pas au début, mais beaucoup de choses peuvent et vont mal tourner. Le problème principal est que le modèle de sécurité complet pour le système entier est cassé. C'est comme avoir un corps sans peau, des organes en l'air. Il est voué à être infecté parce que ce n'est pas censé fonctionner comme ça. Même si cela semble fonctionner pendant quelques minutes, vous devez nettoyer cela.

La meilleure façon serait en fait de partir de zéro. Cela réduira considérablement vos risques et vous donnera un résultat plus propre en moins de temps. Si vous avez des sauvegardes appropriées, cela ne devrait pas être une expérience trop tentante.

Si vous essayez de le nettoyer, le moyen principal serait de demander au gestionnaire de paquets de votre distribution de réinstaller TOUT sur le système, y compris en écrasant les fichiers de configuration. Ensuite, utilisez le système de vérification qu’il doit examiner et assurez-vous qu’aucun d’entre eux n’est marqué comme ayant des fichiers avec des autorisations sortant de l’ordinaire. Ensuite, examinez des éléments tels que les répertoires personnels des utilisateurs et réinitialisez le tout pour obtenir des autorisations rationnelles en masse, puis examinez les quelques éléments devant disposer d'autorisations spéciales (tels que les fichiers de clés ssh). Enfin, recherchez un système complet pour tout ce qui est marqué 777 et parcourez la liste (elle devrait être petite si vous avez effectué les autres étapes à fond) et travaillez-les un à un en vous assurant qu'ils sont bien tels qu'ils sont.


Mais, mis à part la sécurité, qu'est-ce qui ne va pas avec les applications? Cesseront-ils de travailler? Ou la sécurité est la plus grande préoccupation ici?
Vinnycx

La sécurité est la principale préoccupation, mais de nombreux programmes, en particulier dans les coulisses, tels que les démons de journalisation, cron, etc.
Caleb

Cron va cesser de travailler juste à cause de 777?
Vinnycx

1
Il existe plusieurs systèmes cron différents, mais aucun cron qui se respecte ne devrait exécuter des tâches dans le cron de root lorsque le fichier crontab est accessible en écriture pour le monde entier! De plus, le démon mail qui gère les notifications cron devrait se plaindre pour d'autres raisons.
Caleb

10

SOLUTION: J'ai testé cela dans les centres

Ce mec a sauvé mon travail! (Vous devez accéder en quelque sorte)

http://www.adminlinux.org/2009/07/how-to-restore-default-system.html

1) Pour réinitialiser les uids et les gids sur les fichiers et les répertoires:

for u in $(rpm -qa); do rpm --setugids $u; done

2) Aux autorisations sur les fichiers et les répertoires

for p in $(rpm -qa); do rpm --setperms $p; done

puis changez manuellement les permisions en ces fichiers:

# ll /etc/ssh/
# chmod 600 /etc/ssh/ssh_host_rsa_key
# chmod 600 /etc/ssh/ssh_host_dsa_key
# service sshd restart

5

Certains programmes liés à la sécurité ne démarreront pas si certains fichiers ont des autorisations trop "lâches". Comme @ceving l'a dit, sshdc'est le plus typique de cela.

La principale chose qui peut mal se passer est que tout utilisateur peut maintenant ouvrir, lire et écrire n’importe quel fichier de votre système. Les deux raisons qui expliquent cette situation sont les suivantes: A) si un utilisateur malveillant prend le contrôle de votre système par le biais d’un exploit ou d’une mauvaise configuration, il peut maintenant modifier tout ce qui se trouve sur votre système et B) vous pouvez supprimer tout ce que vous voulez, même si vous le souhaitez. vous n'êtes pas root, vous venez donc d'annuler la plupart des protections contre le non-fonctionnement de root.

Si vous n'avez pas sauvegardé les autorisations auparavant, vous vous trouvez dans une situation délicate. Vous pourrez peut-être créer un script qui "récupérera" une liste d'autorisations à partir d'un système fraîchement installé, puis "appliquera" celles-ci à tout ce qui se trouve sur votre système. Je n'ai cependant pas un tel script à portée de main.


Mais, mis à part la sécurité, qu'est-ce qui ne va pas avec les applications? Cesseront-ils de travailler? Ou la sécurité est la plus grande préoccupation ici?
Vinnycx

Juste le couple d'applications qui refusent de démarrer si les autorisations sont trop lâches. La sécurité est la plus grande préoccupation. Mais c'est aussi la stabilité du système. Si vous faites en rm -rf /tant qu’utilisateur normal, votre système sera paralysé.
LawrenceC

Quelles applications peuvent cesser de fonctionner?
Vinnycx

En dehors de SSH? Quoi d'autre peut échouer? Je dois maintenant si je peux quitter le système de cette manière pendant un moment.
Vinnycx

5
@ Vinnycx: Non, vous ne pouvez pas. C'est cassé. Vous devriez en faire une priorité. Sinon, attendez-vous à ce que vos services vous échouent un à un et que les pirates informatiques mangent vos données. Quitter / * @ 777 n'est pas une option.
Caleb
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.