Je viens de voir votre readme. La seule chose que je peux vous dire, c'est que vous vous embêtez vraiment beaucoup à définir des rôles, utiliser les capacités Linux, et tout un tas de choses compliquées pour au final remplacer pledge et doas. Tout votre exemple sur le script python autorisé à démarrer à partir de l'utilisateur awazan de lancer son serveur sur le port 80 revient à autoriser une personne à lancer une application avec certains paramètres, et c'est pratiquement tout. Donc vous demandez aux administrateurs de créer des fichiers XML pour décrire des rôles qui auront des droits, des utilisateurs qui pourront avoir ces rôles et les applications qu'ils pourront lancer avec en plus les paramètres autorisés.
permit nopass awazan as root cmd python /usr/local/Users/awazan/server.py -p 80
Et voilà... alors certes, vous pouvez toujours trouver des arguments un peu pointus pour montrer que cela n'est pas 100% équivalent, mais on en est vraiment pas loin, tout en ayant une bien moins grande complexité et donc en ayant bien plus de chances d'être effectivement intégré sur de vrais systèmes en production (ce qui est le cas pour tous les systèmes OpenBSD depuis plusieurs années maintenant).
Le second exemple que vous donnez implique de ne pas pouvoir faire du LD_PRELOAD, ce qui est déjà pris en compte par mon exemple de fichier doas, tout simplement parce qu'on doit préciser explicitement via keepenv si nous souhaitons garder les variables d'environnement de l'utilisateur au lancement de la commande. C'est un fonctionnement par défaut qui me paraît complètement raisonnable, et sûr par défaut.
Votre troisième exemple indique qu'il faut actuellement utiliser des commandes compliquées pour injecter des capacités dans le binaire des applications, puis ces privilèges sont supprimés dès que le binaire change, et donc votre solution apporte une certaine stabilité. Oui, comme doas.
Du coup, même en ayant creusé votre proposition, je ne peux que vous encourager à regarder ce qui est fait côté OpenBSD. C'est de loin pour moi un exemple du meilleur de ce qui se fait dans le domaine.
PS: j'ai l'impression que votre travail est lié à une publication scientifique. Je suis sincèrement désolé de voir à quel point vous avez travaillé pour arriver au final à moins bien que ce qui est déjà fait. Certes, c'est externe à l'environnement Linux, mais vous auriez sans doute pu vous en inspirer... bref. Je compatis. Moi aussi je suis dans le domaine et je ne fais pas toujours des articles intéressants. Courage pour la suite.
[^] # 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 07 septembre 2018 à 01:58.
Je viens de voir votre readme. La seule chose que je peux vous dire, c'est que vous vous embêtez vraiment beaucoup à définir des rôles, utiliser les capacités Linux, et tout un tas de choses compliquées pour au final remplacer
pledgeetdoas. Tout votre exemple sur le script python autorisé à démarrer à partir de l'utilisateur awazan de lancer son serveur sur le port 80 revient à autoriser une personne à lancer une application avec certains paramètres, et c'est pratiquement tout. Donc vous demandez aux administrateurs de créer des fichiers XML pour décrire des rôles qui auront des droits, des utilisateurs qui pourront avoir ces rôles et les applications qu'ils pourront lancer avec en plus les paramètres autorisés.Voici le même exemple avec
pldege(voir pledge(2)) etdoas(voir doas.conf(5)) :Dans le fichier
/etc/doas.conf:Et voilà... alors certes, vous pouvez toujours trouver des arguments un peu pointus pour montrer que cela n'est pas 100% équivalent, mais on en est vraiment pas loin, tout en ayant une bien moins grande complexité et donc en ayant bien plus de chances d'être effectivement intégré sur de vrais systèmes en production (ce qui est le cas pour tous les systèmes OpenBSD depuis plusieurs années maintenant).
Le second exemple que vous donnez implique de ne pas pouvoir faire du LD_PRELOAD, ce qui est déjà pris en compte par mon exemple de fichier
doas, tout simplement parce qu'on doit préciser explicitement viakeepenvsi nous souhaitons garder les variables d'environnement de l'utilisateur au lancement de la commande. C'est un fonctionnement par défaut qui me paraît complètement raisonnable, et sûr par défaut.Votre troisième exemple indique qu'il faut actuellement utiliser des commandes compliquées pour injecter des capacités dans le binaire des applications, puis ces privilèges sont supprimés dès que le binaire change, et donc votre solution apporte une certaine stabilité. Oui, comme
doas.Du coup, même en ayant creusé votre proposition, je ne peux que vous encourager à regarder ce qui est fait côté OpenBSD. C'est de loin pour moi un exemple du meilleur de ce qui se fait dans le domaine.
PS: j'ai l'impression que votre travail est lié à une publication scientifique. Je suis sincèrement désolé de voir à quel point vous avez travaillé pour arriver au final à moins bien que ce qui est déjà fait. Certes, c'est externe à l'environnement Linux, mais vous auriez sans doute pu vous en inspirer... bref. Je compatis. Moi aussi je suis dans le domaine et je ne fais pas toujours des articles intéressants. Courage pour la suite.