PolicyKit reconnaît le fait que le système Unix habituel ne permet pas d'appliquer efficacement le Principle of Least Privilege, et ça fait un point commun avec Capsicum.
Il est plus orienté vers un accès à des droits supplémentaires pour un utilisateur, le genre de chose qui demanderait des droits root d'habitude. Capsicum peut faire ça, mais il est aussi (surtout ?) pensé pour restreindre les droits utilisateurs au strict minimum. C'est faisable avec le modèle PolyciKit, en partant d'un utilisateur anonyme sans droit qui dialogue par PolicyKit pour obtenir plus de droits, mais c'est sans doute pas vraiment prévu pour en l'état donc moins pratique. Plus généralement, Capsicum permet de limiter facilement les droits existant au strict minimum, alors que PolicyKit décrit seulement comment obtenir plus de droits (ce que Capsicum permet aussi).
Au niveau du fonctionnement, PolicyKit n'est pas un nouveau modèle d'accès, implémenté au niveau du noyau ou de bibliothèques de base. C'est seulement un serveur de messages qui est pensé pour faire dialoguer des applications sans droits et des applications avec droit, pour demander aux applications avec droits de faire des choses pour les sans droits (ce qui revient à leur "prêter" ponctuellement ce droit). C'est donc plutôt une question d'organisation du transfert de droit, qu'un choix technique sur le mécanisme de droit d'accès. Dans un système à capacités, il faudra aussi de tels mécanismes d'organisation, et les solutions retenues habituellement utilisent, comme PolicyKit, le passage de messages. Par exemple, la situation du dialogue de choix d'un fichier décrite dans la news est typique d'un dialogue entre un programme sans droits (Sur le système de fichier) et un utilitaire système privilégié (le programme de choix de fichier), qui fonctionne par passage de message.
Par contre, au-delà de l'aspect 'passage de message', la façon dont PolicyKit et les systèmes de capacités représentent les droits est très différente. PolycyKit utilise un système tout à fait classique de style "matrice d'accès" : on dit "je suis le SUjet, je veux faire telle Action sur tel Objet", et Polycikit autorise ou non. La programmation de système utilisant Policykit se fait donc en se posant des questions comme "qui a le droit d'accéder à tel Objet ?", "Quelles sont les Actions que l'on autorise pour tel Sujet" ? En particulier la gestion des sujets est assez grossière, c'est essentiellement l'utilisateur au sens des systèmes Unix, on pourrait faire plus fin (par exemple on peut temporairement utiliser un processus donné à faire une action donnée en envoyant à un système privilégié un message du style "maintenant si on te demande l'autorisation pour le pid truc, tu acceptes", et en changeant d'avis au bout d'un moment) mais ce serait, dans la plupart des cas, galère à programmer.
Avec les systèmes à capacités, le point de vue sur la gestion des droits est fondamentalement différent. Les droits et les actions sont couplés, et les processus se les passent entre eux selon le besoin, sans passer par un "système de droit" intermédiaire. On se demande donc "de quel droit tel processus/programme/système/utilisateur va-t-il avoir besoin ?", on les lui donne, et après c'est à lui de les répartir avec les autres processus avec qui il est en contact. La gestion des droits est donc naturellement plus fine et plus dynamique, mais aussi moins structurée (d'est ensuite aux applications d'utiliser des patterns de transfert de droits qui suivent une politique haut-niveau donnée). La question de "tel Sujet a-t-il le droit d'utiliser cette Capacité/Action ?" n'a pas de sens : soit il possède la capacité et alors il lui suffit de l'activer pour effectuer l'action, soit il ne la possède pas et il ne peut même pas essayer.
[^] # Re: Et Policykit là-dedans
Posté par gasche . En réponse à la dépêche Capsicum, une séparation fine des privilèges pour UNIX. Évalué à 3.
PolicyKit reconnaît le fait que le système Unix habituel ne permet pas d'appliquer efficacement le Principle of Least Privilege, et ça fait un point commun avec Capsicum.
Il est plus orienté vers un accès à des droits supplémentaires pour un utilisateur, le genre de chose qui demanderait des droits
rootd'habitude. Capsicum peut faire ça, mais il est aussi (surtout ?) pensé pour restreindre les droits utilisateurs au strict minimum. C'est faisable avec le modèle PolyciKit, en partant d'un utilisateur anonyme sans droit qui dialogue par PolicyKit pour obtenir plus de droits, mais c'est sans doute pas vraiment prévu pour en l'état donc moins pratique. Plus généralement, Capsicum permet de limiter facilement les droits existant au strict minimum, alors que PolicyKit décrit seulement comment obtenir plus de droits (ce que Capsicum permet aussi).Au niveau du fonctionnement, PolicyKit n'est pas un nouveau modèle d'accès, implémenté au niveau du noyau ou de bibliothèques de base. C'est seulement un serveur de messages qui est pensé pour faire dialoguer des applications sans droits et des applications avec droit, pour demander aux applications avec droits de faire des choses pour les sans droits (ce qui revient à leur "prêter" ponctuellement ce droit). C'est donc plutôt une question d'organisation du transfert de droit, qu'un choix technique sur le mécanisme de droit d'accès. Dans un système à capacités, il faudra aussi de tels mécanismes d'organisation, et les solutions retenues habituellement utilisent, comme PolicyKit, le passage de messages. Par exemple, la situation du dialogue de choix d'un fichier décrite dans la news est typique d'un dialogue entre un programme sans droits (Sur le système de fichier) et un utilitaire système privilégié (le programme de choix de fichier), qui fonctionne par passage de message.
Par contre, au-delà de l'aspect 'passage de message', la façon dont PolicyKit et les systèmes de capacités représentent les droits est très différente. PolycyKit utilise un système tout à fait classique de style "matrice d'accès" : on dit "je suis le SUjet, je veux faire telle Action sur tel Objet", et Polycikit autorise ou non. La programmation de système utilisant Policykit se fait donc en se posant des questions comme "qui a le droit d'accéder à tel Objet ?", "Quelles sont les Actions que l'on autorise pour tel Sujet" ? En particulier la gestion des sujets est assez grossière, c'est essentiellement l'utilisateur au sens des systèmes Unix, on pourrait faire plus fin (par exemple on peut temporairement utiliser un processus donné à faire une action donnée en envoyant à un système privilégié un message du style "maintenant si on te demande l'autorisation pour le pid truc, tu acceptes", et en changeant d'avis au bout d'un moment) mais ce serait, dans la plupart des cas, galère à programmer.
Avec les systèmes à capacités, le point de vue sur la gestion des droits est fondamentalement différent. Les droits et les actions sont couplés, et les processus se les passent entre eux selon le besoin, sans passer par un "système de droit" intermédiaire. On se demande donc "de quel droit tel processus/programme/système/utilisateur va-t-il avoir besoin ?", on les lui donne, et après c'est à lui de les répartir avec les autres processus avec qui il est en contact. La gestion des droits est donc naturellement plus fine et plus dynamique, mais aussi moins structurée (d'est ensuite aux applications d'utiliser des patterns de transfert de droits qui suivent une politique haut-niveau donnée). La question de "tel Sujet a-t-il le droit d'utiliser cette Capacité/Action ?" n'a pas de sens : soit il possède la capacité et alors il lui suffit de l'activer pour effectuer l'action, soit il ne la possède pas et il ne peut même pas essayer.