Fixer les bits setuid et setgid dans / usr?
J'ai fait quelque chose de stupide:
chown -R root:root /usr
chmod -R g-w /usr
Apparemment , la meilleure chose à faire est de réinstaller le système. Cependant, mon système fonctionne bien jusqu'à présent - y a-t-il quelque chose de immédiatement dangereux qui ne répare pas cela au plus vite? J'ai Ubuntu 18.04 (pas de connexion Internet), il est simplement utilisé comme NAS local.
La raison pour laquelle j'ai fait cela était due à un avertissement lors de la mise à jour:
WARN: uid is 0 but '/usr' is owned by 1000
WARN: /usr is group writable!
J'ai demandé et quelqu'un sur un forum a suggéré les commandes ci-dessus avec "c'est parfaitement sûr". Leçon apprise: Ne faites pas confiance aux internautes, même s'ils semblent totalement convaincus.
La raison, apparemment, pour laquelle /usr était un groupe accessible en écriture et n'appartenait pas à root, cela tient à mon propre DIY-Nas Ubuntu (Odroid):
drwxrwxr-x 10 odroid odroid 4096 Apr 12 2018 usr
J'aurais peut-être dû ne pas utiliser l'option récursive -R. Cela n'a pas d'importance maintenant.
Les dernières heures, j’ai parcouru divers postes pour découvrir ce que j’avais fait. Il semble que l'exécution de chown sur /usr rompt __ bits setuid et setgid; Pour correction de la commande Sudo , je l’avais déjà fait:
chown root:root /usr/bin/Sudo && chmod 4755 /usr/bin/Sudo
En plus de cela, je ne vois plus de problèmes. Lorsque je me connecte à l'interface Ubuntu, un logiciel Bluetooth avertit de son autorisation, mais ce n'est pas immédiatement pertinent. Je comprends qu’un logiciel de/usr comporte un groupe autre que root (voir liste ici , par exemple), pour des raisons de sécurité - mais y aura-t-il des effets réellement négatifs sur mon système de messagerie? système, en particulier en ce qui concerne la gestion de fichiers/archivage, par exemple fichiers corrompus ou inaccessibles?
Notez que j'ai créé un nouveau compte stackexchange parce que je suis trop gêné .. de toute façon, merci beaucoup pour vos suggestions!
Je pense que vous avez eu de la chance parce que vous venez de supprimer le bit "accessible en écriture" pour les groupes. Cela n'affectera pas les bits SETGID ou SETUID. S'ils ont été définis auparavant, ils le sont toujours. Par contre, la commande chmod -R 777 /usr réinitialise tous les bits en rwxtout en supprimant les autres bits en même temps, y compris les sname__. C'est pourquoi les personnes qui ont publié chmod -R 777 /usr sont généralement obligées de procéder à une réinstallation.
Peut-être que les observations que j'ai faites sur mon système peuvent vous aider. J'ai exécuté certaines commandes findpour voir quels fichiers et répertoires auraient été affectés par les commandes que vous avez émises. Voici les résultats:
# Find all files and directories NOT owned by user root:
find usr -not -user root -ls
3407926 52 -rwsr-sr-x 1 daemon daemon 51464 Feb 20 2018 usr/bin/at
# Find all files and directories NOT owned by group root:
find usr -not -group root -ls
3418319 4 drwxrwsr-x 3 root staff 4096 Jan 5 2018 usr/local/lib/python3.6
3418322 4 drwxrwsr-x 2 root staff 4096 Jan 5 2018 usr/local/lib/python3.6/dist-packages
3419229 4 drwxrwsr-x 4 root staff 4096 Nov 13 20:03 usr/local/lib/python2.7
3419230 4 drwxrwsr-x 2 root staff 4096 Jan 26 2018 usr/local/lib/python2.7/dist-packages
1049153 4 drwxrwsr-x 2 root staff 4096 Nov 13 20:03 usr/local/lib/python2.7/site-packages
3544477 4 drwxrwsr-x 2 root staff 4096 Jan 5 2018 usr/local/share/fonts
3418324 4 drwxrwsr-x 3 root staff 4096 Jan 5 2018 usr/local/share/emacs
3544479 4 drwxrwsr-x 2 root staff 4096 Jan 5 2018 usr/local/share/emacs/site-LISP
3416934 372 -rwsr-xr-- 1 root dip 378600 Jun 12 19:20 usr/sbin/pppd
3410196 40 -rwxr-sr-x 1 root mail 39000 Apr 3 2018 usr/sbin/ssmtp
3408208 12 -rwxr-sr-x 1 root utmp 10232 Mär 11 2016 usr/lib/x86_64-linux-gnu/utempter/utempter
3419827 12 -rwxr-sr-x 1 root tty 10232 Aug 4 2017 usr/lib/mc/cons.saver
3428536 16 -rwxr-sr-x 1 root mail 14336 Jul 31 16:14 usr/lib/evolution/camel-lock-helper-1.2
3416858 44 -rwsr-xr-- 1 root messagebus 42992 Nov 15 2017 usr/lib/dbus-1.0/dbus-daemon-launch-helper
1183416 4 drwxrwsr-t 2 root lpadmin 4096 Nov 8 2017 usr/share/ppd/custom
3410118 44 -rwxr-sr-x 1 root mlocate 43088 Mär 1 2018 usr/bin/mlocate
3408029 16 -rwxr-sr-x 1 root tty 14328 Jan 17 2018 usr/bin/bsd-write
3414379 356 -rwxr-sr-x 1 root ssh 362640 Nov 5 12:51 usr/bin/ssh-agent
3410676 32 -rwxr-sr-x 1 root tty 30800 Jul 26 18:20 usr/bin/wall
3409008 72 -rwxr-sr-x 1 root shadow 71816 Jan 25 2018 usr/bin/chage
3416771 24 -rwxr-sr-x 1 root shadow 22808 Jan 25 2018 usr/bin/expiry
3407926 52 -rwsr-sr-x 1 daemon daemon 51464 Feb 20 2018 usr/bin/at
3409356 40 -rwxr-sr-x 1 root crontab 39352 Nov 16 2017 usr/bin/crontab
# find objects that have the group-writable bit set and are owned by user=root but group!=root:
find usr -perm -0020 -user root -not -group root -ls
3418319 4 drwxrwsr-x 3 root staff 4096 Jan 5 2018 usr/local/lib/python3.6
3418322 4 drwxrwsr-x 2 root staff 4096 Jan 5 2018 usr/local/lib/python3.6/dist-packages
3419229 4 drwxrwsr-x 4 root staff 4096 Nov 13 20:03 usr/local/lib/python2.7
3419230 4 drwxrwsr-x 2 root staff 4096 Jan 26 2018 usr/local/lib/python2.7/dist-packages
1049153 4 drwxrwsr-x 2 root staff 4096 Nov 13 20:03 usr/local/lib/python2.7/site-packages
3544477 4 drwxrwsr-x 2 root staff 4096 Jan 5 2018 usr/local/share/fonts
3418324 4 drwxrwsr-x 3 root staff 4096 Jan 5 2018 usr/local/share/emacs
3544479 4 drwxrwsr-x 2 root staff 4096 Jan 5 2018 usr/local/share/emacs/site-LISP
1183416 4 drwxrwsr-t 2 root lpadmin 4096 Nov 8 2017 usr/share/ppd/custom
Bien sûr, votre kilométrage peut varier ont varié mais je suis convaincu que vous n'avez "cassé" qu'une poignée de fichiers. La grande majorité des objets situés sous /usr appartiennent à root:root et ont généralement soit rwxrwxr-x ou rwxr-xr-x. La suppression du bit g-w ne nuit pas vraiment car elle supprime le bit enregistrable pour le groupe rootmais (du moins sur mon système standard), le seul membre de ce groupe est l'utilisateur rootet il dispose d'un accès en écriture via les autorisations de l'utilisateur ( que vous n'avez pas changé) et n'a pas vraiment besoin d'un accès en écriture via l'appartenance à un groupe.
Btw, mon /usr lui-même a les attributs suivants:
drwxr-xr-x 10 root root 4096 Jan 5 2018 usr/
Mettre à jour
Le PO mentionne qu'il a fait face à l'erreur
Sudo: /usr/bin/Sudo must be owned by uid 0 and have the setuid bit set
après avoir émis chmod g-w et chown root:root et dû le réparer avec chmod 4755 /usr/bin/Sudo. Il s'avère que le chown g-w ne modifie PAS le bit setuid , mais le chown root:root l'a fait. Il efface apparemment ces bits SETUID (et vraisemblablement aussi les bits SETGID et STICKY). Pour moi, c'est un comportement inattendu, mais je suis presque sûr qu'il y a une explication et/ou une raison. Toutefois. J'ai exécuté une autre commande findpour voir lequel de mes fichiers ci-dessous /usr contient un ou plusieurs bits parmi SETUID, SETGID et STICKY bits:
find usr -perm /7000 -printf '%M\t%u:%g\t%p\n'
drwxrwsr-x root:staff usr/local/lib/python3.6
drwxrwsr-x root:staff usr/local/lib/python3.6/dist-packages
drwxrwsr-x root:staff usr/local/lib/python2.7
drwxrwsr-x root:staff usr/local/lib/python2.7/dist-packages
drwxrwsr-x root:staff usr/local/lib/python2.7/site-packages
drwxrwsr-x root:staff usr/local/share/fonts
drwxrwsr-x root:staff usr/local/share/emacs
drwxrwsr-x root:staff usr/local/share/emacs/site-LISP
-rwsr-xr-- root:dip usr/sbin/pppd
-rwxr-sr-x root:mail usr/sbin/ssmtp
-rwxr-sr-x root:utmp usr/lib/x86_64-linux-gnu/utempter/utempter
-rwsr-sr-x root:root usr/lib/xorg/Xorg.wrap
-rwxr-sr-x root:tty usr/lib/mc/cons.saver
-rwsr-sr-x root:root usr/lib/snapd/snap-confine
-rwxr-sr-x root:mail usr/lib/evolution/camel-lock-helper-1.2
-rwsr-xr-- root:messagebus usr/lib/dbus-1.0/dbus-daemon-launch-helper
-rwsr-xr-x root:root usr/lib/openssh/ssh-keysign
-rwsr-xr-x root:root usr/lib/policykit-1/polkit-agent-helper-1
-rwsr-xr-x root:root usr/lib/eject/dmcrypt-get-device
drwxrwsr-t root:lpadmin usr/share/ppd/custom
-rwxr-sr-x root:mlocate usr/bin/mlocate
-rwxr-sr-x root:tty usr/bin/bsd-write
-rwsr-xr-x root:root usr/bin/traceroute6.iputils
-rwsr-xr-x root:root usr/bin/gpasswd
-rwxr-sr-x root:ssh usr/bin/ssh-agent
-rwsr-xr-x root:root usr/bin/passwd
-rwsr-xr-x root:root usr/bin/pkexec
-rwsr-xr-x root:root usr/bin/Sudo
-rwxr-sr-x root:tty usr/bin/wall
-rwsr-xr-x root:root usr/bin/chfn
-rwxr-sr-x root:shadow usr/bin/chage
-rwsr-xr-x root:root usr/bin/arping
-rwxr-sr-x root:shadow usr/bin/expiry
-rwsr-sr-x daemon:daemon usr/bin/at
-rwxr-sr-x root:crontab usr/bin/crontab
-rwsr-xr-x root:root usr/bin/chsh
-rwsr-xr-x root:root usr/bin/newgrp
Cette liste n'est pas très longue, mais elle contient encore des fichiers que je considère cruciaux. Surtout ceux du dernier tiers, tels que passwdname__, crontabname__, etc., et bien sûr Sudoname__.
Je pense que la réponse ci-dessus de @PerlDuck explique les choses les plus cruciales. Après avoir examiné chaque fichier manuellement, je pense avoir supprimé le plus gros désordre. Si cet ordinateur avait été exposé à Internet, je l’aurais tout de suite réinstallé - j’ai maintenant un peu plus de temps.
Quoi qu'il en soit, je souhaite ajouter un lien vers une liste complète des autorisations par défaut de Linux ici: https://www.vidarholen.net/contents/junk/ubuntu_permissions.html Cela m'a également aidé à restaurer un certain nombre de autorisations de fichiers supplémentaires.