On en a déjà parlé, il n'y a pas de différence fondamentale entre télécharger puis exécuter et télécharger et exécuter en même temps, que ce soit un script shell ou un paquet seul de ton gestionnaire préféré.
Soit tu fait confiance à ce que tu télécharge parce que ta confiance au dépôt que ce soit ta distribution ou autre, soit tu crois que relire est un audit suffisant (lol), soit tu execute dans un endroit démilitarisé (un conteneur si tu pense que ça suffit ou une vm).
L'énorme majorité des gens font le premier que ce soit avec un curl | sh ou un .deb a télécharger.
Le problème de ce focaliser sur curl c'est que c'est une facilité qui donne à croire qu'il y a plus de sécurité si tu télécharge un rpm ou un tar.gz.
La question de la sécurité est importante et ne peux pas se résumer à "lol curl | sh ça pu".
Pour ce cas précis, il y a une différence : le premier installeur de Rust télécharge un second script, en fonction de la machine cible, mais ne fait pas de contrôle du téléchargement.
Le seul élément de contrôle est que le téléchargement se fait en https, donc risque faible de modif en cours de transfert.
Comme tu le dis, un gestionnaire de paquet type apt vérifie les signatures des dépôts, des listes de paquets, et des téléchargements. C'est tellement robuste que les téléchargements des paquets peuvent se faire en http. C'est très différent d'un wrapper qui télécharge un second wrapper sans le vérifier, mine de rien.
Passer par son gestionnaire de paquets, c'est se garantir qu'un travail de contrôle a été fait, que ce que tu récupères est bien ce que tu crois, et que le logiciel s'intègre bien avec l'ensemble du système.
La question de la confiance reste entière, on est d'accord :).
Non passer par les dépôts de ta distribution. Tu peux utiliser ton gestionnaire de paquet avec un paquet trouvé sur internet comme pour Google Chrome et tu n'a aucune validation en plus et il ajoute son propre dépôt.
Le problème ce n'est pas curl + sh, le problème c'est la confiance au fournisseur.
La confiance, je l'ai validée par l'expérience de ma distribution.
Si je dois rajouter une source de confiance supplémentaire, c'est un affaiblissement.
Attention, je suis bien content de pouvoir le faire (coucou l'interdiction du side-loading), mais ça ne devrait pas être la norme.
D'ailleurs, Debian (unstable) possède un paquet rust bien à jour, plus besoin de rustup. J'imagine que Fedora c'est pareil. Chez Ubuntu, c'est en 1.75 pour la version 24.04, ce qui est « pas mal ».
Le .deb (ou le .rpm) peut être signé numériquement. Si c'est le cas ET que la clé est déjà connue ou obtenue depuis un moyen sûr, alors c'est mieux qu'un script shell non signé plus facile à modifier.
Ça ne change pas grand chose si personne ne vérifie la signature ou que la clé de signature est définie/contrôlée par l'attaquant.
mais dans le temps on avait des utilitaires avec des suid de groupes.
Sous mandrake/mandriva/mageia, il y'avait consoleHelper qui gérait ça; où on pouvait définir les droits par utilisateurs.
Et de toutes façon, le plus souvent dans les droits admins des utilisateurs, on autorise l'installation de packages, qui de toutes façons est une autoroot :)
L'autre fréquemment utilisée est l’exécution de docker, qui est du même acabit.
J'ai aussi eu le droit à un alternatives qui permettait de passer root via les bons choix de commandes.
mais sinon je ne vois pas trop la différence avec l'existant (sudo, dzdo), sachant que sudo peut fonctionner par groupes, quel est l’intérêt de rajouter encore autre chose?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
mais sinon je ne vois pas trop la différence avec l'existant (sudo, dzdo), sachant que sudo peut fonctionner par groupes, quel est l’intérêt de rajouter encore autre chose?
C'est vachement bien comme outil, j'en ai rêvé par moments. Pouvoir attribuer des pouvoirs sur des opérations spécifiques et pas du tout ou rien (root/pas root), changer d'identité ou de groupe mais dans un contexte précis… C'est vraiment cool.
Tu as Polkit aujourd'hui, qui permet de donner des droits différents selon les actions dans un logiciel (je crois que gparted s'en sert, par exemple), qui tu es, et comment tu t'es logé sur la machine. Je pense que c'est le successeur de consoleHelper.
L'autre approche, adoptée par Wireshark, est de séparer les actions privilégiées dans un binaire setgid, comme tu l'expliques.
D'ailleurs la doc de Polkit dit "si vous pouvez faire un setuid/setgid, allez-y c'est plus simple :).
Enfin, on peut citer les capabilities, qui permettent de donner accès à certaines actions sur certains binaires de manière très granulaires (genre autoriser rsync à changer la date d'un fichier qui ne t'appartient pas).
# Le paradoxe de la sécurité
Posté par Glandos . Évalué à 10 (+11/-0).
Et quelques lignes plus bas :
Alors dans le script shell, ça ne fait pas de sudo, c'est très dommage, ça empêche d'être encore plus ironique, mais c'est quand même mieux comme ça.
[^] # Re: Le paradoxe de la sécurité
Posté par barmic 🦦 . Évalué à 2 (+1/-1).
On en a déjà parlé, il n'y a pas de différence fondamentale entre télécharger puis exécuter et télécharger et exécuter en même temps, que ce soit un script shell ou un paquet seul de ton gestionnaire préféré.
Soit tu fait confiance à ce que tu télécharge parce que ta confiance au dépôt que ce soit ta distribution ou autre, soit tu crois que relire est un audit suffisant (lol), soit tu execute dans un endroit démilitarisé (un conteneur si tu pense que ça suffit ou une vm).
L'énorme majorité des gens font le premier que ce soit avec un
curl | shou un.deba télécharger.Le problème de ce focaliser sur curl c'est que c'est une facilité qui donne à croire qu'il y a plus de sécurité si tu télécharge un rpm ou un tar.gz.
La question de la sécurité est importante et ne peux pas se résumer à "lol curl | sh ça pu".
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Le paradoxe de la sécurité
Posté par cg . Évalué à 4 (+2/-0).
Pour ce cas précis, il y a une différence : le premier installeur de Rust télécharge un second script, en fonction de la machine cible, mais ne fait pas de contrôle du téléchargement.
Le seul élément de contrôle est que le téléchargement se fait en https, donc risque faible de modif en cours de transfert.
Comme tu le dis, un gestionnaire de paquet type
aptvérifie les signatures des dépôts, des listes de paquets, et des téléchargements. C'est tellement robuste que les téléchargements des paquets peuvent se faire en http. C'est très différent d'un wrapper qui télécharge un second wrapper sans le vérifier, mine de rien.Passer par son gestionnaire de paquets, c'est se garantir qu'un travail de contrôle a été fait, que ce que tu récupères est bien ce que tu crois, et que le logiciel s'intègre bien avec l'ensemble du système.
La question de la confiance reste entière, on est d'accord :).
[^] # Re: Le paradoxe de la sécurité
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Non passer par les dépôts de ta distribution. Tu peux utiliser ton gestionnaire de paquet avec un paquet trouvé sur internet comme pour Google Chrome et tu n'a aucune validation en plus et il ajoute son propre dépôt.
Le problème ce n'est pas curl + sh, le problème c'est la confiance au fournisseur.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Le paradoxe de la sécurité
Posté par cg . Évalué à 2 (+0/-0).
Oui, tout à fait, c'est ce que je voulais dire. Merci de la précision.
[^] # Re: Le paradoxe de la sécurité
Posté par Glandos . Évalué à 3 (+1/-0).
La confiance, je l'ai validée par l'expérience de ma distribution.
Si je dois rajouter une source de confiance supplémentaire, c'est un affaiblissement.
Attention, je suis bien content de pouvoir le faire (coucou l'interdiction du side-loading), mais ça ne devrait pas être la norme.
D'ailleurs, Debian (unstable) possède un paquet rust bien à jour, plus besoin de rustup. J'imagine que Fedora c'est pareil. Chez Ubuntu, c'est en 1.75 pour la version 24.04, ce qui est « pas mal ».
[^] # Re: Le paradoxe de la sécurité
Posté par Benoît Sibaud (site web personnel) . Évalué à 4 (+1/-0).
Le .deb (ou le .rpm) peut être signé numériquement. Si c'est le cas ET que la clé est déjà connue ou obtenue depuis un moyen sûr, alors c'est mieux qu'un script shell non signé plus facile à modifier.
Ça ne change pas grand chose si personne ne vérifie la signature ou que la clé de signature est définie/contrôlée par l'attaquant.
# je vais faire mon vieux con
Posté par fearan . Évalué à 5 (+2/-0).
mais dans le temps on avait des utilitaires avec des suid de groupes.
Sous mandrake/mandriva/mageia, il y'avait consoleHelper qui gérait ça; où on pouvait définir les droits par utilisateurs.
Et de toutes façon, le plus souvent dans les droits admins des utilisateurs, on autorise l'installation de packages, qui de toutes façons est une autoroot :)
L'autre fréquemment utilisée est l’exécution de docker, qui est du même acabit.
J'ai aussi eu le droit à un alternatives qui permettait de passer root via les bons choix de commandes.
mais sinon je ne vois pas trop la différence avec l'existant (sudo, dzdo), sachant que sudo peut fonctionner par groupes, quel est l’intérêt de rajouter encore autre chose?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: je vais faire mon vieux con
Posté par Pol' uX (site web personnel) . Évalué à 3 (+1/-0).
Je crois qu'il y a une tentative d'explication ici : https://github.com/LeChatP/RootAsRole#why-do-you-need-this-tool-
Adhérer à l'April, ça vous tente ?
[^] # Re: je vais faire mon vieux con
Posté par cg . Évalué à 2 (+0/-0).
C'est vachement bien comme outil, j'en ai rêvé par moments. Pouvoir attribuer des pouvoirs sur des opérations spécifiques et pas du tout ou rien (root/pas root), changer d'identité ou de groupe mais dans un contexte précis… C'est vraiment cool.
Faut que j'essaye ça !
[^] # Re: je vais faire mon vieux con
Posté par cg . Évalué à 4 (+2/-0).
Tu as Polkit aujourd'hui, qui permet de donner des droits différents selon les actions dans un logiciel (je crois que gparted s'en sert, par exemple), qui tu es, et comment tu t'es logé sur la machine. Je pense que c'est le successeur de consoleHelper.
L'autre approche, adoptée par Wireshark, est de séparer les actions privilégiées dans un binaire setgid, comme tu l'expliques.
D'ailleurs la doc de Polkit dit "si vous pouvez faire un setuid/setgid, allez-y c'est plus simple :).
Enfin, on peut citer les capabilities, qui permettent de donner accès à certaines actions sur certains binaires de manière très granulaires (genre autoriser rsync à changer la date d'un fichier qui ne t'appartient pas).
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.