Je comprends bien ce que vous dites, et contrairement à un système comme pledge, vous partez du principe qu'on ne touche pas à l'application mais on la contraint par une autre manière que la perte de privilèges volontaire indiquée dans le code. L'hypothèse de départ est différente, dans un cas on a le code de programmes dont on veut assurer encore plus la sécurité, de l'autre on part uniquement des binaires pour gérer la sécurité.
Et c'est exactement ce que je disais : deux approches. Et là où on peut accepter qu'un programme "s'initialise" puis lâche ses privilèges avec pledge, le même fonctionnement est impossible avec les privilèges Linux et on doit séparer le programme en deux pour le même résultat : le binaire conserve ses privilèges même lorsqu'il entre dans sa boucle de fonctionnement donc l'initialisation doit se faire ailleurs.
Donc on a des hypothèses de départ différentes :
avoir accès au code, pouvoir y ajouter une ligne pour limiter ses droits
ne pas avoir accès au code, ou ne pas vouloir y toucher (ni s'en préoccuper)
Un fonctionnement différent :
une ligne de code indiquant qu'on ne conserve qu'une partie de nos privilèges
des outils externes au programme qui vont donner des privilèges
Des fonctionnalités et contraintes différentes :
on peut avoir des droits au début pour l'initialisation puis y renoncer (fonctionnement normal de toutes les applications serveur), mais on doit toucher au code
on donne des privilèges à une application sans pouvoir lui en retirer une fois la phase d'initialisation terminée, mais on n'a pas besoin de connaître l'application, et on veut juste s'assurer qu'elle n'aille pas fouiller le système et lui interdire des appels systèmes
Mais un même but final : contraindre une application aux seuls privilèges dont elle a besoin. On pourrait donc discuter des usages possibles de chacune des approches, certes, mais l'objectif est quand même identique.
Par ailleurs, dans les deux cas il faut bien qu'on sache ce que l'application est sensée faire pour y attribuer les bons droits... donc le fait d'avoir ou pas à modifier le code (quand on parle seulement d'ajouter une ligne de code), n'est pas un argument qui pèse lourd. Cet argument vaut surtout pour les applications non libres, où on n'a pas du tout accès au code source, sinon ajouter une ligne de code me semble préférable à la complexité des capacités Linux. L'approche (caricaturée) ici est donc "on ne gère pas la sécurité en amont, les admin feront le job plus tard".
[^] # Re: Très intéressant, mais moins pratique que pledge
Posté par karchnu (site web personnel) . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 6. Dernière modification le 06 septembre 2018 à 16:05.
Je comprends bien ce que vous dites, et contrairement à un système comme
pledge, vous partez du principe qu'on ne touche pas à l'application mais on la contraint par une autre manière que la perte de privilèges volontaire indiquée dans le code. L'hypothèse de départ est différente, dans un cas on a le code de programmes dont on veut assurer encore plus la sécurité, de l'autre on part uniquement des binaires pour gérer la sécurité.Et c'est exactement ce que je disais : deux approches. Et là où on peut accepter qu'un programme "s'initialise" puis lâche ses privilèges avec pledge, le même fonctionnement est impossible avec les privilèges Linux et on doit séparer le programme en deux pour le même résultat : le binaire conserve ses privilèges même lorsqu'il entre dans sa boucle de fonctionnement donc l'initialisation doit se faire ailleurs.
Donc on a des hypothèses de départ différentes :
Un fonctionnement différent :
Des fonctionnalités et contraintes différentes :
Mais un même but final : contraindre une application aux seuls privilèges dont elle a besoin. On pourrait donc discuter des usages possibles de chacune des approches, certes, mais l'objectif est quand même identique.
Par ailleurs, dans les deux cas il faut bien qu'on sache ce que l'application est sensée faire pour y attribuer les bons droits... donc le fait d'avoir ou pas à modifier le code (quand on parle seulement d'ajouter une ligne de code), n'est pas un argument qui pèse lourd. Cet argument vaut surtout pour les applications non libres, où on n'a pas du tout accès au code source, sinon ajouter une ligne de code me semble préférable à la complexité des capacités Linux. L'approche (caricaturée) ici est donc "on ne gère pas la sécurité en amont, les admin feront le job plus tard".