Pourquoi su world est-il exécutable?
J'ai un serveur sans tête qui est connecté à distance par plusieurs utilisateurs. Aucun des autres utilisateurs ne se trouve dans le fichier sudoers, ils ne peuvent donc pas obtenir root via Sudo. Cependant, étant donné que les autorisations sur su sont -rwsr-xr-x rien ne les empêche de tenter de forcer brutalement le mot de passe root.
On pourrait faire valoir que si un utilisateur connaît le mot de passe root, il peut de toute façon compromettre le système, mais je ne pense pas que ce soit le cas. OpenSSH est configuré avec PermitRootLogin no et PasswordAuthentication no, et aucun des autres utilisateurs n'a d'accès physique au serveur. Autant que je sache, le monde exécute l'autorisation sur /usr/bin/su est la seule avenue pour les utilisateurs qui tentent de se rooter sur mon serveur.
Ce qui me laisse encore plus perplexe en ce qu'il ne semble même pas utile. Cela me permet d'exécuter su directement au lieu de devoir faire Sudo su, mais ce n'est guère un inconvénient.
Suis-je en train d'oublier quelque chose? Le monde exécute-t-il l'autorisation sur su juste pour des raisons historiques? Y a-t-il des inconvénients à supprimer cette autorisation que je n'ai pas encore rencontrée?
Un point qui manque dans la réponse d'ilkkach est que l'élévation à la racine n'est qu'une utilisation spécifique de su. L'objectif général de su est d'ouvrir un nouveau Shell sous le compte de connexion d'un autre utilisateur. Cet autre utilisateur pourrait être root (et peut-être le plus souvent), mais su peut être utilisé pour supposer any identité que le système local peut authentifier.
Par exemple, si je suis connecté en tant qu'utilisateur jim et que je souhaite rechercher un problème signalé par mike mais que je ne parviens pas à reproduire, je peux essayer de me connecter en tant que mike, et en exécutant la commande qui lui pose problème.
13:27:20 /home/jim> su -l mike
Password:(I type mike's password (or have him type it) and press Enter)
13:27:22 /home/mike> id
uid=1004(mike) gid=1004(mike) groups=1004(mike)
13:27:25 /home/mike> exit # this leaves mike's login Shell and returns to jim's
13:27:29 /home/jim> id
uid=1001(jim) gid=1001(jim) groups=1001(jim),0(wheel),5(operator),14(ftp),920(vboxusers)
En utilisant le -l l'option de su lui fait simuler une connexion complète (par la page man).
Cependant, ce qui précède nécessite la connaissance du mot de passe de mike. Si j'ai accès à Sudo, je peux me connecter en tant que mike même sans son mot de passe.
13:27:37 /home/jim> Sudo su -l mike
Password:(I type my own password, because this is Sudo asking)
13:27:41 /home/mike>
En résumé, la raison pour laquelle les autorisations sur l'exécutable su sont comme vous le montrez, parce que su est un outil à usage général qui est disponible pour tous les utilisateurs du système.
Historiquement (sur les unités non GNU), ce n'était pas le cas, ou du moins il vérifiait manuellement si vous étiez dans un groupe appelé "roue" autorisé à su. La version GNU de su ne reproduisait pas cette fonctionnalité à cause de l'idéologie de RMS sur le contrôle d'accès à l'époque:
Why GNU `su' does not support the `wheel' group
===============================================
(This section is by Richard Stallman.)
Sometimes a few of the users try to hold total power over all the
rest. For example, in 1984, a few users at the MIT AI lab decided to
seize power by changing the operator password on the Twenex system and
keeping it secret from everyone else. (I was able to thwart this coup
and give power back to the users by patching the kernel, but I wouldn't
know how to do that in Unix.)
However, occasionally the rulers do tell someone. Under the usual
`su' mechanism, once someone learns the root password who sympathizes
with the ordinary users, he or she can tell the rest. The "wheel
group" feature would make this impossible, and thus cement the power of
the rulers.
I'm on the side of the masses, not that of the rulers. If you are
used to supporting the bosses and sysadmins in whatever they do, you
might find this idea strange at first.
Vous pouvez trouver beaucoup plus sur la question en Googling "Wheel Group RMS" ou similaire.
Cependant, étant donné que les autorisations sur
susont-rwsr-xr-xrien ne les empêche de tenter de forcer brutalement le mot de passe root.
Oui. En supposant que votre système Linux habituel, le pam_unix.so le module retarde une tentative d'authentification échouée de ~ deux secondes, mais je ne pense pas qu'il y ait quoi que ce soit pour arrêter les tentatives simultanées.
Les tentatives échouées sont bien sûr enregistrées:
Aug 16 22:52:33 somehost su[17387]: FAILED su for root by ilkkachu
Le forçage brutal d'un mot de passe devrait apparaître en bonne place dans les journaux, si vous avez un type de système pour les surveiller. Et si vous avez des utilisateurs locaux non fiables, vous devriez peut-être le faire. Les utilisateurs locaux non fiables peuvent également tenter d'utiliser des exploits d'escalade de privilèges uniquement locaux, et ils sont beaucoup plus courants que l'escalade de privilèges à distance.
Ce qui me laisse encore plus perplexe en ce qu'il ne semble même pas utile.
Bien sûr, c'est utile, il vous permet de vous élever à root, si vous connaissez le mot de passe.
Cela me permet d'exécuter
sudirectement au lieu de devoir faireSudo su, mais ce n'est guère un inconvénient.
Sudo su est quelque peu redondant. Il n'est pas nécessaire d'utiliser deux programmes destinés à vous permettre d'exécuter des programmes en tant qu'autre utilisateur, un suffit. Utilisez simplement Sudo -i ou Sudo -s (ou Sudo /bin/bash etc.) si vous souhaitez exécuter Shell.
Suis-je en train d'oublier quelque chose? Le monde exécute-t-il la permission sur su juste pour des raisons historiques?
Voir au dessus. Eh bien, tous les systèmes n'ont pas Sudo comme alternative, je ne sais pas si vous considérez cela comme historique.
Y a-t-il des inconvénients à supprimer cette autorisation que je n'ai pas encore rencontrée?
Pas vraiment, non pour autant que je sache. I pensez certains systèmes ont su défini de sorte que seuls les membres d'un groupe particulier ("wheel") peuvent l'exécuter. Vous pouvez faire de même pour Sudo si vous le souhaitez (chown root.sudousers /usr/bin/Sudo && chmod 4710 /usr/bin/Sudo).
Ou vous pouvez simplement supprimer l'un ou les deux programmes si vous n'en avez pas besoin. Bien que sur Debian, su soit livré avec le paquet login, il n'est donc probablement pas judicieux de supprimer le paquet dans son ensemble. (Et l'association de login et su comme ça semble quelque peu historique.)
Vous avez déjà de bonnes réponses, mais il n'y a pas une partie de votre message qu'elles ne traitent.
Pour autant que je sache, le monde exécuter l'autorisation sur/usr/bin/su est la seule avenue pour les utilisateurs qui tentent de se rooter sur mon serveur.
C'est une hypothèse dangereuse. Si vous avez défini un bon mot de passe pour root, dans la plupart des cas, il est beaucoup plus probable qu'une escalade de privilèges réussie soit due à l'exploitation d'un bogue dans le noyau ou d'un binaire setuid (vous pouvez bien sûr également supprimer le setuid peu de ceux-ci, mais passwd est setuid, et si vous voulez une haute sécurité, vous devriez également offrir cela à vos utilisateurs, et leur refuser l'option de changer leur mot de passe n'est pas compatible avec cela).
su doit être exécutable dans le monde entier pour que tout le monde puisse l'exécuter. Dans de nombreux systèmes, il peut être utilisé pour passer à un autre utilisateur, en fournissant son mot de passe.
Si vous êtes préoccupé par le fait que quelqu'un applique brutalement le mot de passe root, vous pouvez simplement le désactiver. (rendre le hachage invalide pour qu'aucun mot de passe donné ne puisse le correspondre)
Je ne connais pas le consensus, mais j'envisagerais de pouvoir me connecter en tant que root directement un problème de sécurité en soi.