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