En fait, soit je comprends pas ce que tu dis, soit j'ai une vision trop globale de selinux ( à mon avis, je pense que je comprends pas )
Si tu prends l'integration de selinux dans postgresql, on voit qu'on peut compartimenter au sein d'un programme ( en l'occurence, postgresql ) l'accés à des données internes ( en l'occurence, les bases ). Sauf erreur de ma part, ça se fait pas au niveau du filesystem, mais bien en interne : http://wiki.postgresql.org/wiki/SEPostgreSQL_Architecture
Du coup, si je pige bien, ce qui fait la spécificité de capsicum ( qui va aussi séparer les objets manipulé ), c'est le fait que la source primaire de la politique appliqué sur les objets soit le programme lui même ( via son code ), et pas une base de référence externe ( en l'occurence pour selinux, la politique compilé dans le kernel ).
Du coup, ça me fait me poser plus de questions, dans le sens ou séparer ton process en composant ( ie ce que le papier appelle "logical applications" ) reviens plus ou moins à refaire le travail de l'os ( qui sépare tout sous forme de process ), mais sans avoir les couts de communications ? Et dans ce cas, si tu part du principe que les différents composants, c'est comme les process, j'ai le sentiment qu'on a pas un truc si différent de l'existant, et que ça évite juste de refaire les outils ?
[^] # Re: Capsicum
Posté par Misc (site web personnel) . En réponse au journal Un article sur le sandboxing de Chrome sous Linux. Évalué à 2.
En fait, soit je comprends pas ce que tu dis, soit j'ai une vision trop globale de selinux ( à mon avis, je pense que je comprends pas )
Si tu prends l'integration de selinux dans postgresql, on voit qu'on peut compartimenter au sein d'un programme ( en l'occurence, postgresql ) l'accés à des données internes ( en l'occurence, les bases ). Sauf erreur de ma part, ça se fait pas au niveau du filesystem, mais bien en interne :
http://wiki.postgresql.org/wiki/SEPostgreSQL_Architecture
Du coup, si je pige bien, ce qui fait la spécificité de capsicum ( qui va aussi séparer les objets manipulé ), c'est le fait que la source primaire de la politique appliqué sur les objets soit le programme lui même ( via son code ), et pas une base de référence externe ( en l'occurence pour selinux, la politique compilé dans le kernel ).
Du coup, ça me fait me poser plus de questions, dans le sens ou séparer ton process en composant ( ie ce que le papier appelle "logical applications" ) reviens plus ou moins à refaire le travail de l'os ( qui sépare tout sous forme de process ), mais sans avoir les couts de communications ? Et dans ce cas, si tu part du principe que les différents composants, c'est comme les process, j'ai le sentiment qu'on a pas un truc si différent de l'existant, et que ça évite juste de refaire les outils ?