C'est vrai que, côté thunderdome, j'ai un peu l'impression de me faire troller, par moments. Je veux dire, c'est mon logiciel, et je le place moi-même sous une licence libre, sans y être obligé de quelque façon que ce soit, donc si vous l'aimez, prenez-le, si vous ne l'aimez pas, laissez-le, et puis voilà tout…
Enfin, c'est peut-être à moi de m'habituer à ce côté-ci de la communauté.
Empêcher deux instances différentes d'une même application d'accéder au même espace de nommage du FS c'est quelque chose de différent.
Et c'est ce que je fais. Deux instances d'une même application, tournant dans le même xchroot, ne peuvent pas accéder aux mêmes fichiers. Chaque processus a sa propre vision de /… , avec ses propres fichiers dedans, et s'ils veulent communiquer, ils peuvent le faire par IPCs.
Et comme je le disais, le système est déjà auto-hébergé dans ces conditions, donc, ben, utilisable, il l'est. Oui, il y aura sans doute encore du travail côté bus de communications, mais c'est parfaitement faisable.
Un ':e' dans ton vim il peut ouvrir ou pas un fichier ?
Non.
Un ':w' il marche ?
Oui, mais pas dans un nouveau nom.
Un ':!ls' il marche ?
Non. Sauf si l'utilisateur décide délibérément d'injecter le lanceur de ls dans chroot de vim, c'est techniquement possible, mais plus qu'étrange.
Ca va devenir rigolo en généralisant la chose, en introduisant les mécanismes d'IPC etc.
Pas de problème, il faut les faire passer par des fichiers du xchroot, voilà tout. Par exemple, les sockets du domaine UNIX fonctionneront sans difficulté (liens matériels sur les sockets), seules les sockets UNIX de l'espace d'adressage anonyme seront impossibles à mettre en place.
Sachant que tout le reste du système est à refaire ca sent pas bon.
Hmmm… Je m'en sers déjà. Donc, éléments à refaire, ben, non, il n'y en a guère… Le gros de l'architecture est fait.
Et si le PDF en question modifie le logiciel et que tu ouvres le document « secret » avec un tel logiciel nouvellement vérolé ?
Et il va faire comment pour modifier le logiciel? Il n'a pas les droits requis, il est installé avec un UID différent de celui sous lequel travaille l'utilisateur.
Comment ça? La notion de "licence logicielle" n'existe pas en droit français, et tous ces documents qui s'intitulent eux-même "licence" s'interprètent comme des contrats.
Et, si, un contrat non signé a de la valeur, parce qu'un tribunal interprétera plus facilement un utilisateur comme une partie du contrat que comme un contrefacteur.
Je vais te donner un exemple. Tu as un éditeur de pdfs, et deux pdfs (au même niveau de sécurité pour SELinux). Le premier contient des données que tu ne souhaites pas divulguer, le second est piégé et va tenter de prendre le contrôle de ton lecteur pour lui faire ouvrir discrètement le premier, y récupérer des données, et les cacher sténographiquement dans lui-même. Comment fais-tu pour encaisser cela, avec SELinux et Seccomp2?
Réponse : c'est complètement impossible. Seccomp2 ne sert à rien dans ce cas, et SELinux n'empêchera pas un éditeur de pdfs d'ouvrir un pdf.
Avec mon système, la situation est différente : lorsque le second parvient à prendre le contrôle de l'éditeur, celui-ci est dans un chroot depuis lequel le premier est inaccessible. Donc l'attaque échoue avec -ENOENT.
Même la combinaison SELinux + Seccomp2 est incapable d'empêcher une application d'accéder à un fichier auquel elle peut légitimement avoir à accéder, lorsqu'elle tente de le faire et que l'utilisateur ne lui a pas demandé d'y accéder.
Dans ce genre de cas, malheureusement, il n'y aura qu'une seule possibilité : installer l'application dans deux xchroots distincts. Le premier doté de tous les droits requis pour faire toutes les opérations normales de l'application, mais incapable d'éditer ces fichiers de conf', le second quasi désactivé, mais capable les modifier.
Je conçois bien que ce soit très gênant, mais je ne peux pas faire de miracle : c'est ça ou perdre la sécurité.
Un historique Turing-complet… Oui, d'accord, mais est-ce que ipython exécute cet historique au démarrage (ou à un autre moment) sans interaction de l'utilisateur? Parce que, sinon, l'historique de bash aussi est Turing-complet, mais comme il est traité comme un simple fichier texte indiquant des commandes possibles, à nouveau, à moins d'un exploit permettant de faire exécuter du code à la seule lecture de l'historique, ce ne sera pas exploitable.
A moins d'une faille entre la chaise et le clavier, évidemment. Mais bon, là, ce n'est plus le même problème : je veux bien encaisser des exploits jours zéro, mais je ne peux pas non plus faire l'impossible ;-) .
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é.
Effectivement. Mon appel-système est nommé xchroot(2), et il diffère très fortement du chroot() POSIX qu'implémente Linux, que je ne compte d'ailleurs pas implémenter. Les différences sont:
xchroot(2) implique chdir(2);
xchroot(2) a pour effet de bord de fermer la totalité des descripteurs de fichiers référençant un répertoire de l'appelant, à l'exception de ceux dont il peut prouver qu'ils lui sont accessibles (parce qu'ils référencent des entrées dans son /…);
chdir("..") n'est pas toujours honoré; en fait, cet appel-système n'est honoré que si le répertoire ".." est lui aussi accessible depuis la racine du chroot;
il y a des restrictions importantes au droit de passer un descripteur de fichier référençant un répertoire dans les données ancillaires d'une socket UNIX.
De la sorte, même avec les privilèges maximaux, il est impossible de s'échapper d'un xchroot (Je vais peut-être les appeler comme ça, ce sera plus clair). Bien sûr avec des privilèges maximaux, on peut contourner le problème en remontant le disque dur ailleurs, mais sans cela, le xchroot est vraiment une prison complète.
Grâce à cela, xchroot(2) a pu être rendu non-privilégié, ce qui signifie que n'importe qui peut en créer un nouveau. C'est parfaitement inoffensif : on ne peut pas utiliser cette propriété pour s'en échapper, juste pour réduire la taille de son propre xchroot.
Autre particularité, le flag XCHROOT_USE_ROOTLINK de cet appel. Lorsqu'un processus l'emploie, si le binaire qu'il exécute actuellement comporte un lien racine (une sorte de lien matériel asymétrique pointant d'un fichier régulier vers un répertoire), alors le noyau donne à l'appelant pour nouvelle racine le répertoire visé. Cela signifie que les programmes peuvent s'appeler les uns les autres sans avoir accès au contenu des chroots de leurs descendants; tout au plus peuvent-ils partager les fichiers qu'ils désirent par /… .
Lorsque la pile réseau sera remise en place, elle fera usage des fichiers de périphérique de /dev pour déterminer les droits d'accès au réseau. De la sorte, xchroot(2) continuera bien à isoler les diverses ressources.
Je vais en revenir à ce document de RedHat référencé par patrick_g. L'une des grandes différences, c'est que le chroot() Linux ne fournit pas les fonctionnalités requises pour isoler toutes les applications. Dans le texte, RedHat envisage le cas où un utilisateur ou un démon sont placés dans un chroot, pas une simple application. Parce que, sous Linux, ça n'a pas de sens : si on chroote vim, comment pourrait-il accéder au fichier qu'il doit éditer?
Mais, avec xchroot(2) qui manipule la partition /… , ça devient possible, et chez moi, c'est au niveau de chaque application que les xchroots sont utilisés. Et là, aucun usage des permissions UNIX ne permet d'obtenir ce résultat.
(Pour ceux qui ne comprennent pas : /… est une partition spéciale, dépourvue de toute réalité sur le disque dur (comme /proc), et dont le contenu varie selon le processus qui l'observe; chaque processus ayant la faculté d'associer les fichiers de son choix aux noms qu'il souhaite dans /… . Pour une illustration de son utilisation, voyez mon post un peu au dessus de celui-ci.)
Heu les fichiers de configuration de Vim sont turing complet…
Oui, désolé pour la confusion, c'est de ma faute. J'ai expliqué le modèle simplifié, alors qu'avec des applis dotés de fichiers de configuration problématiques, voire Turing-complets, le schéma sera différent. Milles excuses, je n'aurais pas dû prendre vim comme exemple.
Dans le cas de vim, on a deux groupes de fichiers spécifiques à un utilisateur : ceux relevant de l'historique des commandes (.viminfo), et ceux relevant de la configuration (.vimrc). Pour ceux de l'historique, ils seront bien en lecture-écriture par vim, sans autres formes de procès; du coup, un exploit jour zéro dedans permettrait une telle transmission de l'attaque. Heureusement, je ne crois pas qu'il existe de programmes dont les fichiers d'historiques soient Turing-complets - s'il en existait, il faudrait vraisemblablement les désactiver ou renoncer partiellement à la protection contre les exploits.
Par contre, les fichiers de configuration seront marqués lecture-seule-non-renommable-non-supprimable (côté implémentation, je pense que ce sera fait avec les attributs étendus), et l'application elle-même n'aura pas les privilèges requis pour retirer ou passer outre ce marquage. En revanche, le shell de l'utilisateur aura les privilèges requis pour les ignorer, et le lanceur de vim en fera usage pour marquer les fichiers à éditer de façon appropriée.
Voici une description du scénario, pour être plus clair :
Créateur des userdirs: tiens, on me demande de créer un userdir correspondant à l'uid 1017 pour le programme vim? Bon, c'est parti, je recopie l'userdir modèle et je le chown en 1017… Ah tiens, le fichier .vimrc du modèle est marqué lecture-seule-non-renommable-non-supprimable? Bon, je marque sa copie de la même façon.
Utilisateur: tiens, je vais éditer mon fichier de conf' vim, ça faisait longtemps. Alors, vim ~/userdirs/std/0.0.1/vim/7.3/vim/.vimrc … (Oui, je sais, le chemin n'est pas pratique. On pourra sans doute proposer à l'utilisateur d'ajouter des liens matériels dans son $HOME pour lui simplifier le travail, à condition qu'il n'utilise qu'une seule version de vim ou de ses fichiers de conf'.)
Shell : "vim ~/userdirs/std/0.0.1/vim/7.3/vim/.vimrc", vous dites? OK, fork(), et execve() sur /usr/bin/vim.
Lanceur de vim : Je ne suis pas vim, mais son lanceur! Bon, au vu de la ligne de commande, je dois éditer le fichier ~/userdirs/std/0.0.1/vim/7.3/vim/.vimrc . Soit. J'appelle xchroot(), et je lui demande de créer une entrée dans mon répertoire /… correspondant au fichier .vimrc correspondant, et simultanément, de me changer de chroot au profit de celui du vrai vim. Ah, et je marque l'entrée de /… de ce fichier avec le flag BYPASS_READONLY_NOREMOVE.
Noyau : D'accord pour le flag BYPASS_READONLY_NOREMOVE, tu as les privilèges requis, mais xchroot() implique chdir(), donc ton nouveau chemin courant devient la racine du chroot de vim.
Lanceur de vim : C'était prévu! Maintenant, capset(ABANDONNE, BYPASS_READONLY_NOREMOVE);
Noyau : Pas de problème, j'ai l'esprit large, j'autorise n'importe qui à diminuer ses privilèges.
Lanceur de vim : et maintenant, execve() sur /usr/bin/vim !
Vim : Ah, tiens, je dois éditer le fichier /…/home/username/userdirs/std/0.0.1/vim/7.3/vim/.vimrc . Bon, open() dessus…
Noyau : Ah, il est marqué lecture-seule-non-renommable-non-supprimable dans le système de fichiers, mais BYPASS_READONLY_NOREMOVE dans ton entrée /… . Bon, d'accord, tu peux l'éditer, je ferme les yeux.
Utilisateur : Ben voilà, ça marche très bien!
Maintenant, le scénario d'attaque :
Utilisateur : Tiens, je vais éditer /…/home/username/ultra_piégé_dans_tous_les_sens.txt .
Shell : Bon, ben, j'obéis, mais là, je ne réponds de rien, hein… fork(), et execve() sur /usr/bin/vim.
Lanceur de vim : Je ne suis pas vim, mais son lanceur! Bon, au vu de la ligne de commande, je dois éditer le fichier /…/home/username/ultra_piégé_dans_tous_les_sens.txt . Ben dis donc, y'en a vraiment qui ne manquent pas d'air, ici! Mais soit. J'appelle xchroot(), et je lui demande de créer une entrée dans mon répertoire /… correspondant au fichier ultra_piégé_dans_tous_les_sens.txt, et simultanément, de me changer de chroot au profit de celui du vrai vim. Ah, et je marque l'entrée de /… de ce fichier avec le flag BYPASS_READONLY_NOREMOVE.
Noyau : D'accord pour le flag BYPASS_READONLY_NOREMOVE, tu as les privilèges requis, mais xchroot() implique chdir(), donc ton nouveau chemin courant devient la racine du chroot de vim.
Lanceur de vim : C'était prévu! Maintenant, capset(ABANDONNE, BYPASS_READONLY_NOREMOVE);
Noyau : Pas de problème, j'ai toujours l'esprit large, j'autorise n'importe qui à diminuer ses privilèges.
Lanceur de vim : et maintenant, execve() sur /usr/bin/vim !
Vim : Ah, tiens, je dois éditer le fichier /…/home/username/ultra_piégé_dans_tous_les_sens.txt . Bon, open() dessus…
Noyau : Ah, il ne comporte pas de marquage particulier dans le système de fichiers, donc, c'est bon, vas-y. (Oui, l'entrée est marquée BYPASS_READONLY_NOREMOVE dans /… , mais je m'en moque, ça ne change rien.)
Vim : Je l'ouvre, et…. Aaaaaaaaaaaaargh, un Balrog!
Balrog : Hahahahaha! Maintenant, j'ai le contrôle de vim! Tremblez, mortels! Tout d'abord, modifions son fichier de configuration…
Noyau : Bien essayé, mais il est marqué lecture-seule-non-renommable-non-supprimable, et tu viens de te débarrasser des privilèges requis pour l'ignorer.
Balrog : Koa?! Eh bien, rends-moi mes privilèges!
Noyau : j'ai l'esprit large, mais pas à ce point. Va voir dans la Moria si j'y suis, permission denied.
Balrog : Que?! Alors, retire ce marquage!
Noyau : De nos jours, les démons ne doutent plus de rien. Cause toujours, permission denied.
Balrog : Heu… Et… Il me reste quoi, comme droits, au juste?
Noyau : Bon, il n'y a pas d'appel-système pour te fournir d'un coup une telle analyse, mais je vais te répondre quand même. Tu as le droit d'éditer le fichier dont tu es issu, ainsi que l'historique des commandes de cet utilisateur. Tu as aussi le droit d'exécuter vim, de réduire la taille de ton chroot ainsi que tes privilèges, et d'appeler exit(2).
Balrog [fait une dépression nerveuse]
Bon, en pratique, l'attaquant pourrais tenter sa chance en recopiant le code d'exploit dans le fichier d'historique au niveau du tampon de copier-coller de vim, à condition que son exploit soit compatible avec le passage par ce tampon, et que soit la seule lecture de l'exploit dans le fichier d'historique suffise à l'exploiter, soit qu'il parvienne à amener l'utilisateur à le coller quelque part. C'est vrai, et donc certaines classes rares d'exploits pourront théoriquement progresser, très lentement, à travers le système (à moins que l'utilisateur, ou sa distribution, ne désactive le fichier d'historique).
Mais ce ne sera pas discret (trace claire dans le système de fichiers), ce sera lent (ce qui est catastrophique pour un exploit jour zéro, qui repose justement sur la vitesse d'action), et seul un très faible sous-ensemble des exploits précédents pourront tenter des choses de ce genre.
Mais c'est vrai, dans l'absolu, tu as raison, pour les applications dotées de fichiers spécifiques à un utilisateur modifiables par l'application elle-même sans ordre explicite, la sécurité ne sera pas absolument parfaite. D'ailleurs, un exploit noyau aussi, ça suffirait à passer. Mais elle sera renforcée, et très significativement; et pour la plupart des applications, elle sera complète hors bogue noyau.
Ah, et je précise : même s'il y avait deux sessions de vim simultanées, tournant dans le même chroot, l'une éditant ton fichier piégé, l'autre mon /etc/shadow, ton exploit ne parviendrait pas à passer de l'une à l'autre.
A moins bien sûr que tu n'aies un second exploit jour zéro touchant cette fois les fichiers de configuration de vim. Mais même dans ce cas, les progrès seront très lents, le risque de détection réel (on ne cache pas un exploit dans des fichiers de conf comme ça), et il n'y aura toujours pas d'accès au réseau.
En effet. Il ne s'agit pas d'empêcher les exploits, mais de les encaisser, c'est-à-dire d'empêcher les attaquants d'en tirer profit.
Par exemple, si tu trouvais un exploit jour zéro dans vim, que tu m'envoyais un fichier texte qui en tirait profit, et que je l'ouvrais sous Manux, ton exploit serait entièrement bloqué. Il aurait juste accès au chroot de vim, en lecture seule, ce qui ne sert à rien, et à ton fichier en lecture-écriture, ce qui est tout aussi inutile. Si, à la rigueur, il pourrait changer mes fichiers de préférences vim… La belle affaire.
Bref, rien à voir avec un système classique, où un tel exploit donnerait accès à tout mon compte et au réseau par dessus le marché.
Linux est un noyaux et ne gère pas le paquetage et les dépendances des programmes en lui-même; C'est le gestionnaire de paquets qui s'en occupe.
Bien sûr, c'est pareil chez moi! Mais seul mon format de paquetage comporte les fonctionnalités requises pour faire usage des protections contre les exploits jour zéro, donc tous les autres sont inadaptés.
Tu ne peux pas prétendre au libre si tu veux empêcher l'utilisateur d'utiliser d'autres éléments, surtout lorsqu'il s'agit d'un système d'exploitation.
Pour ce qui est d'installer des programmes quelconques en espace utilisateur, pas de problème; l'interface graphique, en revanche, je ne peux rien promettre. Le jour venu, on verra comment tout ça s'assemblera.
Ce n'est pas pour rien que les distributions Linux sont extrêmement diversifiées sur de nombreux plans ("sacré foutoir" pour certain). Elles sont nées chacune de différentes nécessité, qu'il s'agisse de question d'éthique ou techniques.
Oui, et bien, justement. Cette liberté, Linux la fournit, et c'est très bien ainsi, par ce que cela signifie qu'il existe un système libre qui la fournit. Mais quel système libre existe-t-il qui ne propose PAS ce choix? Je suis parfaitement sérieux. Au méta-niveau, est-ce que l'utilisateur a le choix, actuellement, d'opter pour un logiciel libre qui ne lui donnera PAS d'autres choix? Non. Et pourtant, ça n'a rien d'absurde!
Chez nous, on dit : "Wer die Wahl hat, hat die Qual", ce qui signifie approximativement que celui qui a le choix a aussi toutes les difficultés liées au choix. En fournissant un système qui ne laisse pas ce choix, j'évite aussi de fournir ces difficultés, et j'accrois le niveau général de choix dans le logiciel libre (puisque celui qui veut le choix, bah, il a déjà Linux, et avec mon cher système, il pourra aussi choisir de ne plus en avoir).
Mais bon, inutile de discuter de ce point plus avant. Moi-même, je ne sais pas comment l'interface graphique sera faite, donc, notre discussion n'apporte rien; au final, ce sont les contraintes techniques qui auront le maître mot.
Genode est un framework, il supporte bien plus que L4, dont Linux ( http://genode.org/documentation/platforms/index pour info ). La question de la compatibilité binaire n'est pas un élément suffisant (comme tu l'as souligné dans ton journal), exemple en est le projet Wine, qui fournit une couche de compatibilité avec Windows.
Oui et non. Si tu regardes leurs exemples de code, tu verras que ce n'est pas du tout Linuxien. Manifestement, ils utilisent Linux pour le support matériel, mais ils n'exposent pas ses interfaces à leurs propres applications.
Juste une dernière question: pourquoi avoir codé en français?
Deux raisons. Primo, quand j'ai commencé, je voulais apprendre comment marchait Linux, et je ne pensais pas parvenir au stade où j'en suis. Deuxio, quand c'est devenu difficile, il a fallu que je fasse énormément d'analyses et de recherches, et je n'aurais vraiment pas pu les faire dans une langue étrangère. Je me souviens encore quand je parcourais le dictionnaire, pour essayer de mettre des mots sur ce que je faisais…
Pour innover, il faut avoir l'esprit aussi clair que possible. Mais bon, maintenant que c'est fait, la traduction en anglais est envisageable.
D'un point de vue architectural, pourquoi ne pas séparer le projet d'un noyaux et celui d'un système d'exploitation/plateforme ?
Comme je l'ai mis dans la FAQ, le système de paquetage est vraiment intégré au système d'exploitation. Linux utilise juste les paquetages pour vérifier qu'il a bien toutes les dépendances d'un programme installées; moi, je m'en sers pour construire chaque chroot et mettre en place les lanceurs de chaque programme. C'est vraiment une intégration profonde et incontournable.
Cela n'exclut pas l'existence de distributions fondées sur le système, bien au contraire. Simplement, s'il s'en crée, elles seront moins éloignées entre elles que les distribs Linux. En échange, elles seront toutes intercompatibles.
Ne faudrait pas permettre justement qu'il n'y ait pas une seul UI (qu'il vaudrait mieux séparer du gestionnaire graphique)—c'est après tout une richesse qui permet à chacun d'y trouver son compte. La facilité d'une UI unifiée pour l'utilisateur lambda ne devrait pas interférer avec la possibilité d'adapter son outil (et non de s'y adapter).
Bon, d'abord, pour l'instant, je n'ai pas d'UI, hein :-). Pour ce qui est d'adapter, oui, je suis entièrement pour; des thèmes divers comme dans fluxbox, des favoris, tout ça, ça m'a l'air très bien; le problème, c'est quand on va plus loin. Les membres de ma famille ne sont vraiment, mais alors vraiment pas portés sur la technique (ils sont tous littéraires), donc je peux voir comment des utilisateurs "normaux" se comportent. Eh bien, rien qu'un simple déplacement d'un menu, ça suffit à les perturber au point de leur faire renoncer à utiliser un logiciel. (Et pas la peine de lancer un troll, non-non, ce sont des gens très compétents. Mais dans leurs domaines.) Alors, franchement, une floraison d'interfaces comme sous Linux… Et quand un utilisateur se retrouve perdu parce qu'il est allé sur le poste d'un autre, et qu'il ne reconnaît plus rien, malheureusement, oui, il y a un problème.
Il faut être réaliste : c'est nous, les Linuxiens, qui sommes des anomalies, et ce sont les non-informaticiens qui sont la norme. Et puis, de toutes façons, les informaticiens s'en tireront toujours avec la ligne de commande, alors…
Ah, d'ailleurs, ça me fait penser à une autre règle de conception. Lorsqu'il y aura une UI, la règle sera : le système d'exploitation doit avoir une configuration par défaut adaptée aux besoins des utilisateurs n'ayant pas assez de connaissances techniques pour modifier cette configuration.
BTW, tu connais Genode? ( http://genode.org/ ) Ça pourrait pas mal t'intéresser :)
Ah, non, en effet. Je vais y jeter un œil, mais à priori, il y a des différences importantes entre leur projet et le mien. D'abord, c'est un projet à micro-noyau fondé sur L4, et ça, ça me laisse perplexe (L4 ne dispose pas des primitives requises pour implémenter efficacement les opérations de la classe select(2); rendons à César ce qui lui appartient, c'est le projet Hurd qui l'a découvert). De plus, Manux est vraiment compatible binairement avec Linux, donc là aussi, les deux projets s'écartent fortement.
Pour le reste, les APIs publiées par ce projet sont insuffisantes pour l'évaluer (il n'y a que les APIs de type micro-noyau, pas de table d'appels-systèmes comparable en termes d'abstractions avec celle de Linux), mais je pense qu'ils se dirigent plutôt vers un système du type Hurd-NG que Linux.
Ah, et L4 n'est pas patchable dynamiquement. Mon noyau, si :-) .
(P.S. : Pour ceux qui s'interrogent, mes commentaires sont à 0 parce que c'est ma note par défaut, je viens de créer ce compte pour faire cette annonce.)
En fait, je ne m'attends pas vraiment à avoir beaucoup de contributions. Mais c'est sans importance : j'y ai travaillé seul durant des années, et je compte bien continuer quoi qu'il en soit.
Le Français exclue de facto un bon nombre de gens qui n'iront pas plus loin que les noms de fichier
C'est vrai, mais une chose à la fois. Pour l'instant, le plus urgent, c'est de documenter les interfaces internes du noyau; et je compte bien le faire en anglais.
La licence est trop longue et trop compliquée
Ça, c'est un problème plus complexe qu'il n'en a l'air. Ce n'est pas simple de faire une licence libre entièrement légale. Par exemple, si on applique vraiment, vraiment strictement les principes de Debian, la GPL est non-libre.
En effet, comme elle ne comporte pas de choix de loi applicable, on peut lui appliquer le droit que l'on veut; donc en particulier le droit français. Mais en droit français, en vertu de l'article 46 du code de procédure civile, les tribunaux ayant compétence en matière délictuelle incluent ceux dans lesquels le fait dommageable a été subi.
Le problème survient lorsqu'un plaignant déclare avoir subi des dommages du fait d'une diffusion illégale par internet. Comme internet est disponible dans toutes les juridictions françaises, il suffit au plaignant de trouver un cas de téléchargement dans la juridiction de son choix pour rendre le tribunal territorialement compétent. Résultat, un joli "choice of venue" applicable à tous les tribunaux français, DOMs-TOMs compris, qui viole directement le test "Tentacles of Evil" de Debian.
Le cas ne s'est jamais produit, tant mieux, et je ne suis pas là pour lancer un troll contre la GPL. Mais le fait est que ce n'est pas en simplifiant les licences qu'on améliore la condition des utilisateurs. C'est vrai, ma licence est complexe, mais sa complexité répond à la complexité du monde réel. Comme le disait H.L. Mencken : "For every complex problem, there is a solution which is simple, neat, and wrong".
Pas de gestionnaire de version, rapport de bugs, mailing list (ou j'ai pas trouvé) …
Rien du tout! Mais bon, le projet n'est pas gros à ce point :-). S'il le devient, je mettrai ce genre de choses en place… Mais on n'en est pas là.
Les iopls, c'est une chose, mais impossible d'exprimer une relation du genre "l'application A a le droit de faire une copie d'écran, mais pas l'application B, et quant à C, elle en a le droit, mais lorsqu'elle en fait une, elle doit être falsifiée de telle sorte qu'elle se croie la seule application active".
Pour ça, il faut vraiment placer le serveur graphique en espace noyau.
Là, ça change tout ! Dans ton discours initial, j'ai cru qu'il s'agissait d'un choix "imposé" pour limiter les gestionnaires de paquets. Maintenant, s'il y a une raison technique derrière, je pense qu'il faut la mettre en avant. Sinon, on va de suite te demander pourquoi tu n'as pas utilisé un gestionnaire de paquets existant !
Effectivement, tu as raison. Je vais mettre la FAQ à jour. Rien de tel qu'un regard extérieur pour améliorer les choses!
Mais qu'en est-il de Wayland ? de Mir ? de DirectFB ou que sais-je encore ?
Je vais le mettre aussi dans la FAQ, mais globalement, ce sera non. Il faut que le serveur graphique soit intégré au noyau pour pouvoir gérer les privilèges des applications; et de toutes façons, architecturalement, il n'a rien à faire en espace utilisateur.
En revanche, ceci n'exclut pas que cette future interface graphique soit partiellement ou totalement compatible avec l'un de ces protocoles. Sur ce point, je ne les ai pas encore assez étudiés pour pouvoir me prononcer.
Tu m'aurais parlé de ring 0, prefetch ou CR0 et CR3, je t'aurais compris. Mais là, c'est du chinois pour moi :-D J'ai pas du pousser assez loin mes recherches sur les architectures !
En fait, le gfe est l'un de mes modules, et les bordereaux sont l'un des concepts du noyau, pour permettre le patchage dynamique (une zone de données dont la position est invariable, chaque module a le sien). Quant au flot d'exécution inactif, il s'agit du fe qui fait en boucle while (1) asm volatile ("hlt"); , pour éviter de consommer inutilement des ressources lorsque le processeur n'a rien à faire.
le code source en français (et pas que les commentaires).
Oui, incontestablement. Mais, quand je m'y suis mis, je ne pensais pas que j'irais si loin…
Cela dit, j'accepte les contributions en anglais, et il y a aussi un avantage à la chose : tant que les interfaces internes du noyau seront en français, il faudra les garder bien documentées. (Honte sur moi, faut que je m'y mette…)
vouloir guider les utilisateurs en limitant les choix (format du gestionnaire de paquets, interface graphique) me parait une bonne chose. Mais j'ai peur qu'avec la licence, cela conduise à des forks et "disperse" donc les forces…
En ce qui concerne le format de paquetage, il y a vraiment des motifs techniques pour n'utiliser que celui-là, parce que la logique des chroots lui est liée. En fait, le système de paquetages utilise l'arbre des dépendances d'un programme pour construire son chroot et ses lanceurs, donc aucun format de paquetage existant ne peut le concurrencer.
Quant à l'interface graphique, je ne pouvais pas accepter X.org : avec son appel-système iopl(2), il met l'ensemble des protections du système par terre (et, accessoirement, il est incapable de gérer l'isolement et les privilèges des applications). Donc, une nouvelle interface sera nécessaire… donc autant l'unifier.
Et puis, les forks… On disait la même chose au début de Linux, alors… :-)
…forces dispersées avec une licence qui, si je l'ai bien comprise (aussi en français), limite drastiquement les échanges de code entre différents projets qui seraient issus de Manux puisqu'il faut l'accord des détenteurs des droits patrimoniaux (cf. les difficultés de changement de licence de VLC).
Hmmm… Oui, effectivement. Cela dit, si ça devenait vraiment gênant, la clause de mise à jour de la licence ne m'interdit pas de supprimer cette disposition. On verra, mais je pense que les avantages dépasseront les inconvénients.
Les 7 octets en langage machine, ne serait-ce pas, par hasard, le passage en mode protégé ? :)
Non, mais pas loin :-) . Il s'agit du code du flot d'exécution inactif et du code pour le lancer; ils sont situés dans le bordereau du gfe. Ils doivent s'y trouver, parce qu'en cas de patchage du noyau, le code du flot d'exécution inactif doit demeurer au même emplacement.
Oui, effectivement, ça marche, mais ça va dégrader les performances lors des recompilations. Et puis, comme vim fait de toutes façons un sync() lorsqu'il enregistre, et que le noyau n'est pas si instable que ça, le faire manuellement est suffisant.
Pour tout dire, j'ai souvent (genre une fois sur 10) des plantages du noyau lors des réinstallations; mais côté plantages une fois installé, là, je dois bien dire que je ne sais plus de quand date mon dernier. Un bon bout de temps, en tout cas.
Mme Michu, qui n'est pas du tout favorable au plan proposé par son incapable de mari, décide de faire échouer celui-ci. Durant la phase d'échange des UIDs, elle prend note de tous ceux qui passent et se met à reproduire sans cesse le même (pas le sien, hein, faut pas se faire prendre non plus). De la sorte, lors de la phase de vérification, 174 votants constatent qu'ils ont le même UID que 173 autres personnes, les empêchant ainsi de vérifier que leur vote a bien été pris en compte. Le vote est donc annulé, et Mme Michu peut retourner à ses rosiers pendant que M. Michu se demande qui a bien pu lui faire un coup pareil, halala, heureusement que j'ai ma femme pour me consoler, hein.
Reconnaissons-le, l'anonymat a bien été garanti… Dommage que ce soit en faveur de l'attaquant.
[^] # Re: Licence, contrat, schmilblick
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 3.
Merci :)
C'est vrai que, côté thunderdome, j'ai un peu l'impression de me faire troller, par moments. Je veux dire, c'est mon logiciel, et je le place moi-même sous une licence libre, sans y être obligé de quelque façon que ce soit, donc si vous l'aimez, prenez-le, si vous ne l'aimez pas, laissez-le, et puis voilà tout…
Enfin, c'est peut-être à moi de m'habituer à ce côté-ci de la communauté.
[^] # Re: Intéressant
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 5.
Et c'est ce que je fais. Deux instances d'une même application, tournant dans le même xchroot, ne peuvent pas accéder aux mêmes fichiers. Chaque processus a sa propre vision de /… , avec ses propres fichiers dedans, et s'ils veulent communiquer, ils peuvent le faire par IPCs.
Et comme je le disais, le système est déjà auto-hébergé dans ces conditions, donc, ben, utilisable, il l'est. Oui, il y aura sans doute encore du travail côté bus de communications, mais c'est parfaitement faisable.
[^] # Re: Intéressant
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 4.
Non.
Oui, mais pas dans un nouveau nom.
Non. Sauf si l'utilisateur décide délibérément d'injecter le lanceur de ls dans chroot de vim, c'est techniquement possible, mais plus qu'étrange.
Pas de problème, il faut les faire passer par des fichiers du xchroot, voilà tout. Par exemple, les sockets du domaine UNIX fonctionneront sans difficulté (liens matériels sur les sockets), seules les sockets UNIX de l'espace d'adressage anonyme seront impossibles à mettre en place.
Hmmm… Je m'en sers déjà. Donc, éléments à refaire, ben, non, il n'y en a guère… Le gros de l'architecture est fait.
[^] # Re: Intéressant
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 2.
Et il va faire comment pour modifier le logiciel? Il n'a pas les droits requis, il est installé avec un UID différent de celui sous lequel travaille l'utilisateur.
[^] # Re: Licence, contrat, schmilblick
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 4.
Comment ça? La notion de "licence logicielle" n'existe pas en droit français, et tous ces documents qui s'intitulent eux-même "licence" s'interprètent comme des contrats.
Et, si, un contrat non signé a de la valeur, parce qu'un tribunal interprétera plus facilement un utilisateur comme une partie du contrat que comme un contrefacteur.
[^] # Re: Intéressant
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 3.
Je vais te donner un exemple. Tu as un éditeur de pdfs, et deux pdfs (au même niveau de sécurité pour SELinux). Le premier contient des données que tu ne souhaites pas divulguer, le second est piégé et va tenter de prendre le contrôle de ton lecteur pour lui faire ouvrir discrètement le premier, y récupérer des données, et les cacher sténographiquement dans lui-même. Comment fais-tu pour encaisser cela, avec SELinux et Seccomp2?
Réponse : c'est complètement impossible. Seccomp2 ne sert à rien dans ce cas, et SELinux n'empêchera pas un éditeur de pdfs d'ouvrir un pdf.
Avec mon système, la situation est différente : lorsque le second parvient à prendre le contrôle de l'éditeur, celui-ci est dans un chroot depuis lequel le premier est inaccessible. Donc l'attaque échoue avec -ENOENT.
[^] # Re: Intéressant
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 4.
Même la combinaison SELinux + Seccomp2 est incapable d'empêcher une application d'accéder à un fichier auquel elle peut légitimement avoir à accéder, lorsqu'elle tente de le faire et que l'utilisateur ne lui a pas demandé d'y accéder.
[^] # Re: Intéressant
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 4.
Dans ce genre de cas, malheureusement, il n'y aura qu'une seule possibilité : installer l'application dans deux xchroots distincts. Le premier doté de tous les droits requis pour faire toutes les opérations normales de l'application, mais incapable d'éditer ces fichiers de conf', le second quasi désactivé, mais capable les modifier.
Je conçois bien que ce soit très gênant, mais je ne peux pas faire de miracle : c'est ça ou perdre la sécurité.
[^] # Re: Intéressant
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 2.
Un historique Turing-complet… Oui, d'accord, mais est-ce que ipython exécute cet historique au démarrage (ou à un autre moment) sans interaction de l'utilisateur? Parce que, sinon, l'historique de bash aussi est Turing-complet, mais comme il est traité comme un simple fichier texte indiquant des commandes possibles, à nouveau, à moins d'un exploit permettant de faire exécuter du code à la seule lecture de l'historique, ce ne sera pas exploitable.
A moins d'une faille entre la chaise et le clavier, évidemment. Mais bon, là, ce n'est plus le même problème : je veux bien encaisser des exploits jours zéro, mais je ne peux pas non plus faire l'impossible ;-) .
[^] # 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é.
[^] # Re: Intéressant
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 8.
Effectivement. Mon appel-système est nommé xchroot(2), et il diffère très fortement du chroot() POSIX qu'implémente Linux, que je ne compte d'ailleurs pas implémenter. Les différences sont:
De la sorte, même avec les privilèges maximaux, il est impossible de s'échapper d'un xchroot (Je vais peut-être les appeler comme ça, ce sera plus clair). Bien sûr avec des privilèges maximaux, on peut contourner le problème en remontant le disque dur ailleurs, mais sans cela, le xchroot est vraiment une prison complète.
Grâce à cela, xchroot(2) a pu être rendu non-privilégié, ce qui signifie que n'importe qui peut en créer un nouveau. C'est parfaitement inoffensif : on ne peut pas utiliser cette propriété pour s'en échapper, juste pour réduire la taille de son propre xchroot.
Autre particularité, le flag XCHROOT_USE_ROOTLINK de cet appel. Lorsqu'un processus l'emploie, si le binaire qu'il exécute actuellement comporte un lien racine (une sorte de lien matériel asymétrique pointant d'un fichier régulier vers un répertoire), alors le noyau donne à l'appelant pour nouvelle racine le répertoire visé. Cela signifie que les programmes peuvent s'appeler les uns les autres sans avoir accès au contenu des chroots de leurs descendants; tout au plus peuvent-ils partager les fichiers qu'ils désirent par /… .
Lorsque la pile réseau sera remise en place, elle fera usage des fichiers de périphérique de /dev pour déterminer les droits d'accès au réseau. De la sorte, xchroot(2) continuera bien à isoler les diverses ressources.
Je vais en revenir à ce document de RedHat référencé par patrick_g. L'une des grandes différences, c'est que le chroot() Linux ne fournit pas les fonctionnalités requises pour isoler toutes les applications. Dans le texte, RedHat envisage le cas où un utilisateur ou un démon sont placés dans un chroot, pas une simple application. Parce que, sous Linux, ça n'a pas de sens : si on chroote vim, comment pourrait-il accéder au fichier qu'il doit éditer?
Mais, avec xchroot(2) qui manipule la partition /… , ça devient possible, et chez moi, c'est au niveau de chaque application que les xchroots sont utilisés. Et là, aucun usage des permissions UNIX ne permet d'obtenir ce résultat.
(Pour ceux qui ne comprennent pas : /… est une partition spéciale, dépourvue de toute réalité sur le disque dur (comme /proc), et dont le contenu varie selon le processus qui l'observe; chaque processus ayant la faculté d'associer les fichiers de son choix aux noms qu'il souhaite dans /… . Pour une illustration de son utilisation, voyez mon post un peu au dessus de celui-ci.)
[^] # Re: Intéressant
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 9.
Oui, désolé pour la confusion, c'est de ma faute. J'ai expliqué le modèle simplifié, alors qu'avec des applis dotés de fichiers de configuration problématiques, voire Turing-complets, le schéma sera différent. Milles excuses, je n'aurais pas dû prendre vim comme exemple.
Dans le cas de vim, on a deux groupes de fichiers spécifiques à un utilisateur : ceux relevant de l'historique des commandes (.viminfo), et ceux relevant de la configuration (.vimrc). Pour ceux de l'historique, ils seront bien en lecture-écriture par vim, sans autres formes de procès; du coup, un exploit jour zéro dedans permettrait une telle transmission de l'attaque. Heureusement, je ne crois pas qu'il existe de programmes dont les fichiers d'historiques soient Turing-complets - s'il en existait, il faudrait vraisemblablement les désactiver ou renoncer partiellement à la protection contre les exploits.
Par contre, les fichiers de configuration seront marqués lecture-seule-non-renommable-non-supprimable (côté implémentation, je pense que ce sera fait avec les attributs étendus), et l'application elle-même n'aura pas les privilèges requis pour retirer ou passer outre ce marquage. En revanche, le shell de l'utilisateur aura les privilèges requis pour les ignorer, et le lanceur de vim en fera usage pour marquer les fichiers à éditer de façon appropriée.
Voici une description du scénario, pour être plus clair :
Créateur des userdirs: tiens, on me demande de créer un userdir correspondant à l'uid 1017 pour le programme vim? Bon, c'est parti, je recopie l'userdir modèle et je le chown en 1017… Ah tiens, le fichier .vimrc du modèle est marqué lecture-seule-non-renommable-non-supprimable? Bon, je marque sa copie de la même façon.
Utilisateur: tiens, je vais éditer mon fichier de conf' vim, ça faisait longtemps. Alors, vim ~/userdirs/std/0.0.1/vim/7.3/vim/.vimrc … (Oui, je sais, le chemin n'est pas pratique. On pourra sans doute proposer à l'utilisateur d'ajouter des liens matériels dans son $HOME pour lui simplifier le travail, à condition qu'il n'utilise qu'une seule version de vim ou de ses fichiers de conf'.)
Shell : "vim ~/userdirs/std/0.0.1/vim/7.3/vim/.vimrc", vous dites? OK, fork(), et execve() sur /usr/bin/vim.
Lanceur de vim : Je ne suis pas vim, mais son lanceur! Bon, au vu de la ligne de commande, je dois éditer le fichier ~/userdirs/std/0.0.1/vim/7.3/vim/.vimrc . Soit. J'appelle xchroot(), et je lui demande de créer une entrée dans mon répertoire /… correspondant au fichier .vimrc correspondant, et simultanément, de me changer de chroot au profit de celui du vrai vim. Ah, et je marque l'entrée de /… de ce fichier avec le flag BYPASS_READONLY_NOREMOVE.
Noyau : D'accord pour le flag BYPASS_READONLY_NOREMOVE, tu as les privilèges requis, mais xchroot() implique chdir(), donc ton nouveau chemin courant devient la racine du chroot de vim.
Lanceur de vim : C'était prévu! Maintenant, capset(ABANDONNE, BYPASS_READONLY_NOREMOVE);
Noyau : Pas de problème, j'ai l'esprit large, j'autorise n'importe qui à diminuer ses privilèges.
Lanceur de vim : et maintenant, execve() sur /usr/bin/vim !
Vim : Ah, tiens, je dois éditer le fichier /…/home/username/userdirs/std/0.0.1/vim/7.3/vim/.vimrc . Bon, open() dessus…
Noyau : Ah, il est marqué lecture-seule-non-renommable-non-supprimable dans le système de fichiers, mais BYPASS_READONLY_NOREMOVE dans ton entrée /… . Bon, d'accord, tu peux l'éditer, je ferme les yeux.
Utilisateur : Ben voilà, ça marche très bien!
Maintenant, le scénario d'attaque :
Utilisateur : Tiens, je vais éditer /…/home/username/ultra_piégé_dans_tous_les_sens.txt .
Shell : Bon, ben, j'obéis, mais là, je ne réponds de rien, hein… fork(), et execve() sur /usr/bin/vim.
Lanceur de vim : Je ne suis pas vim, mais son lanceur! Bon, au vu de la ligne de commande, je dois éditer le fichier /…/home/username/ultra_piégé_dans_tous_les_sens.txt . Ben dis donc, y'en a vraiment qui ne manquent pas d'air, ici! Mais soit. J'appelle xchroot(), et je lui demande de créer une entrée dans mon répertoire /… correspondant au fichier ultra_piégé_dans_tous_les_sens.txt, et simultanément, de me changer de chroot au profit de celui du vrai vim. Ah, et je marque l'entrée de /… de ce fichier avec le flag BYPASS_READONLY_NOREMOVE.
Noyau : D'accord pour le flag BYPASS_READONLY_NOREMOVE, tu as les privilèges requis, mais xchroot() implique chdir(), donc ton nouveau chemin courant devient la racine du chroot de vim.
Lanceur de vim : C'était prévu! Maintenant, capset(ABANDONNE, BYPASS_READONLY_NOREMOVE);
Noyau : Pas de problème, j'ai toujours l'esprit large, j'autorise n'importe qui à diminuer ses privilèges.
Lanceur de vim : et maintenant, execve() sur /usr/bin/vim !
Vim : Ah, tiens, je dois éditer le fichier /…/home/username/ultra_piégé_dans_tous_les_sens.txt . Bon, open() dessus…
Noyau : Ah, il ne comporte pas de marquage particulier dans le système de fichiers, donc, c'est bon, vas-y. (Oui, l'entrée est marquée BYPASS_READONLY_NOREMOVE dans /… , mais je m'en moque, ça ne change rien.)
Vim : Je l'ouvre, et…. Aaaaaaaaaaaaargh, un Balrog!
Balrog : Hahahahaha! Maintenant, j'ai le contrôle de vim! Tremblez, mortels! Tout d'abord, modifions son fichier de configuration…
Noyau : Bien essayé, mais il est marqué lecture-seule-non-renommable-non-supprimable, et tu viens de te débarrasser des privilèges requis pour l'ignorer.
Balrog : Koa?! Eh bien, rends-moi mes privilèges!
Noyau : j'ai l'esprit large, mais pas à ce point. Va voir dans la Moria si j'y suis, permission denied.
Balrog : Que?! Alors, retire ce marquage!
Noyau : De nos jours, les démons ne doutent plus de rien. Cause toujours, permission denied.
Balrog : Heu… Et… Il me reste quoi, comme droits, au juste?
Noyau : Bon, il n'y a pas d'appel-système pour te fournir d'un coup une telle analyse, mais je vais te répondre quand même. Tu as le droit d'éditer le fichier dont tu es issu, ainsi que l'historique des commandes de cet utilisateur. Tu as aussi le droit d'exécuter vim, de réduire la taille de ton chroot ainsi que tes privilèges, et d'appeler exit(2).
Balrog [fait une dépression nerveuse]
Bon, en pratique, l'attaquant pourrais tenter sa chance en recopiant le code d'exploit dans le fichier d'historique au niveau du tampon de copier-coller de vim, à condition que son exploit soit compatible avec le passage par ce tampon, et que soit la seule lecture de l'exploit dans le fichier d'historique suffise à l'exploiter, soit qu'il parvienne à amener l'utilisateur à le coller quelque part. C'est vrai, et donc certaines classes rares d'exploits pourront théoriquement progresser, très lentement, à travers le système (à moins que l'utilisateur, ou sa distribution, ne désactive le fichier d'historique).
Mais ce ne sera pas discret (trace claire dans le système de fichiers), ce sera lent (ce qui est catastrophique pour un exploit jour zéro, qui repose justement sur la vitesse d'action), et seul un très faible sous-ensemble des exploits précédents pourront tenter des choses de ce genre.
Mais c'est vrai, dans l'absolu, tu as raison, pour les applications dotées de fichiers spécifiques à un utilisateur modifiables par l'application elle-même sans ordre explicite, la sécurité ne sera pas absolument parfaite. D'ailleurs, un exploit noyau aussi, ça suffirait à passer. Mais elle sera renforcée, et très significativement; et pour la plupart des applications, elle sera complète hors bogue noyau.
[^] # Re: Intéressant
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 4.
Ah, et je précise : même s'il y avait deux sessions de vim simultanées, tournant dans le même chroot, l'une éditant ton fichier piégé, l'autre mon /etc/shadow, ton exploit ne parviendrait pas à passer de l'une à l'autre.
A moins bien sûr que tu n'aies un second exploit jour zéro touchant cette fois les fichiers de configuration de vim. Mais même dans ce cas, les progrès seront très lents, le risque de détection réel (on ne cache pas un exploit dans des fichiers de conf comme ça), et il n'y aura toujours pas d'accès au réseau.
[^] # Re: Intéressant
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 7.
En effet. Il ne s'agit pas d'empêcher les exploits, mais de les encaisser, c'est-à-dire d'empêcher les attaquants d'en tirer profit.
Par exemple, si tu trouvais un exploit jour zéro dans vim, que tu m'envoyais un fichier texte qui en tirait profit, et que je l'ouvrais sous Manux, ton exploit serait entièrement bloqué. Il aurait juste accès au chroot de vim, en lecture seule, ce qui ne sert à rien, et à ton fichier en lecture-écriture, ce qui est tout aussi inutile. Si, à la rigueur, il pourrait changer mes fichiers de préférences vim… La belle affaire.
Bref, rien à voir avec un système classique, où un tel exploit donnerait accès à tout mon compte et au réseau par dessus le marché.
[^] # Re: Intéressant
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 8.
Bien sûr, c'est pareil chez moi! Mais seul mon format de paquetage comporte les fonctionnalités requises pour faire usage des protections contre les exploits jour zéro, donc tous les autres sont inadaptés.
Pour ce qui est d'installer des programmes quelconques en espace utilisateur, pas de problème; l'interface graphique, en revanche, je ne peux rien promettre. Le jour venu, on verra comment tout ça s'assemblera.
Oui, et bien, justement. Cette liberté, Linux la fournit, et c'est très bien ainsi, par ce que cela signifie qu'il existe un système libre qui la fournit. Mais quel système libre existe-t-il qui ne propose PAS ce choix? Je suis parfaitement sérieux. Au méta-niveau, est-ce que l'utilisateur a le choix, actuellement, d'opter pour un logiciel libre qui ne lui donnera PAS d'autres choix? Non. Et pourtant, ça n'a rien d'absurde!
Chez nous, on dit : "Wer die Wahl hat, hat die Qual", ce qui signifie approximativement que celui qui a le choix a aussi toutes les difficultés liées au choix. En fournissant un système qui ne laisse pas ce choix, j'évite aussi de fournir ces difficultés, et j'accrois le niveau général de choix dans le logiciel libre (puisque celui qui veut le choix, bah, il a déjà Linux, et avec mon cher système, il pourra aussi choisir de ne plus en avoir).
Mais bon, inutile de discuter de ce point plus avant. Moi-même, je ne sais pas comment l'interface graphique sera faite, donc, notre discussion n'apporte rien; au final, ce sont les contraintes techniques qui auront le maître mot.
Oui et non. Si tu regardes leurs exemples de code, tu verras que ce n'est pas du tout Linuxien. Manifestement, ils utilisent Linux pour le support matériel, mais ils n'exposent pas ses interfaces à leurs propres applications.
Deux raisons. Primo, quand j'ai commencé, je voulais apprendre comment marchait Linux, et je ne pensais pas parvenir au stade où j'en suis. Deuxio, quand c'est devenu difficile, il a fallu que je fasse énormément d'analyses et de recherches, et je n'aurais vraiment pas pu les faire dans une langue étrangère. Je me souviens encore quand je parcourais le dictionnaire, pour essayer de mettre des mots sur ce que je faisais…
Pour innover, il faut avoir l'esprit aussi clair que possible. Mais bon, maintenant que c'est fait, la traduction en anglais est envisageable.
[^] # Re: Intéressant
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 10.
Merci, ça fait plaisir :-) .
Je vais essayer de te répondre :
Comme je l'ai mis dans la FAQ, le système de paquetage est vraiment intégré au système d'exploitation. Linux utilise juste les paquetages pour vérifier qu'il a bien toutes les dépendances d'un programme installées; moi, je m'en sers pour construire chaque chroot et mettre en place les lanceurs de chaque programme. C'est vraiment une intégration profonde et incontournable.
Cela n'exclut pas l'existence de distributions fondées sur le système, bien au contraire. Simplement, s'il s'en crée, elles seront moins éloignées entre elles que les distribs Linux. En échange, elles seront toutes intercompatibles.
Bon, d'abord, pour l'instant, je n'ai pas d'UI, hein :-). Pour ce qui est d'adapter, oui, je suis entièrement pour; des thèmes divers comme dans fluxbox, des favoris, tout ça, ça m'a l'air très bien; le problème, c'est quand on va plus loin. Les membres de ma famille ne sont vraiment, mais alors vraiment pas portés sur la technique (ils sont tous littéraires), donc je peux voir comment des utilisateurs "normaux" se comportent. Eh bien, rien qu'un simple déplacement d'un menu, ça suffit à les perturber au point de leur faire renoncer à utiliser un logiciel. (Et pas la peine de lancer un troll, non-non, ce sont des gens très compétents. Mais dans leurs domaines.) Alors, franchement, une floraison d'interfaces comme sous Linux… Et quand un utilisateur se retrouve perdu parce qu'il est allé sur le poste d'un autre, et qu'il ne reconnaît plus rien, malheureusement, oui, il y a un problème.
Il faut être réaliste : c'est nous, les Linuxiens, qui sommes des anomalies, et ce sont les non-informaticiens qui sont la norme. Et puis, de toutes façons, les informaticiens s'en tireront toujours avec la ligne de commande, alors…
Ah, d'ailleurs, ça me fait penser à une autre règle de conception. Lorsqu'il y aura une UI, la règle sera : le système d'exploitation doit avoir une configuration par défaut adaptée aux besoins des utilisateurs n'ayant pas assez de connaissances techniques pour modifier cette configuration.
Ah, non, en effet. Je vais y jeter un œil, mais à priori, il y a des différences importantes entre leur projet et le mien. D'abord, c'est un projet à micro-noyau fondé sur L4, et ça, ça me laisse perplexe (L4 ne dispose pas des primitives requises pour implémenter efficacement les opérations de la classe select(2); rendons à César ce qui lui appartient, c'est le projet Hurd qui l'a découvert). De plus, Manux est vraiment compatible binairement avec Linux, donc là aussi, les deux projets s'écartent fortement.
Pour le reste, les APIs publiées par ce projet sont insuffisantes pour l'évaluer (il n'y a que les APIs de type micro-noyau, pas de table d'appels-systèmes comparable en termes d'abstractions avec celle de Linux), mais je pense qu'ils se dirigent plutôt vers un système du type Hurd-NG que Linux.
Ah, et L4 n'est pas patchable dynamiquement. Mon noyau, si :-) .
(P.S. : Pour ceux qui s'interrogent, mes commentaires sont à 0 parce que c'est ma note par défaut, je viens de créer ce compte pour faire cette annonce.)
[^] # Re: Intéressant :)
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 10.
En fait, je ne m'attends pas vraiment à avoir beaucoup de contributions. Mais c'est sans importance : j'y ai travaillé seul durant des années, et je compte bien continuer quoi qu'il en soit.
C'est vrai, mais une chose à la fois. Pour l'instant, le plus urgent, c'est de documenter les interfaces internes du noyau; et je compte bien le faire en anglais.
Ça, c'est un problème plus complexe qu'il n'en a l'air. Ce n'est pas simple de faire une licence libre entièrement légale. Par exemple, si on applique vraiment, vraiment strictement les principes de Debian, la GPL est non-libre.
En effet, comme elle ne comporte pas de choix de loi applicable, on peut lui appliquer le droit que l'on veut; donc en particulier le droit français. Mais en droit français, en vertu de l'article 46 du code de procédure civile, les tribunaux ayant compétence en matière délictuelle incluent ceux dans lesquels le fait dommageable a été subi.
Le problème survient lorsqu'un plaignant déclare avoir subi des dommages du fait d'une diffusion illégale par internet. Comme internet est disponible dans toutes les juridictions françaises, il suffit au plaignant de trouver un cas de téléchargement dans la juridiction de son choix pour rendre le tribunal territorialement compétent. Résultat, un joli "choice of venue" applicable à tous les tribunaux français, DOMs-TOMs compris, qui viole directement le test "Tentacles of Evil" de Debian.
Le cas ne s'est jamais produit, tant mieux, et je ne suis pas là pour lancer un troll contre la GPL. Mais le fait est que ce n'est pas en simplifiant les licences qu'on améliore la condition des utilisateurs. C'est vrai, ma licence est complexe, mais sa complexité répond à la complexité du monde réel. Comme le disait H.L. Mencken : "For every complex problem, there is a solution which is simple, neat, and wrong".
Rien du tout! Mais bon, le projet n'est pas gros à ce point :-). S'il le devient, je mettrai ce genre de choses en place… Mais on n'en est pas là.
[^] # Re: Intéressant :)
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 5.
Les iopls, c'est une chose, mais impossible d'exprimer une relation du genre "l'application A a le droit de faire une copie d'écran, mais pas l'application B, et quant à C, elle en a le droit, mais lorsqu'elle en fait une, elle doit être falsifiée de telle sorte qu'elle se croie la seule application active".
Pour ça, il faut vraiment placer le serveur graphique en espace noyau.
[^] # Re: Intéressant :)
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 6.
Effectivement, tu as raison. Je vais mettre la FAQ à jour. Rien de tel qu'un regard extérieur pour améliorer les choses!
Je vais le mettre aussi dans la FAQ, mais globalement, ce sera non. Il faut que le serveur graphique soit intégré au noyau pour pouvoir gérer les privilèges des applications; et de toutes façons, architecturalement, il n'a rien à faire en espace utilisateur.
En revanche, ceci n'exclut pas que cette future interface graphique soit partiellement ou totalement compatible avec l'un de ces protocoles. Sur ce point, je ne les ai pas encore assez étudiés pour pouvoir me prononcer.
En fait, le gfe est l'un de mes modules, et les bordereaux sont l'un des concepts du noyau, pour permettre le patchage dynamique (une zone de données dont la position est invariable, chaque module a le sien). Quant au flot d'exécution inactif, il s'agit du fe qui fait en boucle while (1) asm volatile ("hlt"); , pour éviter de consommer inutilement des ressources lorsque le processeur n'a rien à faire.
[^] # Re: Intéressant :)
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 10.
Oui, incontestablement. Mais, quand je m'y suis mis, je ne pensais pas que j'irais si loin…
Cela dit, j'accepte les contributions en anglais, et il y a aussi un avantage à la chose : tant que les interfaces internes du noyau seront en français, il faudra les garder bien documentées. (Honte sur moi, faut que je m'y mette…)
En ce qui concerne le format de paquetage, il y a vraiment des motifs techniques pour n'utiliser que celui-là, parce que la logique des chroots lui est liée. En fait, le système de paquetages utilise l'arbre des dépendances d'un programme pour construire son chroot et ses lanceurs, donc aucun format de paquetage existant ne peut le concurrencer.
Quant à l'interface graphique, je ne pouvais pas accepter X.org : avec son appel-système iopl(2), il met l'ensemble des protections du système par terre (et, accessoirement, il est incapable de gérer l'isolement et les privilèges des applications). Donc, une nouvelle interface sera nécessaire… donc autant l'unifier.
Et puis, les forks… On disait la même chose au début de Linux, alors… :-)
Hmmm… Oui, effectivement. Cela dit, si ça devenait vraiment gênant, la clause de mise à jour de la licence ne m'interdit pas de supprimer cette disposition. On verra, mais je pense que les avantages dépasseront les inconvénients.
Non, mais pas loin :-) . Il s'agit du code du flot d'exécution inactif et du code pour le lancer; ils sont situés dans le bordereau du gfe. Ils doivent s'y trouver, parce qu'en cas de patchage du noyau, le code du flot d'exécution inactif doit demeurer au même emplacement.
[^] # Re: sync
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 4.
Oui, effectivement, ça marche, mais ça va dégrader les performances lors des recompilations. Et puis, comme vim fait de toutes façons un sync() lorsqu'il enregistre, et que le noyau n'est pas si instable que ça, le faire manuellement est suffisant.
Pour tout dire, j'ai souvent (genre une fois sur 10) des plantages du noyau lors des réinstallations; mais côté plantages une fois installé, là, je dois bien dire que je ne sais plus de quand date mon dernier. Un bon bout de temps, en tout cas.
[^] # Re: émotion
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.1. Évalué à 7.
Du souvenir? Ce n'est pas un faux, il est bien réel!
# Et Mme Michu?
Posté par Emmanuel Colbus . En réponse au journal Si je devais voter en ligne. Évalué à 2.
Mme Michu, qui n'est pas du tout favorable au plan proposé par son incapable de mari, décide de faire échouer celui-ci. Durant la phase d'échange des UIDs, elle prend note de tous ceux qui passent et se met à reproduire sans cesse le même (pas le sien, hein, faut pas se faire prendre non plus). De la sorte, lors de la phase de vérification, 174 votants constatent qu'ils ont le même UID que 173 autres personnes, les empêchant ainsi de vérifier que leur vote a bien été pris en compte. Le vote est donc annulé, et Mme Michu peut retourner à ses rosiers pendant que M. Michu se demande qui a bien pu lui faire un coup pareil, halala, heureusement que j'ai ma femme pour me consoler, hein.
Reconnaissons-le, l'anonymat a bien été garanti… Dommage que ce soit en faveur de l'attaquant.