Bonjour tout le monde!
Je voudrais profiter de ce journal pour vous présenter mon projet personnel : Manux version 0.0.1.
Il s'agit d'un système d'exploitation, pour l'instant très limité, conçu pour encaisser les exploits jour zéro en espace utilisateur, et renforcé face aux exploits noyau. Son noyau, ainsi que les éléments du cœur du système (comme le système de paquetages), ont été entièrement écrits de zéro par mes soins. Son architecture est très différente de celle des autres systèmes d'exploitation (forcément, à chrooter la totalité des processus…); malgré cela, il est en compatibilité binaire native avec Linux.
De plus, cette architecture lui permet des opérations spéciales. Par exemple, il n'a aucun problème à faire cohabiter deux versions distinctes et théoriquement incompatibles de la libc (puisque tout le monde est chrooté!), ou d'autres bibliothèques ou logiciels qui ne devraient normalement pas pouvoir fonctionner sur la même machine.
Avantage induit au passage, normalement, si un logiciel fonctionne sous une distribution Manux, il fonctionnera sous toutes les distributions Manux existantes. Cela signifie qu'il constituera toujours une plateforme unifiée, ce qui facilitera le travail des développeurs.
Autre point : le noyau est intégralement patchable dynamiquement. Ce n'est pas pour faire des concours d'uptime (d'ailleurs, il arrivera vraisemblablement que des modifications incompatibles lui soient appliquées dans l'avenir, obligeant au redémarrage), mais pour éviter aux utilisateurs d'avoir à faire des compromis entre la disponibilité du service et la sécurité.
Accessoirement, l'architecture du noyau permet de l'étudier et de le reconfigurer dynamiquement. De la sorte, les considérations habituelles qui justifiaient le placement du serveur graphique en espace utilisateur ne s'y appliquent pas.
Je l'ai placé sous une licence libre, mais différente de celles qui existent actuellement. En plus d'être récursive comme la GPL, elle est conçue pour permettre sa commercialisation sous le modèle du "logiciel comme un produit", mais en restant libre. Ceci est expliqué plus en détails sur cette page . Mais bon, ça, ce sera si le logiciel a du succès :-) .
Du point de vue utilisation, comme je le disais, il est actuellement très limité : mode texte uniquement, pile réseau non fonctionnelle, pas d'USB (mais certains claviers USB marchent quand même, je suppose que certains matériels font la traduction USB=>PS/2), privilèges non implémentés(1), etc… Cela dit, il est déjà auto-hébergé, ne nécessitant Linux que pour sa réinstallation. A titre d'exemple, je tape cette annonce sous Manux, dans vim (mais je vais la poster avec Linux, évidemment).
Autre mauvaise nouvelle : il n'est pas entièrement compatible avec Linux. En effet, il est bien compatible binairement, mais pas architecturalement, ce qui signifie qu'il ne sera jamais possible de porter une distribution Linux sous Manux (ou d'utiliser son noyau en remplacement d'un noyau Linux). De plus, comme je refuse de porter X.org (pour des raisons détaillées dans la page de manuel x11.9 des sources), ni Gnome, ni KDE, ni XFCE, ni même Twm ne pourront jamais être portés dessus; et s'il se dote un jour d'une interface graphique, je compte faire en sorte qu'il n'en ait qu'une seule, unifiée, pour faciliter la vie des utilisateurs du mode graphique. Enfin, les distributions (s'il s'en crée) n'auront jamais la même indépendance que sous Linux; c'est indispensable pour conserver l'unicité de la plateforme. A titre d'exemple, il ne sera jamais possible d'utiliser un autre format de paquetage que celui prévu.
Bref, fondamentalement, il s'agit d'un système d'exploitation et d'une philosophie très différents de ceux de Linux. Ce qui n'entrave pas la compatibilité, d'ailleurs, tous les logiciels externes que j'y utilise (bash, vim, gcc, les coreutils, etc…) sont des logiciels Linux non recompilés.
S'il vous intéresse, essayez-le! Vous n'avez besoin que de télécharger l'installeur, de l'exécuter, et de configurer Grub ou Grub2 comme indiqué dans son répertoire doc/. Il vous faudra un ordinateur x86, un disque dur compatible ide (ATA/ATAPI/SATA, pas de SCSI), et une partition libre. Au premier démarrage, le système s'auto-installe; chez moi, cela prend 15 à 25 minutes selon le matériel. Cette phase est indispensable pour établir les liens matériels vers les répertoires et les liens racines que l'installeur Linux ne peut pas créer, puisque Linux ignore ces notions; ensuite, chaque démarrage prend quelques secondes.
Voilà! Si vous avez des questions auxquelles la documentation du site ne répond pas, vous pouvez me les poser ici, ou me contacter comme indiqué sur cette page .
Emmanuel
(1) Oui, je sais, j'aurais pu implémenter les privilèges, mais j'ai estimé que ce n'était pas une chose très importante, et que ça ne valait pas le coup de repousser sa publication pour ça. Ce n'est qu'une version 0.0.1, ne l'oublions pas!
Ah, en bonus, voici les commandes que je tape pour l'installer, et un exemple de session :
ecolbus@linux:~$ tar -xzf installer.tar.gz
ecolbus@linux:~$ su -
root@linux:~# ~ecolbus/installer/installer --device /dev/sda3 --username ecolbus --hostname orion
[Préinstallation...]
# A présent, pour une première installation, appliquer les instructions de
# ./docs/fr/grub2 (ou ./docs/fr/grub1).)
# Ne pas oublier de regénérer la configuration de grub, avec update-grub ...
root@linux:~# init 0
# Surtout pas init 6 : le redémarrage _doit_ être électrique; sinon,
# le clavier se blo
# Reboot sur la nouvelle entrée grub...
# Préinstallation, environ 20 minutes...
orion tty1
login: ecolbus
Your password has expired. Choose a new password.
Changing password for ecolbus
Enter the new password (minimum of 5 characters)
Please use a combination of upper and lower case letters and numbers.
New password:
Re-enter new password:
passwd: password changed.
No mail.
-bash: cannot set terminal process group (-1): Inappropriate ioctl for device
-bash: no job control in this shell
readline: warning: turning off output flushing
readline: warning: turning off output flushing
ecolbus@orion:~$
# A présent que le système est installé, voici un exemple de session :
# Bien sûr, les deux commandes qui suivent, je n'ai pas à les
# retaper à chaque fois.
ecolbus@orion:~$ mknod hd0,5 b 0 0 # Mon /home Linux est sur /dev/sda6
ecolbus@orion:~$ mkdir mnt5
ecolbus@orion:~$ admin
ecolbus@orion:~# smount -t ext2 hd0,5 mnt5
ecolbus@orion:~# unadmin
ecolbus@orion:~$ cd mnt5/ecolbus
# Là, je suis dans mon homedir Linux.
ecolbus@orion:[]$ cd manux+std/manux
ecolbus@orion:[]$ ls
docs libsys make noyau scripts tmp
éphémodules Licences Makefile outils scripts_ld usr
inclus lnc man packages tests
ecolbus@orion:[]$ ./make
[Autorecompilation du noyau et des principaux binaires...]
ecolbus@orion:[]$ admin
ecolbus@orion:[]# ./scripts/maj_noyau.sh
[Mise à jour dynamique du noyau]
ecolbus@orion:[]# unadmin
ecolbus@orion:[]$ vim ./noyau/ext2/main.c
ecolbus@orion:[]$ ./make ext2
[Recompilation d'ext2...]
ecolbus@orion:[]$ ./make éphémodules/divers/hw # Juste pour la démonstration
ecolbus@orion:[]$ admin
ecolbus@orion:[]# patch_kernel ext2
ecolbus@orion:[]# patch_kernel éphémodules/divers/hw
ecolbus@orion:[]# test_sys
Hello World!
0
# A la fin, pour éteindre la machine :
ecolbus@orion:~$ admin
ecolbus@orion:~# init 0 ; exit
Voilà! Si vous avez des questions, n'hésitez pas; et si vous avez des insultes, sachez que même /dev/null est fonctionnel!
(Ah, et j'y songe, quand vous l'utilisez, pensez à faire des "sync" réguliers. Je n'ai pas implémenté l'écriture sur disque au bout de quelques secondes, et le noyau comporte malheureusement encore des bogues… Honte sur moi et ma descendance jusqu'à la zéroïème génération (non incluse - pas folle, la guêpe).)
# émotion
Posté par J Avd . Évalué à 2.
C'est du pur souvenir de moule… Merci !
"Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"
[^] # Re: émotion
Posté par Emmanuel Colbus . Évalué à 7.
Du souvenir? Ce n'est pas un faux, il est bien réel!
[^] # Re: émotion
Posté par fravashyo . Évalué à 10.
« Manux: just a hobby, won't be big and professional like linux »
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: émotion
Posté par Spack . Évalué à 10.
Avec Manux, le plaisir reste protégé et dure plus longtemps…
[^] # Re: émotion
Posté par Tonton Th (Mastodon) . Évalué à 4.
Pfieuuu, c'est un gag vieux comme le monde…
[^] # Re: émotion
Posté par reynum (site web personnel) . Évalué à 2.
J'ai honte mais j'ai ri :-D
kentoc'h mervel eget bezan saotred
[^] # Re: émotion
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 10.
Manux ? Souvenir de moule ?
T'es sûr que tu parles pas de Manix ?
Je
-->[](Ok, bon, cet art ascii est encore plus suggestif, maintenant !)
# sync
Posté par Anonyme . Évalué à 1. Dernière modification le 15 août 2013 à 11:56.
« Ah, et j'y songe, quand vous l'utilisez, pensez à faire des "sync" réguliers. Je n'ai pas implémenté l'écriture sur disque au bout de quelques secondes […] »
Si on peut faire un script qui tourne en arrière plan alors c'est bon :°
[^] # Re: sync
Posté par Emmanuel Colbus . É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.
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Intéressant :)
Posté par Emmanuel Colbus . É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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5. Dernière modification le 15 août 2013 à 12:36.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Intéressant :)
Posté par Emmanuel Colbus . É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 Joris Dedieu (site web personnel) . Évalué à 2.
Il me semblait pourtant que Wayland répondait très précisément au problème des iopl.
[^] # Re: Intéressant :)
Posté par Emmanuel Colbus . É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 Mildred (site web personnel) . Évalué à 4.
Il me semble que justement wayland a une solution pour ce problème, tout en restant en espace utilisateur. Les applications sous le compositeur seront limitées à ce niveau, sauf les application que le compositeur a choisies.
Au final, il y a une hiérarchisation, où le compositeur agit en quelque sorte comme un processus privilégié (tout en restant confiné a l'espace utilisateur) qui a pour rôle d'arbitrer les processus clients.
[^] # Re: Intéressant :)
Posté par Joris Dedieu (site web personnel) . Évalué à 8.
Je ne pense pas que tu auras beaucoup des contributions dans ces conditions.
Je pense que tu devrais publier sur une forge et t'empresser de traduire le code et les commentaires. Sinon ton projet qui a l'air bien sympa va rater sa cible.
[^] # Re: Intéressant :)
Posté par Emmanuel Colbus . É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 Anonyme . Évalué à 7.
Un gestionnaire de version ça serait quand même cool. Enfin, ça m'étonnerais que tu n'en utilise pas localement, mais le mettre à disposition sur Internet ce serait chouette.
En ce qui me concerne ça ne changera rien parce que de toute façon je ne pense pas aller mettre le nez dans le code bien souvent…
# Intéressant
Posté par lordblackfox . Évalué à 5.
Juste un WAW pour commencer, j'examinerai tes sources plus tard, mais en tout cas, ça promet d'être excitant :)
J'ai juste quelques questions/remarques:
- 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 ?
- 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).
- Pourquoi ne pas profiter des projets existants, et plutôt intégrer du Wayland par exemple—ou encore se baser sur d'autres projets histoire de concentrer sur l'essentiel?
- BTW, tu connais Genode? ( http://genode.org/ ) Ça pourrait pas mal t'intéresser :)
En tout cas, bravo!
[^] # Re: Intéressant
Posté par Emmanuel Colbus . É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 lordblackfox . Évalué à 5.
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.
Pour l'UI, je ne parle pas spécialement de thème ou de config; Les différences entre les gestionnaires de bureau/fenêtre par exemple sont bien plus larges, sur le point de la conception, de l'ergonomie, de l'utilisation, et des concepts inhérents aux projets (par exemple le Plasma sous KDE n'a rien à voir avec le bureau à la Gnome3).
La question du passage d'une UI à une autre comme argument de la nécessité de tout unifier n'est pas pertinente, parce qu'elle ne prend pas en compte deux aspects importants: la liberté de l'utilisateur et l'apprentissage d'une interface. Le libre ne se résume pas à fournir le code source, filer les 4 libertés et basta. C'est aussi permettre à l'utilisateur d'avoir la liberté de maîtriser sa machine et ce qui tourne dessus; 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.
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.
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.
Juste une dernière question: pourquoi avoir codé en français?
Bonne chance pour la suite
[^] # Re: Intéressant
Posté par Emmanuel Colbus . É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 patrick_g (site web personnel) . Évalué à 10.
Tu peux détailler s'il te plaît ? Parce que même en lisant ta documentation je n'ai pas compris en quoi ton projet permet de se protéger contre les exploits. C'est le fait de tout mettre dans des chroots ?
[^] # Re: Intéressant
Posté par Emmanuel Colbus . É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 . É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 ckyl . Évalué à 7.
Heu les fichiers de configuration de Vim sont turing complet…
Et c'est bien la que je ne vois pas comment ton truc peu marcher par ce que c'est simple il y a deux solutions:
Soit tu as des environnements, donc applications pour toi, entièrement isolés qui ne peuvent jamais se parler et la tu contients les débordements dans chaque environnement.
Soit tes environnements ont moyens de se parler (accès à un seul même fichier éditable dans l'un et lisible dans l'autre) et la c'est game over pour la sécu. À partir du moment ou tu as à access au FS d'un uid il est compromis.
Donc si on résume soit tu as un truc totallement inutilisable vu que tu segmentes par appliquation, ca me fait une belle jambe d'avoir un vim tout seul dans son coin… Soit tu as un truc pas plus secure que n'importe quel autre système.
C'est bien pour ca qu'usuellement on cloisone par unité logique. Tu pourrais vraiment nous expliquer correctement ton truc au moins conceptuellement ? On pourra regarder si la technique suit après.
[^] # Re: Intéressant
Posté par patrick_g (site web personnel) . Évalué à 8.
Et puis il y a aussi le fait que chroot n'est pas fait pour la sécurité. Cela a été dit et répété des centaines de fois.
Citation d'Alan Cox : chroot is not and never has been a security tool.
On trouve pleins d'articles sur le net pour mettre en garde les gens (un exemple au hasard).
La solution pour sécuriser les applications c'est un module MAC (SELinux ou Apparmor ou autres).
[^] # Re: Intéressant
Posté par Larry Cow . Évalué à 7.
En même temps, il (Emmanuel) parle de chroot dans un contexte non-Linux, probablement même pas complètement POSIX. Bref, il faut à mon avis lire "chroot" comme "technologie d'isolation" (dont les caractéristiques restent à définir, et qui selon ce qu'elle isole peut n'être qu'un équivalent à chroot()). Et pas comme "appel système chroot() qu'on connaît bien et qui n'isole que le FS, et encore".
[^] # Re: Intéressant
Posté par Emmanuel Colbus . É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 . É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 Larry Cow . Évalué à 3.
Euh, ipython par exemple, et peut-être même l’interpréteur python de base (je ne suis pas certain que ce dernier ait un historique par défaut, mais ça peut peut-être s'activer).
[^] # Re: Intéressant
Posté par Emmanuel Colbus . É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: Intéressant
Posté par Larry Cow . Évalué à 2.
Connaissant Python et son manque total de mécanismes de sécurité (je ne l'en aime pas moins, note bien), je ne serais pas outrageusement surpris que l'animal (IPython) mette à disposition des fonctions permettant de modifier son "autoexec"-like. Introspection, tout ça.
Et si lui ne le fait pas, on n'est pas forcément à l'abri d'un qui le fasse. Avec la mode d'embarquer des langages de script…
Après tout, Firefox lui-même peut modifier son prefs.js, lequel est exécuté au démarrage. Après, je ne pense pas que l'interface fournisse des moyens de rajouter autre chose que des appels à user_pref() dans le fichier. Mais si l'attaquant parvient à l'en convaindre…
[^] # Re: Intéressant
Posté par Emmanuel Colbus . É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 patrick_g (site web personnel) . Évalué à 5.
Comme pour une distro Linux classique qui utilise SELinux (ou Apparmor) et Seccomp mode 2. Donc quel avantage significatif apporte ton OS sur le plan de la sécurité par rapport à ça ?
[^] # Re: Intéressant
Posté par Emmanuel Colbus . É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 Renault (site web personnel) . Évalué à 5.
Bah c'est logique, si cet accès est légitime, où est le problème ?
[^] # Re: Intéressant
Posté par Emmanuel Colbus . É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 Renault (site web personnel) . Évalué à 2.
Et si le PDF en question modifie le logiciel et que tu ouvres le document « secret » avec un tel logiciel nouvellement vérolé ?
Bah tu ne peux rien faire non plus.
Ta sécurité semble intéressante mais j'ai l'impression que tu la présentes comme invulnérable alors qu'en réalité il y a forcément des problèmes.
Une sécurité doit être le résultat d'un équilibre entre la simplicité d'utilisation et le niveau de protection souhaité. Qu'un lecteur de PDF ait accès à un PDF ne me semble pas du tout anormal même si ça induit des biais de sécurité. Mais dis toi que l'utilisateur pourra toujours ouvrir des failles et autres bêtises à son insu.
[^] # Re: Intéressant
Posté par Emmanuel Colbus . É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: Intéressant
Posté par ckyl . Évalué à 4.
Tu passes d'un truc à l'autre, c'est grossier là ;)
Empêcher de modifier le logiciel c'est faisable sans problème sur plein de systèmes (ou même tout ce qui n'est pas explicitement spécifié).
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. Mais tu dois faire un choix. Soit tu segmentes complétement, et ton système n'est pas utilisable pour autre chose que quelque chose d'extrêment spécifique (voir pas utilisable tout court faudrait y réfléchir vraiment). Soit tu ne segmentes pas tant que ca en mergant automatiquement en fin d'execution, en utilisant des mécanismes spéciaux etc. Et là ton truc est troué. Tu peux écrire sur le FS, comme sur un système classique…
[^] # Re: Intéressant
Posté par Emmanuel Colbus . É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 ckyl . Évalué à 7.
Dans la réponse sur mon autre commentaire tu nous expliques spécifiquement que ':w toto' ne fonctionne pas. Une application ne peut donc créer de nouveaux fichiers. Des petites fonctionalité genre "nouveau document" ou "Enregistrer sous". Des problèmes comme ca on peut en trouvé une infinité.
Soit je suis trop bête pour comprendre les subtilités de ton modèle et comment ca tient debout en dehors de "J'arrive à éditer mon fichier texte", soit ca ne tient pas debout pour un cas d'utilisation générique.
Sachant que tu as déjà commencer à introduire de nouveaux concepts type "il suffirait de patcher firefox pour", ou que l'exemple du ':!ls' ne te fasse pas percuter que c'est ce que les applications passent leur temps à faire j'ai un peu peur de ne pas être complétemment dans le faux. Si le seul truc qui reste c'est du MAC sur l'accès/écriture des fichiers, c'est techniquement faisable depuis longtemps juste presque impossible à mettre en oeuvre en dehors des démons.
[^] # Re: Intéressant
Posté par Emmanuel Colbus . Évalué à 5.
Si, mais seulement ceux dont le nom lui a été passé sur sa ligne de commande.
En revanche, pour des fonctionnalités du genre "nouveau document" ou "enregistrer sous", il faudra effectivement passer par un programme externe. Mais ça ne pose aucun problème : en effet, les programmes graphiques qui proposent ces fonctionnalités le font déjà en employant des bibliothèques (c'est pour ça que les apparences de ces boîtes de dialogue sont si semblables). Tout ce qu'il y aura à faire, c'est de fournir une bibliothèque appelant ce programme.
Hmmm… Quelles applications font ce genre de choses? Je veux dire, le lancement de commandes entièrement arbitraires. Je ne vois guère que les shells (gérés), les scripts de l'utilisateur (gérés), et les "make" (gérés).
En ce qui concerne les applications qui ont besoin de faire appel à une autre de façon prévisible, pas de problème : cela signifie que le second programme fait partie de leurs dépendances, et donc qu'ils ont dans leur racine un lien matériel vers le lanceur de ce programme.
Par exemple, si tu as un programme qui a une dépendance sur ls, alors il aura, dans sa racine, un fichier /bin/ls correspondant au lanceur de ls, qui lui permettra de le lancer à volonté, sans restrictions. Mais comme l'accès au lanceur d'un programme n'implique pas l'accès à son xchroot, cela laisse intacte la sécurité de l'application, comme celle de ls.
[^] # Re: Intéressant
Posté par ckyl . Évalué à 8.
J'avais donc bien compris où tu voulais en venir. Malheureusement je n'y crois pas une seule seconde pour un système généraliste. C'est soit inutilisable soit une passoire, encore plus si tu ne veux pas patcher tout l'userland.
D'un point de vu démon, c'est à peu près jouable. Mais soit tu vas obtenir quelque chose de moins fin que ce qui est possible via les policy MAC, soit plus casse gueule qu'une VM vu la complexité du bordel. Sachant que tout le reste du système est à refaire ca sent pas bon.
D'un point de vu utilisateur c'est mort. Les applications communiquent entre elles, sont intégrées, et ont des accès larges et légitimes au système de fichier. Déjà avec ton simple exemple de vim tout seul dans ton coin tu t'englues dans les explications en imaginant déjà des cas spéciaux de fichiers éditables ou non reposant sur des white/black-list par application et de lanceur spéciaux pour une application. Et là on à même commencé à parler de la fuite d'information. Un ':e' dans ton vim il peut ouvrir ou pas un fichier ? Si oui c'est mort. Un ':w' il marche ? Un ':!ls' il marche ? Alors c'est mort pour l'isolation. Si la réponse est non alors tu as un système simplement inutilisable. On se souvient que là on parle d'un pauvre éditeur de texte dans son coin. Ca va devenir rigolo en généralisant la chose, en introduisant les mécanismes d'IPC etc.
Les politiques MAC sont super contraignantes, c'est pour ca qu'elle reste confinée où elles font sens.
[^] # Re: Intéressant
Posté par Emmanuel Colbus . É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 fearan . Évalué à 3.
Mouais une façon de voir les choses; dans mon emacs il n'est pas rare d'avoir un grep (m-x grep) ou un shell (bash ou eshell), par ailleurs emacs a tendance à utiliser des commande externe comme svn, aspell, ispell, make, gcc, g++, javac… Possède un explorateur de fichier, à la possibilité d'en créer, supprimer…
Je vois un intérêt à ton système, mais pour certaines application, il lui faudrait un mode débridé, sinon le développement sera vite un enfer ;).
Autre question, comment se comporte le système sur plusieurs partition imaginons que je doives éditer 680Go de film sur partition A et 254Go de filme sur partition B?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Intéressant
Posté par Emmanuel Colbus . Évalué à 2.
Hélas… Le système lui-même n'est pas à proprement parler débridable (ou plus exactement, la version débridée s'appelle Linux).
Par contre, l'utilisateur peut facilement et automatiquement ajouter tout ce qu'il veut à un programme. Si tu crées un script ~/bin/mon_emacs qui injecte dans le PATH d'emacs toutes les commandes dont tu te sers habituellement, ça fonctionnera sans problème. C'est d'ailleurs ce que fait le binaire ./make des sources du noyau, pour donner à make accès au compilateur, à l'assembleur, à l'éditeur de liens, etc…
Pas de vraie différence par rapport à Linux; une même application peut accéder simultanément à des fichiers situés dans des partitions physiques séparées, c'est transparent. Sauf justement dans les cas où ce n'est pas transparent non plus sous Linux, comme pour les déplacer ou créer un lien matériel entre les deux.
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Woah !
Posté par ʭ ☯ . Évalué à 2.
Lol kikool… Doom fonctionne là-dessus? Et est-ce que l'isolation des processus va pas faire que les monstres reçoivent jamais les balles?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# Si je comprends bien on ne peut pas modifier un fichier sur le disque
Posté par fearan . Évalué à 6.
Sauf s'il est présent sur la ligne de commande, j'ai bon?
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.
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?
Comment fonctionne l'isolation ? C'est une copie des binaire ou des liens ? Au niveau encombrement mémoire ça se passe comment ?
Si un appli passe outre le read only des binaire nécessaire, est ce que ça impacte les autres?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Si je comprends bien on ne peut pas modifier un fichier sur le disque
Posté par Emmanuel Colbus . É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: Si je comprends bien on ne peut pas modifier un fichier sur le disque
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6.
Mais sur vim, qui était un exemple plus haut, comme je pense dans tout éditeur, tu peux aussi ouvrir un fichier après avoir démarré le programme! En général quand je code, j'ouvre un ou plusieurs fichiers, puis je me rends compte que je veux référencer tel ou tel dépendances donc j'ouvre ces autres fichiers depuis vim. Mais ces fichiers n’étaient pas sur la ligne de commande. Ça marche?
Aussi autre question, plus haut tu dis que le xchroot de vim n'aurait pas accès au reseau. Mais vim est un programme qui peut avoir accès au réseau. Si je tape:
$ vim http://linuxfr.org/users/ecolbus/journaux/annonce-manux-0-0-1
Ça curl le lien et me permet de lire le fichier html. Ce genre de fonctionnalité de vim serait tué? Ou bien tu permets certains accès au réseau mais pas d'autres (genre on peut downloader, pas d'upload, etc.)? Comment ça se détermine?
Enfin supposons que quelqu'un ouvre un fichier en étant root (parce qu'il ouvre des fichiers de conf système par exemple, et dans un split vim, il veut ouvrir ce qu'il croit être un fichier d'exemple mais contient en fait une attaque!), et comme on disait plus haut, y a une faille qui donne un contrôle sur vim. L'user dans le xchroot étant root, il ne peut pas tout faire? Même le root est limite? Ou il a tout les privilèges comme sous linux?
En tous cas, projet sympa. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Si je comprends bien on ne peut pas modifier un fichier sur le disque
Posté par Emmanuel Colbus . Évalué à 4.
Non. Des solutions pourront être mises en place dans l'avenir pour fournir cette fonctionnalité (comme je l'ai évoqué dans un autre commentaire); mais pour l'instant, ça ne marche pas. C'est incontestablement une limitation de mon système. J'estime simplement que les bénéfices tirés de l'accroissement de la sécurité en valent la peine.
En fait, non. Dans ce cas précis, tu as passé http://XXX sur la ligne de commande de ton lanceur, ce qui permet de comprendre ton intention d'accéder au réseau, par conséquent, le lanceur fournirait à cette instance de vim l'accès requis.
Je commencerais par faire remarquer que mon système n'a pas de root, et que les privilèges peuvent être donnés à n'importe quel utilisateur :-) . C'est documenté dans la FAQ, chapitre "comment peut-on passer root". Et il est impossible d'échapper d'un chroot, quel que soient les privilèges; une application "non chrootée", ça n'a pas vraiment de sens.
En revanche, avec son split dans vim et son ouverture d'un second fichier, l'utilisateur commettrait effectivement une erreur qui permet la propagation de l'attaque. Et c'est faisable, mais pas de la façon dont tu l'envisages : il faudrait passer à vim deux fichiers sur sa ligne de commande, et ensuite ouvrir le second dans le split.
Donc, oui, c'est vrai, c'est une autre faiblesse. Je pense que les utilisateurs apprendront (ou que les logiciels seront patchés pour parer à cela, par exemple en lançant une seconde instance d'eux-même dans ce genre de cas).
Mais effectivement, tu as raison : mon système peut encaisser bien des choses, mais pas ça.
[^] # Re: Si je comprends bien on ne peut pas modifier un fichier sur le disque
Posté par Jehan (site web personnel, Mastodon) . Évalué à 3.
Salut,
Ok ben en tant que gros utilisateur de vim, c'est rédhibitoire. Pour un petit utilisateur, je comprendrai que ça change peu, mais quand je développe, je commence en général en ouvrant 1 ou 2 fichiers que je pense être ma cible. Puis je me rends compte que j'ai besoin de vérifier l'API et l’implémentation de tel autre, puis tel autre, etc. J'arrive facilement a une dizaine de fichiers dans des tabs vim. Et je ne vais certainement pas fermer vim, puis le rouvrir avec un fichier de plus sur la ligne de commande toutes les 2 minutes (surtout que ce faisant, je perds l'historique de vim pour mes undo en cas d'erreur, mes marks, registres, etc.!). Et puis des fois, j'ouvre un fichier pour le regarder 2 min, et le fermer immédiatement. Devoir fermer/rouvrir vim pour ça serait vraiment contre-productif. Enfin tout ça pour dire que pour moi cette sécurité ne vaut absolument pas la perte de fonctionnalité. :p
Ok mais je suis sur que vim peut avoir d'autres utilisations du réseau en dehors de la ligne de commande. J'ai l'impression que dans ton OS, tout est trop lie a la ligne de commande (et je dis ça, pourtant je lance plein de choses en lignes de commande moi-même, au moins tout ce qui est en rapport avec mes activités de développement!). C'est peut-être ça le problème. Ne devrais-tu pas trouver un système plus adaptable a diverses situations? Par exemple, une application peut annoncer quel type de droits elle nécessite et l'OS peut les accorder au cas par cas (mais bien sur ça demande de préparer une telle liste pour chaque logiciel, ce qui peut être une part du packaging par exemple; et certes les devs paresseux pourraient juste demander tous les droits a l'OS, comme ça arrive dans les smartphones avec ce type de sécurité, et donc on en perd le sens)? Ou bien quand un droit un peu particulier (accès a un nouveau fichier en cours d’exécution? Accès au réseau?) est requis, l'OS popup une question a l'utilisateur qui peut donner le droit ou non selon que ça correspond a ce qu'il est en train de faire.
Ex:
- l'utilisateur veut ouvrir un fichier dans un vim déjà lance :tabopen fichier.c
- l'OS lui demande "le programme 'vim' veut accéder a la ressource fichier 'fichier.c'. L'autorisez-vous?" [oui] [non]
Par contre si au milieu de nulle part, vim demande un accès réseau (alors qu'il a rien fait qui justifie cela), l'utilisateur est alerté qu'y a un truc pas net et peut rechercher si y a pas un programme espion chez lui qui tenterait de faire quelque chose avec le réseau en passant par vim.
Bon c'est un peu le fonctionnement de certains firewall/antivirus, et je sais que ça peut être très chiant parfois (genre ça demande 50 trucs que l'utilisateur comprend pas quand on veut juste lancer un prog). Mais peut-être aussi cela peut-il être fait de manière plus intelligente que ces firewalls?
Dans tous les cas, je pense que limiter massivement toutes les fonctionnalités intéressantes (et basique comme ouvrir des fichiers durant exécution!) des programmes ne peut être la bonne solution! A long terme, tu devras vraiment trouver quelque chose pour aller plus loin, tout en restant dans une logique de sécurité (enfin ce n'est qu'un avis rapide, je n'ai certainement pas toutes les cartes en main non plus).
En fait c'est bien ce que j'envisageais. Comme je disais plus haut, j'utilise vim massivement comme un éditeur multi-fichiers (ce qu'il est, brillamment même!). Soit parfois en split, ça c'est surtout quand y a deux fichiers vraiment très proches que je veux comparer (souvent avec le mode "diff" de vim); mais aussi souvent dans des tabs vim. Travailler ainsi est très différent de travailler dans des instances séparées de vim, notamment pour le copier/couper/coller (je sais qu'on peut aussi travailler dans des instances de vim séparées, et partager des buffers, mais c'est moins pratique…).
Quoiqu'il en soit, je ne dirais pas forcement que c'est une erreur de l'utilisateur d'ouvrir plusieurs fichiers pour s'aider dans son travail. Et même si c'en est une (oui en effet, il pourrait vérifier séparément son fichier venant d'une source plus douteuse d'abord, ou utiliser des copier-coller système, etc.), ben on est humains. On fait ce genre d'erreur, et c'est tant mieux parce que sinon la vie serait vachement chiante. Effectivement nombre d'attaques pourraient être contrées si le gars est plus méticuleux/méthodique et vérifie chaque variable une par une, mais si on se met a faire cela, la vie est un enfer (un peu comme des TOCs, comme le gars qui va se laver les mains 100 fois par jour. Certes il risque moins d’être malade que moi, mais je préfère de temps en temps chopper un rhume que de vivre une vie entière dans la peur des microbes).
Enfin voila, tout ça pour dire qu'au nom de la sécurité a tout prix, si la vie devient horrible, ben je suis pas sur que ça vaut le coup.
Mais ce n'est qu'un avis sans réellement avoir teste. Je te souhaite tout de même bonne chance, et si t'as des nouvelles d'avancement du projet, n’hésite pas a reposter. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Licence, contrat, schmilblick
Posté par Miod in the middle . Évalué à 3.
Il va falloir revoir la licence de A à Z, car celle-ci mélange allègrement le concept de licence (qui définit des droits et des non droits, de façon non opposable) et contrat (qui est un accord entre deux parties dûment identifiées, et signé). Un contrat non signé n'a aucune valeur (puisqu'au moins l'une des deux parties ne l'a pas signé), et une licence qui se présente comme un contrat dès la quatrième ligne a une valeur légale proche du néant.
Par conséquent, ce logiciel, jusqu'à preuve du contraire, est un logiciel propriétaire.
[^] # Re: Licence, contrat, schmilblick
Posté par Emmanuel Colbus . É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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Licence, contrat, schmilblick
Posté par Emmanuel Colbus . É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: Licence, contrat, schmilblick
Posté par patrick_g (site web personnel) . Évalué à 5.
Cela n'a rien à voir avec l'utilisation ou pas de ton logiciel. C'est le fait que tu as posté un journal sur LinuxFR pour présenter ton travail. Il est normal (c'est le principe même des journaux) que nous fassions des commentaires sur Manux, que ce soit le côté technique ou bien le juridique.
Tu t'attendais à quoi ? Les lecteurs ont un esprit critique et ils l'exercent, c'est sain non ?
[^] # Re: Licence, contrat, schmilblick
Posté par Emmanuel Colbus . Évalué à 1.
Ça, d'accord, pas de problème. Mais je trouve que s'interroger pour savoir si un système d'exploitation est utilisable pour quoi que ce soit alors qu'il est déjà auto-hébergé, c'est à peu près aussi trollesque que de s'interroger pour savoir si une voiture est capable de circuler après qu'elle ait fini les 24h du Mans.
[^] # Re: Licence, contrat, schmilblick
Posté par ckyl . Évalué à 5.
Trollesque ?
Tu présentes ton projet, je regarde (ce que tu dis, la doc, le code), je m'intéroge et je demande. Excuse moi (nous) de chercher de comprendre ce qui a été fait, pourquoi, comment et où ca peut aller plutôt que jouer à l'école des fans. Les questions sont: quels sont les avantages, quels sont les inconvéniants, quels sont limites, qu'est ce qui se passe quand on revient à fonctionnalités et userland égal, est ce qu'on ne laisse pas un trou qui rend cela inutile.
Maintenant si tu trouves ca inutile comme questions, pourquoi le présenter ?
PS: Je vais pas suivre la classique comparaison foireuse de voiture, mais justement les proto du 24h du Mans répondent à un besoin très précis avec de fortent contraintes et si tu en sors… ;)
# Plan 9
Posté par fmaz fmaz . Évalué à 4.
J'arrive un peu après la bataille mais un certain nombre de choses que tu décris dont le fait de pouvoir modifier la vue qu'a un processus du FS me font penser à plan 9 et à son modèle de sécurité.
Qu'en est-il ?
# Perfs
Posté par ariasuni . Évalué à 3.
Il y a deux problèmes avec les mesures de sécurité:
En tout cas c’est intéressants ces initiatives dans le domaine de la sécurité, peut-être que Linux n’est pas si sécurisé que ça finalement. :p
Écrit en Bépo selon l’orthographe de 1990
# Tuer la poule aux oeufs d'or
Posté par reno . Évalué à 3.
J'étais en train de me motiver pour regarder le contenu technique de l'OS puis j'ai regardé la licence et d'un seul coup j'ai perdu tout intérêt.
Indice: pose toi la question pourquoi le projet Debian a renommé Firefox.
La gestion des trademark est incompatible avec le libre donc de facto tu viens de tuer le coté libre de ton logiciel, bof..
[^] # Re: Tuer la poule aux oeufs d'or
Posté par Denis Bernard (site web personnel) . Évalué à 1.
Il ne faut pas faire de confusion entre le droit U.S. et le droit français ! Au sens strict, "Trademark" signifie 'marque commerciale' ; or, en droit français, on parle plutôt de marque déposée qui s'applique certes aux entreprises commerciales mais aussi à des personnes (morales ou physiques) de la société civile. Voir sur Wikipédia le Droit des marques .
[^] # Re: Tuer la poule aux oeufs d'or
Posté par reno . Évalué à 3.
Je ne vois pas l’intérêt de ta réponse?
Lis ce qu'il veut faire avec sa licence plutôt..
[^] # Re: Tuer la poule aux oeufs d'or
Posté par Denis Bernard (site web personnel) . Évalué à 1.
Pour info : j'ai vu sur le site de l'I.N.P.I. que Debian était une marque internationale déposée sous le numéro 1084122.
Mais pour répondre à ta question : oui j'ai lu la licence et oui, comme toi, tout ne me plaît pas dedans. D'un autre côté, il ne faut pas demander à un gus qui code tout seul dans son coin, d'avoir tout autant le génie de l'informatique que celui du droit. Dans chacun de ces domaines, il faut avoir fait des années d'études ! Et c'est là où la communauté peut apporter quelque chose, surtout dans le contexte obligatoirement international qu'est le logiciel qui oblige à un exercice d'équilibriste entre des dizaines de législation en vigueur.
# CoreOS ?
Posté par Narmer . Évalué à 1.
Ce projet ne rejoindrait il pas un peu ce que propose CoreOS ?
http://coreos.com/
Il s'appuie en plus sur l'excellent docker.io.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.