Hurd - Page 1

Jusqu'il y a peu, je pensais que Hurd était "yet another *nix kernel". En fait, il a l'air de proposer quelques trucs vraiment supers.

Ainsi, par exemple, les "translators" permettent d'attacher un programme à un noeud du système de fichiers. Exemple :

$ pwd
/home/glibersat
$ mkdir ftp
$ [Attacher le translator hostmux avec comme sous-translator ftpfs]
$ cd ftp
$ ls
$ cd ftp.fr.debian.org
$ pwd
/home/glibersat/ftp/ftp.fr.debian.org
$ ls
debian  debian-amd64  debian-non-US
$ cd ..
$ pwd
/home/glibersat/ftp
$ ls
ftp.fr.debian.org
$ cd ftp.hurdfr.org
$ pwd
/home/glibersat/ftp/ftp.hurdfr.org
$ ls
duck  duckcorp  gps  hurdfr  myserver

C'est pas , ça ?

Maintenant j'anticipe les versions utilisables et stables de Hurd avec impatience En espérant qu'il aura assez de succès pour que les drivers (ceux libres, du moins) soient portés assez rapidement ...

comment ça tu anticipes les versions , tu t'es pas trompé de mot par hasard ? (genre « j'attends », ou je sais pas moi mais un mot qui aurait un sens dans le contexte quoi )

edit : pour être plus précis ce qui me choque dans ta phrase c'est que tu anticipes quelque chose qui n'est pas un événement (c'est même quasiment un objet), en fait c'est probablement une ellipse de « j'anticipe la parution des versions [...] » mais ça fait vraiment bizarre dit comme ça, enfin ça me donne vraiment l'impression qu'il manque un bout de la phrase ou que tu t'es trompé de mot ^^

Bah ce genre de chose, ça peut se faire assez facilement avec fuse sur les noyaux linux récent
Par exemple ça : http://wiki.thiesen.org/page/Fuseftp
Mais on doit pouvoir faire exactement pareil que dans ton exemple avec hurd

Sally > Oui, j'anticipe "la parution des versions", si tu veux
guilc > Mais ce n'est pas au niveau de l'OS


Sinon , pour donner un autre exemple, on peut aussi attacher le translator "fortune" à un fichier, et utiliser ce fichier comme fichier de signature d'emails. Eh bien à chaque mail envoyé, il contiendra une signature différente

Moumou :
guilc > Mais ce n'est pas au niveau de l'OS

Bah justement, au niveau du kernel, je trouve ça plutot crade, et peu safe.
Si ton code est daubé, d'une, c'est le kernel qui prend, et si y a une faille, la faille est dans le kernel land, beaucoup grave qu'une faille en userland au niveau des possibilités d'exploitation de la faille...
Enfin, après, j'ai pas les détails de l'implémentation de cette fonctionnalité dans hurd, mais si c'est bien ça, je trouve ça hyper crade et je préfère 10 000 fois la méthode fuse

Quand je dis au niveau du kernel, chacun des translators est tout de même un module du noyau, ce qui n'est ni crade, ni peu safe. Hurd est modulaire, et le but de ce design est justement que les failles et les bugs des modules ne se propagent pas dans le noyau.

Sinon, voici un autre exemple : Tu vas sur ta machine, tu crée une disquette avec dessus un binaire setuid root. Tu vas la mounter sur une machine Linux sur laquelle root a oublié de mettre fd0 en nosuid ou noexec, ben paf, t'as un exploit. Sur Hurd, le point de montage est géré par le translator ext2fs (si ta disquette est ext2). Or le translator est lancé par l'utilisateur (contrairement à mount qui est setuid root), donc de toute façon, même sans ces hacks que sont noexec et nosuid, il n'y a aucune possibilité de gagner l'accès root.

Tiens, Moumou découvre le Hurd

guilc> renseigne toi sur le sujet avant de critiquer ou de comparer "c'est comme..."
Ce n'est pas comme. Le Hurd entier n'est pas comme. Les concepts mis en jeux n'ont rien à voir avec ce que tu peux connaître du fonctionnement d'un noyau.

En meme temps deja que les drivers sous linux c pas la joie, mais alors la ca va etre encore plus dur :/

Le Hurd est un système expérimental pour l'instant.
Il n'a pas vocation à supporter un autre matériel que celui de ses développeurs.
Et "si t'es pas content t'as qu'à pas le mettre".

spectras :
guilc> renseigne toi sur le sujet avant de critiquer ou de comparer "c'est comme..."
Ce n'est pas comme. Le Hurd entier n'est pas comme. Les concepts mis en jeux n'ont rien à voir avec ce que tu peux connaître du fonctionnement d'un noyau.

Ce n'est pas un critique bordel !
Tu as vu le "Si" dans ma phrase ?

guilc :
j'ai pas les détails de l'implémentation de cette fonctionnalité dans hurd, mais si c'est bien ça...

Non, je ne connais pas hurd, mon hypothèse était une idée de ce que laissait comprendre le post de moumou...
Si c'est pas comme ça, ben tant mieux, tu peux expliquer par exemple poruquoi ce n'est pas ça (non, on n'a pas forcément le temps de passer des heures et des heures a décortiquer l'implémentation de hurd, ce que tu semble avoir fait). Pas la peine de balancer des insultes sur ce qui restait une hypothèse...

bein c l avantage quand t es super mega crousti, apres tu peux gueuler tout le temps sur tout le monde

./10> c'est pas une question d'implémentation, mais de concept. L'exemple de Moumou n'est qu'un cas particulier de l'expression d'un concept très puissant, qui fait l'originalité du Hurd.

Pour faire court : le Hurd ne connait pas la notion de "point de montage". Pour le hurd, le système de "fichiers" n'est pas un système de fichiers, c'est un référentiel de nommage. A chaque nom est associé un ou plusieurs programmes, de sorte que lorsqu'une référence est demandée sur ce nom, le programme correspondant est instancié (si tu connais CORBA, le mécanisme s'approche plus ou moins, en remplaçant le système de nommage complexe par un simple chemin dans une arbo).

Certains programmes simulent un point de montage, par exemple le programme ext3fs, qui lorsqu'il est invoqué montre une arborescence d'objets correspondant aux fichiers sur le disque. Celui montré par moumou en est un autre, qui l'orsqu'il est invoqué montre une arborescence ftp (de plus sa fonction "entrée dans un groupe", invoquée par la commande cd, le conduit à créer automatiquement le groupe correspondant, par exemple ftp.free.fr).
Ces exemples sont les moins intéressants, dans le sens où ils sont assez proches des utilisations habituelles.

Un autre exemple intéressant : lorsqu'une application crashe, le système ouvre un point dans le référentiel de nommage. Ceci provoque l'instanciation d'un programme de gestion du crash. A partir de là, ça veut dire que par une simple commande ln -s tu peux modifier le programme instancié. Par exemple, pour mettre un programme qui génère un core dump, ou pour mettre un programme qui lance un débuggeur, oui qui envoie un mail, ou que sais-je encore.

Tout est dans le référentiel de nommage, y compris des trucs comme le scheduler, le gestionnaire de mémoire, les mécanismes d'authentification...


Côté implémentation, le Hurd est composé d'un noyau minimal, architecture à passage de messages. Il n'y a rien qui tourne en kernel space comme tu disais, justement. Comme je viens de le décrire, tout est dans le référentiel de nommage, et le scheduler est un programme ordinaire, au même titre que la commande ls, un driver de carte réseau ou firefox. (note : le référentiel de nommage lui même est un programme, qui peut être changé). Les programmes qui ont besoin de parler entre eux le font via une API RPC. Par exemple : un pilote de disque dur exporte un certain nombre d'appels RPC pour pouvoir être reconnu comme tel par un programme de gestion de système de fichier. Le pilote utilise lui-même un certain nombre de RPC pour demander des choses au programme qui gère les canaux DMA (qu'il localise via le référentiel de nommage), à celui qui gère les interruptions (qu'il localise...bah je refais pas le topo)...

Côté sécurité pour le lancement de ces programmes ? Ben facile : chmod. Un utilisateur peut lancer son propre programme driver de carte réseau, qui s'exécutera avec ses permissions (l'utilisateur doit avoir la permission d'accéder à la carte). Etant un programme indépendant, il ne perturbera pas les autres utilisateurs, et en cas de crash, ben c'est un crash d'application normale (qui peut même invoquer un débuggueur ordinaire, voir un peu plus haut)

---

Et le modèle de sécurité utilisé ? Ben ai-je vraiment besoin de faire un dessin ? Le programmes ne communiquent entre eux que via RPC. Par défaut, un programme bénéficie des jetons de permission de celui qui l'a exécuté. Tout programme peut détruire ses jetons à tout moment. A l'inverse, il y a un programme spécial et un seul capable de créer des jetons de permission; il fait 2 pages de code et est donc facilement vérifiable.

Ainsi voilà comment un serveur SSH sous Hurd travaillerait (travaille?) :
1) il est lancé et hérite les jetons de permission de son père
2) il ouvre son port (il faut que les jetons hérités contiennent ce privilège)
3) il détruit la totalité de ses jetons
=> là il ne peut plus faire le moindre appel RPC (il se mangera des permissions refusées, même pour des trucs comme allouer de la mémoire)

4) lorsqu'une connexion arrive, aucun risque d'un exploit : même si qqn trouve une faille et injecte du code, le code ne peut strictement rien faire
5) le serveur fait alors un appel RPC au programme spécial (c'est le seul appel RPC ne demandant pas de jeton), en lui passant les login/pass fournis par l'utilisateur.
6) le programme spécial vérifie le mot de passe, et accord ou non les jetons d'identification correspondants aux droits de l'utilisateur

Tu remarques que :
1) tant que personne ne s'est identifié, le serveur a 0 droit
2) une fois loggé il a les droits de l'utilisateur loggé
3) il ne fait pas l'identification lui même, mais délègue au programme dédié à cette fonction

Quel que soit le bug qu'il peut y avoir dans le serveur, à aucun moment le système ne peut être compromis, puisque "l'exploit" tournera avec les permissions de l'utilisateur qui le lance (=aucune s'il n'est pas loggé)


Et on combine ça avec le référentiel de nommage. Bah oué, le programme qui crée le jetons est dans le référentiel de nommage. Mais alors, il se passe quoi si un utilisateur en lance une copie ? Facile : la copie fonctionne à merveille, créant des jetons comme le modèle normal. Sauf que la copie tourne avec les jetons de l'utilisateur qui l'a lancé, et ne peut donc donner que ces jetons là.
Autrement dit : un utilisateur peut lancer un serveur ssh sous son nom. Le serveur sera en mesure de le logger, mais pas de logger un autre utilisateur.


A travers ces quelques exemples, on voit la modularité et la sécurité dégagées par les concepts du système. Ca redéfinit complètement la façon d'aborder un système d'exploitation, ses fonctionnalités (redéfinissables à la volée), sa sécurité (jamais plus de jetons que nécessaire), sa stabilité (tu connais bcp de systèmes capables de relancer le scheduler s'il plante?).
Le seul revers important, c'est que le passage de message et l'authentification entre drivers a un coût significatif en temps de calcul. Je sais pas où ça en est actuellement, la dernière fois que j'ai regardé ils avaient trouvé une solution et commençaient à l'implémenter.

Pour résumer mon post précédent (y'a des feignasses qui vont pas le lire).

Hurd, fondamentalement, est un ensemble d'interfaces "CORBA/RPC-like", utilisant l'arborescence unix comme espace de nommage, et un micronoyau pour passer les messages RPC. Chaque driver / système de fichier / scheduler / memory manager / application classique est alors un objet présentant une interface et en utilisant d'autres. L'arborescence permet de coller les objets ensemble, un peu comme le idl script.

Je viens de trouver un enregistrement vidéo de la conférence de 2004 aux JDL à Lyon sur le sujet : ftp://ftp.duckcorp.org/hurdfr/events/Kilobug-041023.ogm

hum, bon ben ce sera pour ce soir "Reprendre ici •«" ^^

Pour les jetons : est-ce que c'est une information infiniment réplicable qu'on peut éventuellement cacher (= comme une clé privée), ou est-ce que c'est qqch que l'on peut détruire de manière prouvable (= on peut faire une liste exhaustive des jetons auquel un processus a accès) ?

spectras
: Quel que soit le bug qu'il peut y avoir dans le serveur, à aucun moment le système ne peut être compromis, puisque "l'exploit" tournera avec les permissions de l'utilisateur qui le lance (=aucune s'il n'est pas loggé)

Euh, c'est quand même beaucoup dire : le serveur a quand même accès aux mots de passe des utilisateurs, c'est loin d'être négligeable... Par exemple le serveur :

char name[100],pass[100];
for ( ; ; ) {
  FILE *stream = wait_new_connection();
  if (fgets(name,100,stream) && fgets(pass,100,stream))
    fork_and_login(name,pass);
  close_connection(stream);
}

a une grosse, grosse vulnérabilité : si je crée un compte avec un mot de passe de un caractère (ou même vide), j'ai accès au mot de passe de l'utilisateur précédent (modulo les 1 ou 2 premiers caractères, mais ça peut se deviner ou se bruteforcer)


Ou encore : si ce serveur a un buffer overflow qui permet d'exécuter du code arbitraire, alors je peux connaître les mots de passe de tous ceux qui se logguent, savoir qui se logge et quand, etc... (bon par contre c'est vrai qu'avec des jetons suffisamment fins on doit pouvoir faire en sorte qu'il soit impossible de modifier le code ou d'exécuter du code arbitraire )

spectras
:tu connais bcp de systèmes capables de relancer le scheduler s'il plante?).

tu as déja vu un scheduler planter ?

mais oui, celui du Hurd

Pollux> ce n'est pas une vulnérabilité dure. De toutes façons, je ne t'apprends rien en te disant qu'un serveur se fait sur le modèle.

while(connecté = accept(ecouteur)) {
   int pid = fork()
   if (pid == 0) {
      close(ecouteur)
      blablabla;
      exit()
   }
   close(connecté)
}

Ton exemple est complètement foireux quoi qu'il en soit : il est incapable d'accepter plusieurs connexions simultanées. Pour un serveur c'est assez moyen.
Par ailleurs, si t'as suivi les implications de ce que je disais plus haut, il n'est pas nécessaire que le serveur manipule le mot de passe des utilisateurs. Après tout, il n'en a pas l'utilité.

tu as déja vu un scheduler planter ?

Ben par quelle magie un scheduler serait exempt d'erreurs ? D'ailleurs un rapide google semble indiquer que la version 2.6.8 de linux a un bug dans son scheduler, qui survient si tu fais du VLAN tagging (802.1q) dans un noyau préemptible... bonjour l'isolation

Moi j aime bien les resumés car je suis une grosse faignasse, merci !

c'était une petite blagounette! ceci dit je me demande comment ça se passe qd il plante, est-ce qu'il est écrit quelque part en dur que c'est tel scheduler à relancer? parce que sinon je vois pas trop...

moi des fois je fais du VLAN tagging aussi!
quand on me dit ta gueule, VLAN une baffe!

spectras
: Par ailleurs, si t'as suivi les implications de ce que je disais plus haut, il n'est pas nécessaire que le serveur manipule le mot de passe des utilisateurs. Après tout, il n'en a pas l'utilité.

En théorie, ce serait assez logique effectivement (*), mais ce n'est pas ce que tu dis :

5) le serveur fait alors un appel RPC au programme spécial (c'est le seul appel RPC ne demandant pas de jeton), en lui passant les login/pass fournis par l'utilisateur.

Moi je lis ça comme si c'est le serveur qui doit lire les login/pass (d'ailleurs c'est assez logique, seul le serveur sait qu'il faut écouter sur le port 22, et parler par SSH pour avoir les logins/pass ^^)



(*) : puisque le problème dont je parlais est un pb de leak d'information, et que la seule façon d'éviter les leaks d'information avec des binaires quelconques est d'isoler les processus, je verrais la chose comme ça :

serveur_port_22 : jetons = { acceptation_connections_port_22, création_processus_fils_avec_jetons_appropriés } fils : jetons = { lecture_écriture_handle_exclusif_à_ce_processus_et_ses_fils (en gros, après appel de cette fonction, le père et ses autres fils n'ont pas le droit de lire ou écrire dans ce handle) }

Ca garantit que le serveur ne va pas aller écouter sur d'autres ports, et que les fils ne peuvent pas dialoguer entre eux, bref là pour le coup je serais d'accord pour dire que quel que soit les bugs du serveur, il ne peut rien arriver de pire qu'une DoS. Est-ce que tu sais si en pratique les programmes ont une granularité aussi fine ?

spectras :
Tiens, Moumou découvre le Hurd

Merci, mais je ne dois surement pas être le seul, tu devrais plutôt être heureux que j'ai créé ce topic

Ceci etant dit je pense qu un dessin serait plus approprié.

Bookeldor> ben...dans le référentiel de nommage. Y'a un chemin genre /system/scheduler (je connais pas le chemin, c'est un exemple bidon).

Pollux> ben ce sont des exemples, je suis parti d'un modèle hypothétique de serveur. Après, comme je l'ai dit, le mécanisme que gère les jetons est présent dans le référentiel comme tout le reste. Rien n'empèche de le remplacer ou de l'overrider localement par un qui réalise une authentification par clef privée au lieu de mot de passe. Par définition, il n'y a rien de figé sous Hurd, à part le micronoyau et ses 3 appels systèmes qui se battent en duel.

Cette page est plus pointue que moi pour répondre à ta question : http://kilobug.free.fr/hurd/pres-en/abstract/html/node7.html (pour cause, c'est un des développeurs qui l'a rédigée)

La partie "POSIX compatibility" qui émule un UID / GID à partir de tokens spécifiques est intéressante, dommage que ce ne soit pas davantage développé.

On note également : "Through ``auth'', tokens can be given, destroyed, or created. Tokens can exist for anything, for example you can imagine a token ``is able to bind ports below 1024''."

Par ailleurs, une rectification d'une erreur dans ce que j'ai dit plus haut : le serveur qui gère les mots de passe est distinct de celui qui gère les jetons. Le serveur gérant les mots de passe est un serveur normal, de quelques lignes qui a un large éventail de jetons, et peut donc en dupliquer de manière arbitraire (le même, lancé par un utilisateur, ne pourra dupliquer que les jetons dont il dispose, c'est à dire ceux de l'utilisateur). Pour la création proprement dite il s'adresse au serveur "auth".

Ha merci pollux je comprend beaucoup mieux
De toute maniere vista sera bien superieur a hurd!!! si si je vous le jure
(Bon la c est un peu flagrant le troll).

Enfin Hurd ca fait super longtemps qu on en entend parler...

Bah oui, "<" aussi bien pour l'ensemble des features que pour la date de sortie (parce que Tunes, hein... )

Bah oué JackosKing. On ne réinvente pas le concept d'OS en 5 minutes hein. La version actuelle du Hurd a commencé son développement en 2002 ou 2003 il me semble. Et encore, ils ont changé de micronoyau l'année dernière.

ha ouai mais si ils changent le noyau tous les ans, bientot on ne recompilera plus on carrement de noyau !!!

Quand on avance dans l'inconnu, c'est fréquent de faire des erreurs. Les développeurs du Hurd ont passé beaucoup de temps à élaborer les concepts (qui sont loin d'être triviaux), on fait plusieurs essais déjà, chaque essai tirant partie des erreurs du précédent.

Lorsqu'un processus obtient le droit d'émettre vers le noeud /servers/password (par exemple avec la fonction open), il peut envoyer des messages au serveur en question. L'un des RPCs qu'il peut envoyer à ce serveur est "password_check_user'. L'interface de ce RPC indique que l'appelant doit fournir un identifiant et un mot de passe. Après vérification, le serveur retourne un jeton d'authentification à l'appelant. Celui-ci peut alors l'utiliser pour prendre des privilèges lors de requêtes à des serveurs reconnaissant ce jeton

Ceci signifie que, par exemple, un serveur FTP peut être implémenté de telle sorte qu'il démarre avec aucun jeton d'authentification (il ne peut donc pas faire de requêtes à d'autres serveurs). Lorsqu'un client tentera de s'identifier, il se contentera de passer les informations au serveur "password" et de récupérer le jeton le cas échéant. En plus de rendre l'implémentation plus simple, et donc de réduire la possibilité de failles, un énorme gain en sécurité est obtenu : le serveur doit augmenter ses privilèges et non les diminuer lorsque l'utilisateur est authentifié. Bien que le résultat soit le même, les attaques de type buffer owverflow deviennent bénignes : même si l'attaquant arrive à cracker le démon ftp au cours de la phase d'authentification, il entre dans le système avec aucun privilège (au contraire d'un système unix classique, où le serveur FTP s'exécute en tant que root et abandonne ses permissions après).

De plus, aucun élément du système n'est statique : chacun peut être remplacé, ou suppléé par l'administrateur ou par les utilisateurs. Notamment, un utilisateur peut parfaitement créer et lancer son propre serveur d'authentification. Les autres serveurs refuseront de reconnaître les jetons qu'il créera en dehors du cadre des jetons "officiels" qu'il possède. Ceci permet de créer un "proxy" d'authentification, qui subdivise les ressources contrôlées par un utilisateur donné et compartimente le système.

Par exemple, supposons un serveur de mail. Il range tous les mails dans un système de fichiers ext2 dans un fichier (comme un loopback sous Linux). Le propriétaire du fichier pourrait être, disons, "application-data". On pourrait lancer un serveur ext2fs utilisant ce fichier, et s'appuyant sur un serveur d'authentification exécuté en tant qu'utilisateur. Lorsque les clients se loggent pour vérifier leurs mails, ils se voient donc attribuer des jetons d'authentification par le serveur d'authentification local. Ces jetons, reconnus par le serveur ext2fs, sont utilisables pour lire les mails, mais sont invalides dans tout le reste du système.

[traduction libre d'un extrait de l'interview de Neal Walfield, disponible ici

Note intéressante également : les différents serveurs composant un système peuvent tourner sur des systèmes physiques distincts. Ceci n'est pas encore implémenté hélas.