Je suis d'accord avec toi sur le fait que le compromis, où une passe de "une capacité = une action" à 60 masques a augmenté la complexité. Mais en même temps, c'est assez naturel : il s'agit de coller à la programmation système UNIX et ce n'est pas de la nouvelle complexité qui est ajoutée, c'est la complexité existante avec laquelle on s'interface.
Tu as l'air de trouver que 60 masques c'est trop, mais sur cette page je vois 131 codes de retour d'erreur sur une distribution GNU/Linux classiques. Donc c'est bien l'ordre de grandeur de la complexité gérée aujourd'hui par les programmeurs systèmes.
Enfin, je t'invite à regarder la liste des capabilités présente dans la manpage de cap_new, sur la page du projet Capsicum. Elle colle essentiellement exactement au nom des appels systèmes tolérés par le système : tu veux appeler getsockname ? Il faut que le masque CAP_GETSOCKNAME soit mis. La plupart des masques de capacité ont ainsi une lecture directe, et c'est donc une forme de complexité où "tu paies à l'usage" : soit tu connais l'appel système correspondant et tu l'utilises dans ton programme, et alors oui tu dois te soucier de ce masque, soit tu n'en as jamais entendu parler et tu n'as pas besoin de t'en servir. Je ne pense pas que la complexité ajoutée soit donc si énorme.
De toute façon les responsables du projet Capsicum ne prétendent pas avoir inventé la recette miracle. Ce sont les premiers à reconnaître (dans un des messages de la mailing-list que j'ai mis en lien) qu'il reste des améliorations à faire sur la "programmabilité", le fait de rendre agréable à utiliser pour les programmeurs cette finesse de gestion des droits. Mais je pense (et clairement eux aussi) que ça reste une avancée intéressante dans le domaine, qui a des avantages que les solutions existantes n'ont pas su réunir.
Personne ne prétend que faire du logiciel parfaitement sûr est exactement aussi facile que faire du logiciel sans se soucier de la sécurité. Dans un système à autorité ambiante on n'a pas besoin de se préoccuper des droits, ils sont là quand on en a besoin. Dans un système qui essaie de respecter le Principle Of Last Privilege, cette gestion des droits est rendue explicite. Une personne qui ignorait totalement les problématiques avant va donc trouver qu'il doit s'occuper de plus de choses. Par contre, une personne qui avait déjà mené une réflexion sur la compartementalisation1 pourra au contraire s'appuyer sur des outils pour la rendre plus concrète et en vérifier directement l'efficacité.
1: je rappelle que la compartementalisation des logiciels ne sert pas que pour la sécurité, mais aussi pour la modularité, la maintenabilité, la fiabilité, etc. Par exemple, les gens qui mettent en avant les architectures avec micro-noyaux ne s'intéressent pas en premier à la sécurité en général. De même la raison de séparer les pages dans Chrome vient plus de considérations de fiabilité. Faire ce raisonnement plus fin, que ce soit au départ pour des raisons de sécurité ou pas, a donc des avantages dans de nombreux domaines.
Même une fois qu'on utilise des capacités, la finesse de la gestion des droits peut être décidée progressivement. En fait en général on ne respecte jamais absolument le Principle of Least Authority : on approxime (supérieurement, sinon ça ne marche pas) les droits nécessaires. On peut commencer par faire une approximation grossière, ce qui donne des bénéfices de sécurité moins importants, mais demande moins d'effort pour le programmeur. Selon le degré de criticité du logiciel ou de motivation des programmeurs, on peut ensuite affiner en considérant plus précisément le comportement et le besoin en autorité des différentes parties du programme et de ses sous-programmes. Ce n'est pas un choix binaire, tu es libre de décider la quantité d'effort que tu investis selon tes priorités. Mais ça ne veut pas dire qu'il faut rien faire; justement, avec peu d'efforts on peut obtenir un bénéfice important (passer de "rien" à "un truc grossier mais raisonnable").
[^] # Re: Trop complexe
Posté par gasche . En réponse à la dépêche Capsicum, une séparation fine des privilèges pour UNIX. Évalué à 10.
Je suis d'accord avec toi sur le fait que le compromis, où une passe de "une capacité = une action" à 60 masques a augmenté la complexité. Mais en même temps, c'est assez naturel : il s'agit de coller à la programmation système UNIX et ce n'est pas de la nouvelle complexité qui est ajoutée, c'est la complexité existante avec laquelle on s'interface.
Tu as l'air de trouver que 60 masques c'est trop, mais sur cette page je vois 131 codes de retour d'erreur sur une distribution GNU/Linux classiques. Donc c'est bien l'ordre de grandeur de la complexité gérée aujourd'hui par les programmeurs systèmes.
Enfin, je t'invite à regarder la liste des capabilités présente dans la manpage de
cap_new, sur la page du projet Capsicum. Elle colle essentiellement exactement au nom des appels systèmes tolérés par le système : tu veux appelergetsockname? Il faut que le masqueCAP_GETSOCKNAMEsoit mis. La plupart des masques de capacité ont ainsi une lecture directe, et c'est donc une forme de complexité où "tu paies à l'usage" : soit tu connais l'appel système correspondant et tu l'utilises dans ton programme, et alors oui tu dois te soucier de ce masque, soit tu n'en as jamais entendu parler et tu n'as pas besoin de t'en servir. Je ne pense pas que la complexité ajoutée soit donc si énorme.De toute façon les responsables du projet Capsicum ne prétendent pas avoir inventé la recette miracle. Ce sont les premiers à reconnaître (dans un des messages de la mailing-list que j'ai mis en lien) qu'il reste des améliorations à faire sur la "programmabilité", le fait de rendre agréable à utiliser pour les programmeurs cette finesse de gestion des droits. Mais je pense (et clairement eux aussi) que ça reste une avancée intéressante dans le domaine, qui a des avantages que les solutions existantes n'ont pas su réunir.
Personne ne prétend que faire du logiciel parfaitement sûr est exactement aussi facile que faire du logiciel sans se soucier de la sécurité. Dans un système à autorité ambiante on n'a pas besoin de se préoccuper des droits, ils sont là quand on en a besoin. Dans un système qui essaie de respecter le Principle Of Last Privilege, cette gestion des droits est rendue explicite. Une personne qui ignorait totalement les problématiques avant va donc trouver qu'il doit s'occuper de plus de choses. Par contre, une personne qui avait déjà mené une réflexion sur la compartementalisation1 pourra au contraire s'appuyer sur des outils pour la rendre plus concrète et en vérifier directement l'efficacité.
1: je rappelle que la compartementalisation des logiciels ne sert pas que pour la sécurité, mais aussi pour la modularité, la maintenabilité, la fiabilité, etc. Par exemple, les gens qui mettent en avant les architectures avec micro-noyaux ne s'intéressent pas en premier à la sécurité en général. De même la raison de séparer les pages dans Chrome vient plus de considérations de fiabilité. Faire ce raisonnement plus fin, que ce soit au départ pour des raisons de sécurité ou pas, a donc des avantages dans de nombreux domaines.
Même une fois qu'on utilise des capacités, la finesse de la gestion des droits peut être décidée progressivement. En fait en général on ne respecte jamais absolument le Principle of Least Authority : on approxime (supérieurement, sinon ça ne marche pas) les droits nécessaires. On peut commencer par faire une approximation grossière, ce qui donne des bénéfices de sécurité moins importants, mais demande moins d'effort pour le programmeur. Selon le degré de criticité du logiciel ou de motivation des programmeurs, on peut ensuite affiner en considérant plus précisément le comportement et le besoin en autorité des différentes parties du programme et de ses sous-programmes. Ce n'est pas un choix binaire, tu es libre de décider la quantité d'effort que tu investis selon tes priorités. Mais ça ne veut pas dire qu'il faut rien faire; justement, avec peu d'efforts on peut obtenir un bénéfice important (passer de "rien" à "un truc grossier mais raisonnable").