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

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?

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.

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.

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

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.