Et voila, saferun fonctionne maintenant.

Ça ne gère que le C et le C++ pour l'instant (ironique de la part d'un programme globalement écrit en OCaml), mais ça tourne sans problème et de manière sécurisé (du moins, je l'espère).

Le code source est accessible là:

le programme lui même
http://svn.quare.fr/viewvc/projets/trunk/saferun.tar.gz?view=tar

un binding ocaml pour la fonction ptrace
http://svn.quare.fr/viewvc/projets/trunk/libptrace-ocaml.tar.gz?view=tar

le makefile pour compiler ces deux programmes
http://svn.quare.fr/viewvc/projets/trunk/Makefile/OCaml.mk?view=co

Mais en BONUS!! le service est accessible en telnet surla machien quare.fr par le port 5000
vous tapez : telnet quare.fr 5000
puis vous copiez un code source en C ou en C++ (en mettant sur la première ligne C ou C++ selon le langage) et vous terminez en tapant EOF et hop vous avez la sorti de votre programme !

Bon si la connexion ne se fait pas, attendez un peu, car j'ai pas mal limité l'accès au service, mais normalement il n'y a pas de problème. Il faudra que je fasse une meilleur interface à tout ça, mais dites moi ce que vous en pensez.

J'essayerais aussi d'ajouter d'autre langage (pour l'instant le runtime caml me pose problème car il vaut modifier la gestion des signaux et c'est trop sensible pour que je le permette, donc je vais devoir émuler ces appels systèmes et le man de ptrace est déjà un peu vague (voir faux par endroit), mais là, s'il dit que c'est possible, il ne donne pas la moindre indication sur comment...)

Salut,
C'est interessant comme programme. J'ai fait deux trois test.
On a le droit d'essayer de tout casser ?

si c'est toi, oui bien sûr, mais préviens moi si tu réussi...

bon, ca marche bien ton truc.
J'ai bien aimé la limitation de temps pour eviter les boucles minables!
Je n'ai pas trouvé d'appel systeme qui ne soit pas bloqué a part brk.

C'est bizarre, je n'ai pas exactement le meme comportement quand j'essaye de lire /var ou /tmp que pour / ou /usr. Les deux premiers ca ne s'ouvre pas, tandis que pour le dernier je me fais killé a cause de l'utilisation de l'appel systeme fcntl. Ce qui me fait dire (confirmer par errno) qu'il n'y a pas de /var et /tmp mais qu'il y a un /usr...

Tiens c'est marrant,
je n'ai pas la meme erreur sur un while (1) ou je me prend un sigkill que sur un while (1) malloc ou je me prend un "real time timeout"

Bon ca a l'air solide ton truc. Je regarderais le code plus tard.

très malin ton test du while malloc, car vu que sleep est bloqué je me demandais comment tester cela mis à part part avec des latence d'entrée sortie, mais effectivement il y a une limite (5s) de temps CPU et une limite de temps total (10s).

Il y a quelques appels qui sont autorisé forcément pour démarrer le programme et faire des entrée/sorties, entre autre la lecture de fichier, mais pas tout. Et j'ai ajouté le support de l'émulation de l'appel pour les quelques appels dont a besoin le runtime caml mais que je ne voulais pas laisser accessible. C'est pas évident car l'argument SYSEMU de ptrace ne fonctionne pas sur amd64, donc je le fait à l'ancienne : je remplace l'appel par un autre (getpid) et à la fin je remplace la valeur de retour par zéro. Par contre, je ne sais pas encore comment décoder les arguments d'un appel. Sinon pour open j'empêcherais que l'on s'en serve sur des répertoires ...

En tout cas, avec "OCaml" sur la première ligne, les programme en ocaml doivent fonctionner maintenant et rajouter de nouveaux langages doit être assez simple.

Bon et la dernière version du programme, et de la bibliothèque est sur le serveur svn.

en fait, le comportement de opendir permet de savoir si un repertoire est présent. J'imagine que de la meme facon on doit pouvoir savoir si un ficheir est present (pas eu le temps de verifier).
Ce comportement n'est pas dangereux mais il permet une analyse du système.

Pour le malloc en fait je voulait essayer de faire un DoS sdur le systeme en faisant swappé ta machine.
D'ailleurs si on fait trop swappé, il y a des noyaux qui se mettent a tuer des processus aléatoirement (biaisé sur la consommation mémoire), je voulais donc voir si j'arrivais a tuer des trucs critiques.
Cependant, il y a une limite au nombre de connexion simultané j'ai l'impression. Du coup, je n'arrive pas a faire le DoS.

Pour récupérer des infos, j'ai aussi essayer de regarder des variables du système, ce n'est pas évident parceque les appels systemes sont bloqué (donc en particulier je n'ai pas le chemin courant). De la meme facon, il n'y a rien dans argv (argc == 0), je n'ai pas encore regardé les variables d'environnements mais j'imagine que c'est pareil. du coup, je ne sais meme pas sur quel uid le programme tourne...

Ca a l'air robuste ton truc.

dans argv il y a des truc, mais, tu vas rire, j'ai une erreur quand j'essaye de le lire (un signal que je ne décode pas, du coup je ne sais pas ce qui se passe). Mais je vais le vider.
Hop, voila, plus de variable d'environnement.

Mais je ne sais pas du coup ce qui se passait tout à l'heure. Si tu reçoit ce message d'erreur :
error: unknown but definitely forbidden operation
Envoie moi le programme avec lequel tu l'obtient s'il te plait.

Pour ce qui est du swap j'y ai un peu pensé, mais c'est certainement le bottle neck de tout ça. La consommation mémoire de ces programme est assez encadré et le nombre de programme simultané aussi (quoi que là c'est un peu paranoïaque, j'augmenterais la valeur plus tard). Mais comme les programmes sont nicé je crois que oom les tuera en premier. De fait, je ne comprend pas trop ce fichier /proc/<pid>/oom_adj qui permet d'ajuster de manière dramatique le score d'un processus pour oom, car il est "writable" par le processus en question qui peut donc gérer sapriorité tout seul, je ne trouve pas ça normal (enfin bon, pas depuis la cage de toutes manières).

Mais je crois que l'algo est assez bon et ne tue pas de processus critique (rien à root généralement).

Bon, mon erreur inconnue était une segfault (maintenant il y a un meilleur message d'erreur). Ce qui m'étonne, je croyais que ce tableau était terminé par un zéro (ou alors que la dernière chaine était un zéro, mais ce n'est ni l'un ni l'autre).

En tout cas, merci pour le retour.

"Mais je crois que l'algo est assez bon et ne tue pas de processus critique (rien à root généralement)."
Il y avait une periode ou ca tuait le server X. Mais ca a été corrigé par un hack tout sale (de mémoire)

Bon, j'ai retrouvé l'article sur chroot. Il date un peu (2003) et je ne sais donc pas si c'est encore d'actualité. (mais bon ca peut toujours servir)
http://godrik.mandragor.org/~godrik/chroot.pdf

merci, c'est assez intéressant.

Globalement, du fait que la plupart des appels systèmes sont interdit, je suis protégé contre ce genre d'exploit, mais c'est bon à connaître.