Je pense que tu mets le doigt sur le problème qui est la "communication". La virtualisation donne une façon de séparer les processus—qui est sans doute plus robuste que des solutions internes au noyau comme les process groups, puisque la surface d'attaque est plus petite. Séparer c'est bien mais il faut aussi communiquer, et c'est sur cet aspect que les approches par capacités apportent un point de vue intéressant—qui est applicable même par-dessus des solutions à base de virtualisation, même si la réalisation technique ne sera pas exactement Capsicum.
Les applications qui peuvent être complètement séparées (le client-mail boulot et le lecteur de musique) ne posent pas de problème. La difficulté est sur celles qui doivent collaborer, par exemple le navigateur-web-boulot et le client-mail-boulot (on veut télécharger un document du web et l'envoyer ensuite par pièce-jointe). Tu ne peux pas complètement isoler ces deux processus (pour qu'ils répondent à ton besoin il faut qu'ils puissent échanger de l'information). Mais si tu te contentes de les mettre sur la même machine virtuelle, sans essayer de les protéger l'un de l'autre, tu laisses la porte ouverte à des attaques (par exemple une faille dans le décodeur PNG du browser permet d'exécuter du code arbitraire et donc de lire le carnet d'adresse du client mail). Il faut soit re-isoler au sein de la VM (en utilisant Capsicum par exemple), soit les mettre sur deux VMs mais avec des outils de partage de données entre les deux.
Pour ce partage, les solutions de virtualisation comme Qube-OS proposent des solutions spécialisées selon le type d'objet à partager (fichier, texte...); à chaque fois, le système fait une médiation entre les VMs en demandant à l'utilisateur (dans un processus privilégié) de désigner la donnée à faire traverser. Ce sont des cas particuliers de l'"approche capacités", où c'est la désignation des ressources qui contient/transmet les droits sur ces ressources. On peut donc voir Capsicum comme (une implémentation pour Linux d') une généralisation de ce mode d'échange.
[^] # Re: Virtualisation par défaut
Posté par gasche . En réponse à la dépêche Capsicum dans Linux : ça bouge !. Évalué à 9.
Je pense que tu mets le doigt sur le problème qui est la "communication". La virtualisation donne une façon de séparer les processus—qui est sans doute plus robuste que des solutions internes au noyau comme les process groups, puisque la surface d'attaque est plus petite. Séparer c'est bien mais il faut aussi communiquer, et c'est sur cet aspect que les approches par capacités apportent un point de vue intéressant—qui est applicable même par-dessus des solutions à base de virtualisation, même si la réalisation technique ne sera pas exactement Capsicum.
Les applications qui peuvent être complètement séparées (le client-mail boulot et le lecteur de musique) ne posent pas de problème. La difficulté est sur celles qui doivent collaborer, par exemple le navigateur-web-boulot et le client-mail-boulot (on veut télécharger un document du web et l'envoyer ensuite par pièce-jointe). Tu ne peux pas complètement isoler ces deux processus (pour qu'ils répondent à ton besoin il faut qu'ils puissent échanger de l'information). Mais si tu te contentes de les mettre sur la même machine virtuelle, sans essayer de les protéger l'un de l'autre, tu laisses la porte ouverte à des attaques (par exemple une faille dans le décodeur PNG du browser permet d'exécuter du code arbitraire et donc de lire le carnet d'adresse du client mail). Il faut soit re-isoler au sein de la VM (en utilisant Capsicum par exemple), soit les mettre sur deux VMs mais avec des outils de partage de données entre les deux.
Pour ce partage, les solutions de virtualisation comme Qube-OS proposent des solutions spécialisées selon le type d'objet à partager (fichier, texte...); à chaque fois, le système fait une médiation entre les VMs en demandant à l'utilisateur (dans un processus privilégié) de désigner la donnée à faire traverser. Ce sont des cas particuliers de l'"approche capacités", où c'est la désignation des ressources qui contient/transmet les droits sur ces ressources. On peut donc voir Capsicum comme (une implémentation pour Linux d') une généralisation de ce mode d'échange.