on est d'accord, si tu es OK avec le fait d'obtenir ou donner les pleins pouvoirs, tu peux te contenter de su.
J'ai peut-être une déformation ou un biais à force de chercher à sécuriser les systèmes dont je suis responsable... Mais je vais donner d'autres arguments :
le partage de mot de passe rend la traçabilité très complexe. Une session locale ouverte par root ou admin ne permet pas de savoir qui l'a fait. En se logeant avec voltairine ou cg puis fait sudo systemctl stop syslog-ng, on sait qui a lancé la commande.
Si le mot de passe est partagé et qu'on souhaite révoquer l'accès à cg mais pas aux 5 autres utilisateurs, et bien il faut communiquer le mot de passe aux 5 autres, et ce de manière rapide et sécurisée.
sudo permet d'enregistrer toutes les commandes lancées et leur affichage (y compris pour un shell root), ce que su ne fait pas1.
`su' rend obligatoire de mettre un mot de passe au compte root si on veut obtenir un shell.
si l'accès est basé sur un mot de passe, alors un utilisateur peut bloquer les autres en le changeant.
surtout si on n'a pas besoin de ses spécificités (ce qui est généralement le cas)
Je me permet de faire comme toi : renversement de la charge de preuve 😉. Quel est ce "cas général" dans lequel un utilisateur peut passer root avec su, voire même connaître le mot de passe des autres comptes ?
Dans les environnements autres que mon ordi perso, sudo offre une granularité sans laquelle il est dangereux d'offrir plus que les permissions standard.
sudo a certainement des défauts (que doas n'a pas, que sudo-rs mitige, on peut aussi regardee polkit mais c'est encore un autre monde), en particulier, souvent que la config par défaut est laxiste. Mais en aucun cas ça ne plaide pour un mot de passe partagé ou un mécanisme "tout ou rien" comme su ou sudo bash. Quand tu veux centraliser des permissions complexes dans un LDAP ou en posant des fichiers de conf avec Puppet ou Ansible, avec sudo, tu peux. Avec su, aucune finesse possible.
Bref, je voulais mettre en lumière les avantages qu'offre sudo, parce que ça peut donner des idées et peut-être pouvoir se dire qu'en fait, ses spécificités, on en a besoin 😇.
on peut compenser avec auditd mais on aura les commandes, pas l'affichage. On a aussi pam_wheel qui permet de limiter les groupes qui ont accès à su, ce qui est un bon début. ↩
[^] # Re: Rust
Posté par cg . En réponse au lien Faille critique exploitée dans sudo. Évalué à 6.
Hello,
on est d'accord, si tu es OK avec le fait d'obtenir ou donner les pleins pouvoirs, tu peux te contenter de
su.J'ai peut-être une déformation ou un biais à force de chercher à sécuriser les systèmes dont je suis responsable... Mais je vais donner d'autres arguments :
sudo systemctl stop syslog-ng, on sait qui a lancé la commande.sudopermet d'enregistrer toutes les commandes lancées et leur affichage (y compris pour un shell root), ce quesune fait pas1 .Je me permet de faire comme toi : renversement de la charge de preuve 😉. Quel est ce "cas général" dans lequel un utilisateur peut passer root avec
su, voire même connaître le mot de passe des autres comptes ?Dans les environnements autres que mon ordi perso,
sudooffre une granularité sans laquelle il est dangereux d'offrir plus que les permissions standard.sudoa certainement des défauts (quedoasn'a pas, quesudo-rsmitige, on peut aussi regardeepolkitmais c'est encore un autre monde), en particulier, souvent que la config par défaut est laxiste. Mais en aucun cas ça ne plaide pour un mot de passe partagé ou un mécanisme "tout ou rien" commesuousudo bash. Quand tu veux centraliser des permissions complexes dans un LDAP ou en posant des fichiers de conf avec Puppet ou Ansible, avecsudo, tu peux. Avecsu, aucune finesse possible.Bref, je voulais mettre en lumière les avantages qu'offre
sudo, parce que ça peut donner des idées et peut-être pouvoir se dire qu'en fait, ses spécificités, on en a besoin 😇.on peut compenser avec
auditdmais on aura les commandes, pas l'affichage. On a aussipam_wheelqui permet de limiter les groupes qui ont accès à su, ce qui est un bon début. ↩