L'idée fondamentale de Capsicum est que les droits que l'on a sur un objet dépendent de la façon dont y accède et pas de l'objet lui-même: si A envoie à B une description de l'objet O, il choisit lesquels de ses droits sur O lui transférer dans cette description. Concrètement ces droits sont véhiculés par des descripteurs de fichiers (étendus avec des informations de droit d'accès et plus généralement d'appels systèmes utilisables sur l'objet pointé par le descripteur), et non les fichiers eux-mêmes. On peut avoir deux descripteurs différents vers le même objet et utiliser l'un ou l'autre qui donnent des droits différents (un peu comme en Role-Based Security à un niveau moins fin).
Cette approche d'attacher des droits aux descripteurs ne correspond pas du tout au design de LSM qui est une interface générale pour les solutions de type "mandatory access control": étant donné un sujet A et un objet O, A a-t-il le droit d'effectuer une opération donnée sur O ? C'est une façon très différente de concevoir le contrôle d'accès1, et il n'est pas à ma connaissance possible d'implémenter Capsicum comme un module LSM --- du moins sans un surcoût important, moralement il faudrait un label différent pour chaque paire d'objet et de sujet.
Le patch actuel communique un peu avec l'interface LSM (par exemple il appelle des hooks LSM si un module de sécurité est déjà chargé), et cela lui a été reproché—on préfère une solution soit complètement dans le moule LSM, soit complètement en dehors.
1: Capabilities: je ne connais qu'une petite partie du monde et c'est cette connaissance qui limite intrinsèquement mes droits, et que je peux transmettre. MAC: tout le monde peut parler avec tout le monde, mais un oracle externe décide d'interdire certains accès selon les identités des sujets/objets.
.
Sur l'avis de Linus : il ne s'est pas exprimé de nouveau sur ces séries de patches, donc je ne sais pas quel est son avis et s'il est toujours le même. Je crois que comme toujours les mainteneurs Linux reprochent aux gens qui veulent intégrer un gros morceau de l'extérieur de ne pas assez se reposer sur ce qui existe déjà dans le noyau, et que les premières versions des patches se font toujours rejeter pour cette raison. Je ne serais pas surpris qu'il ait senti Capsicum à l'époque comme un "gros bousin repris en bloc de FreeBSD" et réagi fortement à cause de cela—les premiers prototypes développés en 2011 avaient probablement ce défaut. Les patches actuels semblent plus Linux-centriques et ont sans doute de meilleures chances—même si rien n'est joué pour l'instant. Il s'agit d'un comrpomis à trouver, et il va certainement y avoir encore pas mal de changements.
[^] # Re: Qu'est ce qui a changé?
Posté par gasche . En réponse à la dépêche Capsicum dans Linux : ça bouge !. Évalué à 10.
L'idée fondamentale de Capsicum est que les droits que l'on a sur un objet dépendent de la façon dont y accède et pas de l'objet lui-même: si A envoie à B une description de l'objet O, il choisit lesquels de ses droits sur O lui transférer dans cette description. Concrètement ces droits sont véhiculés par des descripteurs de fichiers (étendus avec des informations de droit d'accès et plus généralement d'appels systèmes utilisables sur l'objet pointé par le descripteur), et non les fichiers eux-mêmes. On peut avoir deux descripteurs différents vers le même objet et utiliser l'un ou l'autre qui donnent des droits différents (un peu comme en Role-Based Security à un niveau moins fin).
Cette approche d'attacher des droits aux descripteurs ne correspond pas du tout au design de LSM qui est une interface générale pour les solutions de type "mandatory access control": étant donné un sujet A et un objet O, A a-t-il le droit d'effectuer une opération donnée sur O ? C'est une façon très différente de concevoir le contrôle d'accès1, et il n'est pas à ma connaissance possible d'implémenter Capsicum comme un module LSM --- du moins sans un surcoût important, moralement il faudrait un label différent pour chaque paire d'objet et de sujet.
Le patch actuel communique un peu avec l'interface LSM (par exemple il appelle des hooks LSM si un module de sécurité est déjà chargé), et cela lui a été reproché—on préfère une solution soit complètement dans le moule LSM, soit complètement en dehors.
1: Capabilities: je ne connais qu'une petite partie du monde et c'est cette connaissance qui limite intrinsèquement mes droits, et que je peux transmettre. MAC: tout le monde peut parler avec tout le monde, mais un oracle externe décide d'interdire certains accès selon les identités des sujets/objets.
.
Sur l'avis de Linus : il ne s'est pas exprimé de nouveau sur ces séries de patches, donc je ne sais pas quel est son avis et s'il est toujours le même. Je crois que comme toujours les mainteneurs Linux reprochent aux gens qui veulent intégrer un gros morceau de l'extérieur de ne pas assez se reposer sur ce qui existe déjà dans le noyau, et que les premières versions des patches se font toujours rejeter pour cette raison. Je ne serais pas surpris qu'il ait senti Capsicum à l'époque comme un "gros bousin repris en bloc de FreeBSD" et réagi fortement à cause de cela—les premiers prototypes développés en 2011 avaient probablement ce défaut. Les patches actuels semblent plus Linux-centriques et ont sans doute de meilleures chances—même si rien n'est joué pour l'instant. Il s'agit d'un comrpomis à trouver, et il va certainement y avoir encore pas mal de changements.