snap m'a permis d'avoir une version de LXD plus réçente que celle dans les repos ubuntu par défaut 3.18 vs 3.03. Je suis un adepte des dernières version de paquets ;)
Mais effectivement, pour ce tuto, ça n'a que peu d'importance !
Je suis conscient de tout ça. Peut-être aurais-je dû insister un peu plus sur le fait que je vise le confort. Je ne fais pas de concurrence à Dehydrated, car ce dernier remplace Certbot. Alors que tout ce que je veux, c'est utiliser Certbot en fournissant en tout et pour tout deux options (sans compter –help) : –test pour tester et –cert pour générer/renouveler les certificats. Certbot et Dehydrated ont tous les deux une myriade d'options. Mon script s'adresse à tous ceux qui n'ont juste pas envie de se prendre la tête avec ça.
Comme souvent je comprends pas pourquoi tout le monde persiste à utiliser Certbot.
L'outil est clairement mal foutu, super lourd et a une légère tendance à faire pleins de trucs dans ton dos au point de parvenir à se coincer pour n'importe quoi.
L'outil est tellement mal foutu qu'on en vient à developper des scripts de surcouche pour le rendre passablement utilisable.
Il existe des dizaines d'alternatives largement meilleures et ce dans un peu tous les langages possibles.
Ce script en vient à reproduire à peu près dehydrated tout en s'appuyant sur une base fragile…
Je m'en vais de ce pas fourrer ça sous le nez des nerds genre “Ouais mais Firefox c'est un truc de vieux et puis c'est dépassé et y'a mieux que ça gna gna gna”.
Je l'utilise depuis qu'il s'appelait successivement Firebird et Phoenix (2003 ou 2004 si mon souvenir est bon), et je ne veux rien d'autre sur ma bécane.
Sans compter que par principe, le processus 1 (init) doit être ultra protégé et qu'un plantage de ce processus provoque l'effondrement de tout le système. Idéalement, c'est du KISS. Et enfin le non respect des principes fondamentaux d'Unix (un outils, une tâche) ne sont pas de bon augure non plus.
Pour les applications métiers je comprends, c'est d'ailleurs ce qu'on fait, chaque applications à son propre utilisateur, et son lancer par un script init perso, donc chaque opérateur à le droit de lancer sudo -u UserAppli pour lancer les taches de maintenance de cette appli. Après de mon cotés, aucun outils n'est exécuter en local sur les machines, les utilisateurs n'ont que des IHM. Les devs n'ont par contre en aucun cas accès au machine, les environnements sont généré à la volée via jenkins.
Par exemple dans ma boite on compte plus de 500 informaticiens (tout métier confondu), dont environs 100 pour la gestion de l'infrastructure (15 techniciens d'exploitation/supervision présent H24, 7/7j, une 20ène d'admin et ingé, les intégrateurs, les analystes etc …), chacun doit être capable à n'importe qu'elle moment de pouvoir redémarrer un serveur, ou simplement un service système ou une application, pas le choix d'avoir un accès “root” pour redémarrer sshd par exemple.
Franchement j'aimerai me passer de sudo, mais franchement je ne vois pas comment faire pour que si user1 lance un script d'init d'un service, ce script se lance avec les permissions de userX.
A part utiliser que des comptes génériques ou technique où on partage les mdps, on a essayé, jusqu'a ce qu'un petit malin décide de changer des mdps sans prévenir personnes.
Tu viens de démontrer la supériorité des scripts init. Chez nous Systemd n'est pas du tout le bienvenu. En plus ce truc est une faille de sécurité à lui tout seul. Les évaluations en termes de sécurité et qualité de code des travaux de Lennart Poetering sont assez catastrophique…
Nos outils disposent des permissions nécessaire pour être utilisés. S'il le faut nos scripts init peuvent appartenir au groupe qui pourra les manipuler (c'est ultra rare par ailleurs, ils peuvent faire une quantité astronomique de choses en espace utilisateur). Les rares qui veulent être admin de leur machine sont dans un réseau à part (bac à sable). On peut aussi jouer avec des outils comme Policykit mais dans notre cas ça n'a jamais été nécessaire. Et bien évidemment personne à part les deux ASR habilité n'a de mot de passe root, jamais.
Alors, oui, il arrive que parfois un utilisateur viennent nous voir pour nous demander de faire un truc qu'il ne peut pas faire sans être root, mais c'est notre boulot et au passage ça nous permet d'évaluer la pertinence de la demande et de la valider ou la rejeter (et proposer une alternative). Quoi qu'il en soit, nous n'avons jamais trouvé de bonne raison ou de cas ou l'usage de sudo serait nécessaire.
Je ne vois pas comment tu peux faire de l'administration système grâce au ACLs, à part en jouant avec le SUID et GUID, ce qui reste pire que sudo, tu augmentes grandement la surface d'attaque. Car dans ce cas ça veut dire que les administrateurs et techniciens ont des comptes avec des permissions élevés, sous Unix, un utilisateur doit être un simple utilisateur, et demander des permissions élevés temporairement (via compte root ou sudo). D'ailleurs ça m'agace de voir des connexions root sur les serveurs.
De plus avec les ACLs, tu peux seulement limiter l'accès (rwx) sur un fichier, par exemple tu ne peux pas dire qu'un utilisateur ne peux utiliser que l'argument status de systemctl, mais seulement l'autoriser à utiliser systemctl ou non.
Non, ce ne sont quand même pas de bonne pratique, j'insiste. Les groupes et les ACLs c'est fait pour ça, et ça fonctionne très bien. Dans mon labo de recherche on fonctionne comme ça et tout le monde peut bosser sans aucun problème, y compris des développeurs ou des gens qui conçoivent des outils de mesure et les trucs qui vont avec (et qui finiront dans des satellites). Vu le fric que ça coute je t'assure qu'ont ne fait pas d'économie sur les tests.
Après c'est sur c'est moins pratique et il faut bosser, mais notre niveau et exigence forcément très élevé de sécurité n'est pas compromis par ce genre d'outil, ce qui dans notre cas n'est pas négociable.
ça reste mieux que de donner les mots de passe des utilisateurs spécifique à plusieurs personnes, ou pire l'utilisateur root.
En serveur perso ou tu es tout seul dessus, pas de soucis, mais en entreprise, quand tu dois avoir 50 personnes qui sont susceptible de devoir faire des actions, y'a rien de mieux que sudo (ou doas pour openBSD), par exemple quand tu as un services de supervision en 24/7, c'est bien qu'ils puissent être autonome dans la relance de service, sans pour autant leur donner les droits full root pour le faire.
Jamais rencontré en entreprise non plus, je n'en ai pas écumé des centaines cela dit mais s'amuser à donner tous les droit sauf root à un utilisateur est de toute façon une mauvais pratique. Un responsable DSI sérieux ne laisserait jamais faire ça.
Mais autrement, totalement d'accord avec ton commentaire.
Et quelle est la regex pour repérer les commentaires à propos de l'écriture inclusive ?
Je propose de ne pas faire les choses à moitié en utilisant carrément les regex pour l'écriture inclusive. Bisous d'un dévelop' peureux. :o)
Merci pour l'info :) Ubuntu n'est en effet pas terrible si on veut dans les dépôts les derniers paquets :)
Bonjour Adrien_D,
snap m'a permis d'avoir une version de LXD plus réçente que celle dans les repos ubuntu par défaut 3.18 vs 3.03. Je suis un adepte des dernières version de paquets ;)
Mais effectivement, pour ce tuto, ça n'a que peu d'importance !
Pourquoi l'installation de LXD via snap et pas apt ?
Je suis conscient de tout ça. Peut-être aurais-je dû insister un peu plus sur le fait que je vise le confort. Je ne fais pas de concurrence à Dehydrated, car ce dernier remplace Certbot. Alors que tout ce que je veux, c'est utiliser Certbot en fournissant en tout et pour tout deux options (sans compter –help) : –test pour tester et –cert pour générer/renouveler les certificats. Certbot et Dehydrated ont tous les deux une myriade d'options. Mon script s'adresse à tous ceux qui n'ont juste pas envie de se prendre la tête avec ça.
Comme souvent je comprends pas pourquoi tout le monde persiste à utiliser Certbot. L'outil est clairement mal foutu, super lourd et a une légère tendance à faire pleins de trucs dans ton dos au point de parvenir à se coincer pour n'importe quoi. L'outil est tellement mal foutu qu'on en vient à developper des scripts de surcouche pour le rendre passablement utilisable.
Il existe des dizaines d'alternatives largement meilleures et ce dans un peu tous les langages possibles.
Ce script en vient à reproduire à peu près dehydrated tout en s'appuyant sur une base fragile…
Si vous avez d'autres échantillons de ces emails, n’hésitez pas à nous les faire suivre…
Je m'en vais de ce pas fourrer ça sous le nez des nerds genre “Ouais mais Firefox c'est un truc de vieux et puis c'est dépassé et y'a mieux que ça gna gna gna”.
Je l'utilise depuis qu'il s'appelait successivement Firebird et Phoenix (2003 ou 2004 si mon souvenir est bon), et je ne veux rien d'autre sur ma bécane.
Ou pas…
C'est le résultat d'une étude interne qui a simplement consisté en la lecture de quelque fichiers pris au hasard dans différents de ses projets. Ensuite il y a les fréquentes alertes de sécurité à propos de Systemd (mais aussi PulseAudio et d'autre trucs, internet t'en dira long), au hasard : * https://www.itprotoday.com/linux/linuxs-systemd-hit-three-security-holes * https://news.slashdot.org/story/18/10/27/196227/new-systemd-vulnerability-discovered
À noter qu'à l'inverse je n'ai jamais entendu parler de graves failles de sécurité dans SystemV init ou BSD init.
Il y a aussi les pétages de câbles légendaires de Linus Tovald sur le comportement de Poettering et de certains de ses développeurs. Par exemple, je ne ferait jamais confiance en des devs qui se comportent comme ça (et je comprend parfaitement la position de Torvalds) : * https://news.ycombinator.com/item?id=19023232 * https://www.phoronix.com/scan.php?page=news_item&px=mty1mza
Sans compter que par principe, le processus 1 (init) doit être ultra protégé et qu'un plantage de ce processus provoque l'effondrement de tout le système. Idéalement, c'est du KISS. Et enfin le non respect des principes fondamentaux d'Unix (un outils, une tâche) ne sont pas de bon augure non plus.
Tu aurais une source à ce sujet stp ? Ca m'intéresserait.
Pour les applications métiers je comprends, c'est d'ailleurs ce qu'on fait, chaque applications à son propre utilisateur, et son lancer par un script init perso, donc chaque opérateur à le droit de lancer
sudo -u UserApplipour lancer les taches de maintenance de cette appli. Après de mon cotés, aucun outils n'est exécuter en local sur les machines, les utilisateurs n'ont que des IHM. Les devs n'ont par contre en aucun cas accès au machine, les environnements sont généré à la volée via jenkins.Par exemple dans ma boite on compte plus de 500 informaticiens (tout métier confondu), dont environs 100 pour la gestion de l'infrastructure (15 techniciens d'exploitation/supervision présent H24, 7/7j, une 20ène d'admin et ingé, les intégrateurs, les analystes etc …), chacun doit être capable à n'importe qu'elle moment de pouvoir redémarrer un serveur, ou simplement un service système ou une application, pas le choix d'avoir un accès “root” pour redémarrer sshd par exemple.
Franchement j'aimerai me passer de
sudo, mais franchement je ne vois pas comment faire pour que si user1 lance un script d'init d'un service, ce script se lance avec les permissions de userX.A part utiliser que des comptes génériques ou technique où on partage les mdps, on a essayé, jusqu'a ce qu'un petit malin décide de changer des mdps sans prévenir personnes.
Tu viens de démontrer la supériorité des scripts init. Chez nous Systemd n'est pas du tout le bienvenu. En plus ce truc est une faille de sécurité à lui tout seul. Les évaluations en termes de sécurité et qualité de code des travaux de Lennart Poetering sont assez catastrophique…
Nos outils disposent des permissions nécessaire pour être utilisés. S'il le faut nos scripts init peuvent appartenir au groupe qui pourra les manipuler (c'est ultra rare par ailleurs, ils peuvent faire une quantité astronomique de choses en espace utilisateur). Les rares qui veulent être admin de leur machine sont dans un réseau à part (bac à sable). On peut aussi jouer avec des outils comme Policykit mais dans notre cas ça n'a jamais été nécessaire. Et bien évidemment personne à part les deux ASR habilité n'a de mot de passe root, jamais.
Alors, oui, il arrive que parfois un utilisateur viennent nous voir pour nous demander de faire un truc qu'il ne peut pas faire sans être root, mais c'est notre boulot et au passage ça nous permet d'évaluer la pertinence de la demande et de la valider ou la rejeter (et proposer une alternative). Quoi qu'il en soit, nous n'avons jamais trouvé de bonne raison ou de cas ou l'usage de sudo serait nécessaire.
Je ne vois pas comment tu peux faire de l'administration système grâce au ACLs, à part en jouant avec le SUID et GUID, ce qui reste pire que sudo, tu augmentes grandement la surface d'attaque. Car dans ce cas ça veut dire que les administrateurs et techniciens ont des comptes avec des permissions élevés, sous Unix, un utilisateur doit être un simple utilisateur, et demander des permissions élevés temporairement (via compte root ou sudo). D'ailleurs ça m'agace de voir des connexions root sur les serveurs.
De plus avec les ACLs, tu peux seulement limiter l'accès (rwx) sur un fichier, par exemple tu ne peux pas dire qu'un utilisateur ne peux utiliser que l'argument
statusdesystemctl, mais seulement l'autoriser à utilisersystemctlou non.Non, ce ne sont quand même pas de bonne pratique, j'insiste. Les groupes et les ACLs c'est fait pour ça, et ça fonctionne très bien. Dans mon labo de recherche on fonctionne comme ça et tout le monde peut bosser sans aucun problème, y compris des développeurs ou des gens qui conçoivent des outils de mesure et les trucs qui vont avec (et qui finiront dans des satellites). Vu le fric que ça coute je t'assure qu'ont ne fait pas d'économie sur les tests.
Après c'est sur c'est moins pratique et il faut bosser, mais notre niveau et exigence forcément très élevé de sécurité n'est pas compromis par ce genre d'outil, ce qui dans notre cas n'est pas négociable.
ça reste mieux que de donner les mots de passe des utilisateurs spécifique à plusieurs personnes, ou pire l'utilisateur root. En serveur perso ou tu es tout seul dessus, pas de soucis, mais en entreprise, quand tu dois avoir 50 personnes qui sont susceptible de devoir faire des actions, y'a rien de mieux que sudo (ou doas pour openBSD), par exemple quand tu as un services de supervision en 24/7, c'est bien qu'ils puissent être autonome dans la relance de service, sans pour autant leur donner les droits full root pour le faire.
Pour moi c'est simplement installer sudo qui est une mauvaise pratique…
Jamais rencontré en entreprise non plus, je n'en ai pas écumé des centaines cela dit mais s'amuser à donner tous les droit sauf root à un utilisateur est de toute façon une mauvais pratique. Un responsable DSI sérieux ne laisserait jamais faire ça.
Mais autrement, totalement d'accord avec ton commentaire.
Quand je dis par défaut, pas out of box, mais je l'ai souvent rencontré en entreprise, car plus simple niveau configuration.
La configuration par défaut est par contre une faille en elle même, donner tout les droits à un utilisateur, ce n'est pas secure.
Autre que pour le nom de la machine, et dans le cas d'une infra mono-serveur, mono-utilisateur, le terme ALL ne devrait jamais être utilisé