Sauf s'il est présent sur la ligne de commande, j'ai bon?
Oui.
Parce que pour éditer un projet, ça devient galère de filer tous les fichier du projet, ou de devoir repasser par la ligne de commande pour ouvrir un nouveau fichier.
Je te comprends. En fait, il y a une solution, non implémentée, et qui nécessitera cette fois une modification des applications pour en bénéficier : leur donner accès à un programme séparé ayant accès au homedir de l'utilisateur et chargé d'ajouter les fichiers demandés au /... de l'appelant. En pratique, cela donnerait :
pipe();
clone(MON_FILS_A_LE_DROIT_DE_M_AJOUTER_DES_ENTREES);
execve(ouvreur_de_fichiers);
xchroot(je_sors_de_ce_xchroot_et_j_ai_acces_au_homedir);
Bonjour cher utilisateur, quel fichier voulez-vous ouvrir?
Ah, celui-ci? OK.
Modifie_le_xchroot_de_mon_pere(AJOUTE, CE_FICHIER_AVEC_CE_NOM);
write(DANS_LE_PIPE, LE_NOUVEAU_NOM);
exit(0);
Pour la création de fichier, supposons que je navigue via panda roux, et que je veuille enregistrer houlahoup.rar ça marche comment? on enregistre dans un répertoire qui ensuite est fusionné avec le reste de l'arbo?
Deux solutions : soit tu l'enregistres dans le userdir de ton panda, qui est le répertoire contenant sa conf, soit tu as l'honneur d'avoir une version du panda modifiée de la même façon que ci-dessus, qui va appeler un programme extérieur pour le faire. L'importance du programme extérieur tient, d'une part, à l'isolation, et d'autre part, à l'obtention d'une autorisation explicite de l'utilisateur pour effectuer cet enregistrement.
Comment fonctionne l'isolation ? C'est une copie des binaire ou des liens ?
Chaque programme a sa racine, qui correspond au répertoire /root de son paquetage. Dans celui-ci se trouvent des liens matériels vers tous les binaires sur lesquels ce programme a une dépendance, comme par exemple la glibc; toutefois, les programmes dont il dépend sont remplacés par leurs lanceurs, qui se chargent de maintenir l'isolation entre les xchroots.
Au niveau encombrement mémoire ça se passe comment ?
Euh... Si j'avais implémenté le partage effectif de la mémoire partagée, ça se passerait nettement mieux /o\ . En pratique, lorsque les libs correspondent aux mêmes fichiers, elles correspondront à la même zone mémoire, comme sous Linux.
(Je suis parfaitement conscient que cela constitue un canal de communication caché, mais mon but n'est pas d'empêcher deux applications collaboratives de communiquer; il est bien connu que de ce côté-là, la seule bande passante du scheduler est plus que suffisante. Mais pour contraindre deux applications distinctes à collaborer, il va falloir envoyer un exploit dans chacune d'elle tout en faisant en sorte que l'une au moins ait accès à une ressource intéressante, ce qui est une toute autre paire de manches qu'un "simple" exploit jour zéro.)
Si un appli passe outre le read only des binaire nécessaire, est ce que ça impacte les autres?
Ah, oui. Si une application agressive parvient à modifier la glibc, c'est le désastre garanti. Mais la glibc est installée avec l'UID 0, et celui-ci est désactivé.
[^] # Re: Si je comprends bien on ne peut pas modifier un fichier sur le disque
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 2.
Oui.
Je te comprends. En fait, il y a une solution, non implémentée, et qui nécessitera cette fois une modification des applications pour en bénéficier : leur donner accès à un programme séparé ayant accès au homedir de l'utilisateur et chargé d'ajouter les fichiers demandés au /... de l'appelant. En pratique, cela donnerait :
Deux solutions : soit tu l'enregistres dans le userdir de ton panda, qui est le répertoire contenant sa conf, soit tu as l'honneur d'avoir une version du panda modifiée de la même façon que ci-dessus, qui va appeler un programme extérieur pour le faire. L'importance du programme extérieur tient, d'une part, à l'isolation, et d'autre part, à l'obtention d'une autorisation explicite de l'utilisateur pour effectuer cet enregistrement.
Chaque programme a sa racine, qui correspond au répertoire /root de son paquetage. Dans celui-ci se trouvent des liens matériels vers tous les binaires sur lesquels ce programme a une dépendance, comme par exemple la glibc; toutefois, les programmes dont il dépend sont remplacés par leurs lanceurs, qui se chargent de maintenir l'isolation entre les xchroots.
Euh... Si j'avais implémenté le partage effectif de la mémoire partagée, ça se passerait nettement mieux /o\ . En pratique, lorsque les libs correspondent aux mêmes fichiers, elles correspondront à la même zone mémoire, comme sous Linux.
(Je suis parfaitement conscient que cela constitue un canal de communication caché, mais mon but n'est pas d'empêcher deux applications collaboratives de communiquer; il est bien connu que de ce côté-là, la seule bande passante du scheduler est plus que suffisante. Mais pour contraindre deux applications distinctes à collaborer, il va falloir envoyer un exploit dans chacune d'elle tout en faisant en sorte que l'une au moins ait accès à une ressource intéressante, ce qui est une toute autre paire de manches qu'un "simple" exploit jour zéro.)
Ah, oui. Si une application agressive parvient à modifier la glibc, c'est le désastre garanti. Mais la glibc est installée avec l'UID 0, et celui-ci est désactivé.