Gestion des accès et su/sudo

Tags: #<Tag:0x00007f993dcad068> #<Tag:0x00007f993dcaced8> #<Tag:0x00007f993dcacd48>

Bonjour,

juste parce que ça a été évoqué et qu’il y a peu de regroupement des fonctionnements, implémentations, organisation de la gestion des accès et donc de l’utilisation de su et sudo clairement regroupé, je créé ce fil de discussion pour regrouper les différentes possibilités et implications.

Les enjeux de ces accès peuvent être résumés (donc non exhaustifs) de la façon suivante:

  • Ne pas divulguer largement le mot de passe administrateur
  • Permettre de pouvoir réaliser des commandes d’administration sans connaître et/ou sans utiliser le compte root
  • Assurer la bonne administration d’une machine sans diluer le niveau de sécurité de la dite machine et incidemment de toute machine inclue dans le périmètre d’utilisation.

La solution la plus répandue consiste à utiliser sudo.
Cependant, un certain nombre de problématiques apparaissent avec cette utilisation souvent mal cadrée:

  • Sur certaines distribution, l’utilisation implicite de sudo à l’installation implique la non définition d’un mot de passe pour root. C’est une brèche de sécurité.
  • L’utilisation d’un groupe unique pour tous les utilisateurs concernés.
  • Une configuration qui implique la possibilité de l’utilisation de toutes les commandes d’administration possible, y compris celle permettant de changer le mot de passe root. C’est une brèche de sécurité.
  • Un risque de sécurité du fait de la différence de niveau de mot de passe entre un utilisateur et root (le mot de passe root étant globalement plus « fort » que celui d’un utilisateur). A quoi bon avoir une escalade de privilège si cette escalade est basée sur un niveau de sécurité inférieur au privilège voulu.
  • Dans un environnement avec de nombreux serveurs, les fichiers de configurations de sudo sont difficiles à maintenir.

Pour l’utilisation de su:

  • L’utilisation de su dans un environnement multi-utilisateur implique une dispersion du mot de passe root.
  • Par défaut aucune aucune définition de groupe pour son utilisation.
  • L’utilisation de la commande su n’est pas restreinte.

Il est à noter qu’il existe une troisième voie qui est l’utilisation de polkitd qui ne sera pas discutée ici mais qu’il est important de connaître. Il permet de s’affranchir de l’utilisation de su et sudo, bien que dans le principe, la réflexion soit la même.

Dans un environnement mono-utilisateur, l’utilisation de sudo ne s’impose pas. Cependant, avec un environnement multi-utilisateur il est nécessaire.

Mais il faudra prendre un certain nombre de décisions:

  • Il faut mettre en place une stratégie de définition des mot de passe exigeant des mots de passe forts avec un renouvellement obligatoire au bout de 30/60/90 jours par exemple.
  • Avoir une stratégie de groupe relatives aux typologies d’ utilisations
  • Aucune commande par défaut. Seule des commandes identifiées (même les paramètres de ces commandes devraient aussi être identifiées) doivent être définies.
  • Aucune définition de commandes/d’accès autrement que par l’utilisation de groupes; rien d’individuel.
  • Assurer une traçabilité complète de l’utilisation de sudo dans les logs.
  • S’assurer de l’utilisation de pty pour les commandes (valable pour un serveur sans GUI, mais peu adapté à un poste de travail par exemple.
  • S’assurer de la ré-authentification pour chaque augmentation de privilèges.
  • Mettre en place un timeout sur l’authentification (ne pas dépasser 15mn par exemple)

L’un des inconvénients majeur de l’utilisation de sudo est son manque de souplesse dans un environnement avec beaucoup de machines.
Chaque modification devra être reportée dans chaque fichier de configuration sur chaque machine.
Pour y palier il y a deux solutions principales:

  • Mettre en place une infrastructure de déploiement de ces modifications. Cela implique une nouvelle architecture dans le périmètre avec les implications de maintenances, de déploiements et de compétences.
  • Utiliser sudo-ldap. Cette solution a un avantage majeur qu’elle permet une utilisation dynamique de la configuration sudo. En effet, dans cette solution chaque commande sera vérifiée auprès d’un serveur LDAP. Toute modification dans le serveur LDAP sera ainsi prise en compte immédiatement (donc dynamiquement); alors que la solution par fichier de conf local implique de se déconnecter et se reconnecter pour prendre en compte les modifications.

Pour l’utilisation de su, il faudra là aussi s’assurer d’un certain nombre de points:

  • Imposer l’utilisation d’un groupe autorisé à utiliser la commande (au niveau de la configuration PAM).
  • Mettre en place un timeout sur la connexion
  • N’être utilisé que par des key-users identifiés.
  • Mettre en place autant que possible une traçabilité (utilisation de apparmor, auditd, aide)

Le fait est qu’il n’est pas ici question de su vs sudo, mais de su avec sudo et inversement. Les deux ont leur utilité. Les deux ont leurs cas d’utilisation spécifiques et parfois complémentaires.
Et enfin, comme cité précédemment, depuis quelques années, l’utilisation de polkitd est venu s’ajouter aux possibilités

je n’utilise pas sudo mais su.
je ne vois pas l’intérêt de faire avec un utilisateur de sécurité inférieurt ce que je peux faire avec root, étant dans un environnement où je suis le seul à utiliser la machine.
dans un environnement multi-utilisateur sudo a toute sa place. Si ce n’est qu’il devient totalement inutile si tout est permis sous prétexte que c’est sudo.

Donc ne t’en déplaise, travailler avec root via su garde toute sa place. Sans compte qu’il y a moyen de s’assurer que n’importe qui n’utilise pas su via l’utilisation d’une sécurisation par groupe dans la configuration PAM

je n’utilise pas sudo mais su.
je ne vois pas l’intérêt de faire avec un utilisateur de sécurité inférieurt ce que je peux faire avec root, étant dans un environnement où je suis le seul à utiliser la machine.
dans un environnement multi-utilisateur sudo a toute sa place. Si ce n’est qu’il devient totalement inutile si tout est permis sous prétexte que c’est sudo.
Donc ne t’en déplaise, travailler avec root via su garde toute sa place. Sans compte qu’il y a moyen de s’assurer que n’importe qui n’utilise pas su via l’utilisation d’une sécurisation par groupe dans la configuration PAM

Si vous ne voyez pas l’intérêt d’utiliser sudo alors que vous pouvez utiliser su, ce n’est pas vraiment mon problème.
Plutôt que faire un long discours puisque ce n’est pas le sujet du fil, voilà un petit lien https://debian-facile.org/doc:faq:differences-entre-su-et-sudo
Ce hors-sujet est clos pour moi.

Clair et ton lien est une opinion pas une argumentation, elle est d’ailleurs connue pour ça.
Dans les milieu de la sécurité l’avis est tout autre.

Hello @Zargos

2 petites remarques.

  • Dans ton texte tu parles d’environnement multi-utilisateurs, il me semble qu’il faudrait préciser que tout ou partie de ces utilisateurs ont accès à certains droits d’administration.

  • renouvellement obligatoire des mots de passe : je très mitigé sur le réel gain en sécurité d’une telle politique. Il me semble qu’il est préférable d’adapter ces durées au niveau d’attaques.

Il n’y a pas besoin de savoir combien nécessite de droits administrateurs, il suffit qu’il y en ait un parmi plusieurs ou plus, et qu’il puisse changer. C’est le contexte qui importe plus que le cas spécifique.

La durée doit effectivement être adaptée, mais le principe c’est qu’il y en ait une. Plus un mot de passe a une durée de vie longue plus il est susceptible d’être cassé, voir perdu. en fait, sur une politique de sécurité, la durée de vie limité d’un mot de passe n’est qu’un élément parmi d’autre. Il n’est pas absolu et suffisant. Mais il est nécessaire d’autant plus que l’environnement inclut de nombreux utilisateurs.

Sur les différents cas de défaillance de la sécurité que j’ai pu observé dans le cadre de les activités professionnelles, les mots de passe prenne tout de même une assez grande place.