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, comme les autorisations susont -rwsr-xr-xprésentes, 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 noet PasswordAuthentication no, et aucun des autres utilisateurs n'a d'accès physique au serveur. Pour autant que je sache, le monde exécuter l'autorisation sur /usr/bin/suest 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 de courir sudirectement au lieu de devoir le 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 la permission sujuste 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' ilkkachu est que l'élévation à la racine n'est qu'une utilisation spécifique pour 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 supeut être utilisé pour supposer toute identité que le système local peut authentifier.

Par exemple, si je suis connecté en tant qu'utilisateur jimet que je souhaite enquêter sur un problème mikesignalé, mais que je ne parviens pas à reproduire, je peux essayer de me connecter en tant que mikeet d'exécuter 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)

L'utilisation de l' -loption de le sufait simuler une connexion complète (selon la manpage).

Ce qui précède nécessite cependant la connaissance du mikemot de passe de. Si j'ai sudoaccès, je peux me connecter comme mikemê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' suexécutable sont comme vous le montrez, c'est parce qu'il sus'agit d'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 faisiez partie d'un groupe appelé "roue" su. La version GNU de sune 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, comme les autorisations susont -rwsr-xr-xprésentes, rien 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.somodule 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, cela vous permet de vous élever à root, si vous connaissez le mot de passe.

Cela me permet de courir sudirectement au lieu de devoir le faire sudo su, mais ce n'est guère un inconvénient.

sudo suest 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 -iou sudo -s(ou sudo /bin/bashetc.) si vous souhaitez exécuter le shell.

Suis-je en train d'oublier quelque chose? Le monde exécute-t-il l'autorisation sur su juste pour des raisons historiques?

Voir au dessus. Eh bien, tous les systèmes n'ont pas sudod'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. Je pense que certains systèmes ont sumis en place de sorte que seuls les membres d'un groupe particulier (" wheel") peuvent l'exécuter. Vous pouvez faire de même sudosi 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, il soit sulivré avec le loginpaquet, ce n'est donc probablement pas une bonne idée de supprimer le paquet dans son ensemble. (Et l'appariement loginet suensemble 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 un peu de ceux-ci, mais passwdest setuid, et si vous voulez une haute sécurité, vous devez é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.

Les autres réponses sont correctes en disant "su" vous permet de vous connecter à des comptes autres que root.

Une remarque sur "sudo su" cependant. Cela vous permet en fait de vous connecter au compte root sans connaître le mot de passe root. Vous devez connaître le mot de passe du compte avec lequel vous exécutez sudo et avoir ce compte dans le fichier sudoers.