J'avoue que pour une appli simple comme tcpdump, j'arrive à imaginer la chose, et le code que tu montres semble plutôt clair; maintenant sur un programme comme chromium, qui doit toucher des fichiers un peu partout, utiliser les interfaces réseau, lancer des processus, je pense que ça doit poser tout un tas d'autres soucis.
C'est vrai, mais en pratique le besoin de compartementalisation a été pris en compte dès la conception de chromium, et l'intégration de Capsicum s'en est retrouvée d'autant facilitée. L'article de Capsicum détaille un peu plus les modifications apportées à chromium; en substance, ils ont ajouté 100 lignes de lc_limitfd, comme les 6 que j'ai montrées pour tcpdump, et remplacé un morceau de leur impl. Linux par un morceau de leur impl OSX qui se prêtait mieux aux capacités sur ce point précis.
Leur comparaison aux autres méthodes de sandboxing utilisées pour Chromium est assez positive (bon après, évidemment, ce sont les auteurs de Capsicum, donc ce n'est pas une évaluation indépendante):
d'après eux, mettre en place une sandbox sous Windows c'est assez galère, et ils se sont retrouvé à tout interdire ou presque, mais communiquer avec un process non sandboxé chargé d'implémenter lui-même le contrôle d'accès désiré. Plus de 22 000 lignes de code au total
un peu le même problème (en moins pire) avec seccomp : plus de 11 000 lignes de code au total
pour les deux approches MAC (Seatbelt de Mac OSX et SELinux), ils se plaignent d'un manque de flexibilité, d'une gestion de droits au final moins fine qu'avec Capsicum (par design pour Seatbelt, et par difficulté pour SELinux), et surtout d'un manque de flexibilité dynamique : les politiques d'accès doivent être fixées avant le lancement du programme et ne peuvent pas évoluer dynamiquement, contrairement à la gestion des droits dans un système à capacité.
J'ai une question: d'où viennent les 10% de pertes de performances?
Est-ce qu'à chaque appel système la capacité du processus est checkée?
Oui, chaque appel système est affecté par le mode capacité. Les coûts sont variés et très détaillé dans l'article, que je t'incite à regarder si tu veux plus de détail : il y a des micro-benchmarks des principaux appels systèmes concernés, et des tests plus réalistes sur les programmes entiers (gzip). Le nombre de 10% que j'ai donné est le surcoût sur l'appel système fstat (il fallait bien choisir quelque chose pour donner un ordre d'idée...).
Dans le cas de gzip, le coût de capsicum ajoute seulement un surcoût constant, puisque le gros de l'application est de la compression qui se fait sans utilisation de droits particuliers. Avec l'implémentation actuelle ils ont mesuré un surcoût de 2.37 millisecondes, ce qui est non-négligeable (par rapport au temps total de gzip) pour de petites entrées. Pour des entrées de taille 512K, cela représente 5% du temps de calcul (dans leurs tests), et ensuite cela devient vite négligeable.
Les auteurs précisent qu'ils comptent travailler à optimiser un peu leur code. J'imagine qu'ils ont commencé par obtenir une version fonctionnellement satisfaisante au début, sans mettre l'accent sur les performances, et qu'il y a une marge de progrès à faire. Mais dans tous les cas, ce genre de vérifications supplémentaires aura toujours un coût; c'est au développeur de faire un compromis, selon la nature de son application, ses besoins en sécurité et en performance.
Si jamais un troublion décide de changer tous les appels vers cette librairie [..] on perd tout l'avantage de la solution.
Si un attaquant modifie un exécutable qui est lancé avec les droits utilisateurs (que l'exécutable ait prévu au départ d'utiliser capsicum ou pas), effectivement il peut faire ce qu'il veut dans les limites des droits de l'utilisateur. Capsicum ne change quelque chose que pour les processus qui tournent avec le 'capability flag', c'est à dire après l'appel de cap_enter, ou encore les processus fils lancés par des processus sous cap_enter.
En gros, si tu appelles un programme "foo" modifié par l'attaquant depuis ton shell, il peut faire un peu ce qu'il veut; par contre si un programme "bar" géré par capsicum appelle "foo", il sera restreint aux droits qu'à "bar". C'est justement l'intérêt du Principle of Least Authority: si les droits de "bar" sont minimaux, l'attaquant (ou simplement tout problème lié à un bug non intentionnel) est très limité.
[^] # Re: Wow
Posté par gasche . En réponse à la dépêche Capsicum, une séparation fine des privilèges pour UNIX. Évalué à 10.
C'est vrai, mais en pratique le besoin de compartementalisation a été pris en compte dès la conception de chromium, et l'intégration de Capsicum s'en est retrouvée d'autant facilitée. L'article de Capsicum détaille un peu plus les modifications apportées à chromium; en substance, ils ont ajouté 100 lignes de
lc_limitfd, comme les 6 que j'ai montrées pourtcpdump, et remplacé un morceau de leur impl. Linux par un morceau de leur impl OSX qui se prêtait mieux aux capacités sur ce point précis.Leur comparaison aux autres méthodes de sandboxing utilisées pour Chromium est assez positive (bon après, évidemment, ce sont les auteurs de Capsicum, donc ce n'est pas une évaluation indépendante):
d'après eux, mettre en place une sandbox sous Windows c'est assez galère, et ils se sont retrouvé à tout interdire ou presque, mais communiquer avec un process non sandboxé chargé d'implémenter lui-même le contrôle d'accès désiré. Plus de 22 000 lignes de code au total
un peu le même problème (en moins pire) avec
seccomp: plus de 11 000 lignes de code au totalpour les deux approches MAC (Seatbelt de Mac OSX et SELinux), ils se plaignent d'un manque de flexibilité, d'une gestion de droits au final moins fine qu'avec Capsicum (par design pour Seatbelt, et par difficulté pour SELinux), et surtout d'un manque de flexibilité dynamique : les politiques d'accès doivent être fixées avant le lancement du programme et ne peuvent pas évoluer dynamiquement, contrairement à la gestion des droits dans un système à capacité.
Oui, chaque appel système est affecté par le mode capacité. Les coûts sont variés et très détaillé dans l'article, que je t'incite à regarder si tu veux plus de détail : il y a des micro-benchmarks des principaux appels systèmes concernés, et des tests plus réalistes sur les programmes entiers (gzip). Le nombre de 10% que j'ai donné est le surcoût sur l'appel système
fstat(il fallait bien choisir quelque chose pour donner un ordre d'idée...).Dans le cas de gzip, le coût de capsicum ajoute seulement un surcoût constant, puisque le gros de l'application est de la compression qui se fait sans utilisation de droits particuliers. Avec l'implémentation actuelle ils ont mesuré un surcoût de 2.37 millisecondes, ce qui est non-négligeable (par rapport au temps total de
gzip) pour de petites entrées. Pour des entrées de taille 512K, cela représente 5% du temps de calcul (dans leurs tests), et ensuite cela devient vite négligeable.Les auteurs précisent qu'ils comptent travailler à optimiser un peu leur code. J'imagine qu'ils ont commencé par obtenir une version fonctionnellement satisfaisante au début, sans mettre l'accent sur les performances, et qu'il y a une marge de progrès à faire. Mais dans tous les cas, ce genre de vérifications supplémentaires aura toujours un coût; c'est au développeur de faire un compromis, selon la nature de son application, ses besoins en sécurité et en performance.
Si un attaquant modifie un exécutable qui est lancé avec les droits utilisateurs (que l'exécutable ait prévu au départ d'utiliser capsicum ou pas), effectivement il peut faire ce qu'il veut dans les limites des droits de l'utilisateur. Capsicum ne change quelque chose que pour les processus qui tournent avec le 'capability flag', c'est à dire après l'appel de
cap_enter, ou encore les processus fils lancés par des processus souscap_enter.En gros, si tu appelles un programme "foo" modifié par l'attaquant depuis ton shell, il peut faire un peu ce qu'il veut; par contre si un programme "bar" géré par capsicum appelle "foo", il sera restreint aux droits qu'à "bar". C'est justement l'intérêt du Principle of Least Authority: si les droits de "bar" sont minimaux, l'attaquant (ou simplement tout problème lié à un bug non intentionnel) est très limité.