Bonjour,

J'ai écrit un petit programme que je vous soumets si vous avez envie de le tester (pour m'aider à l'améliorer).
J'aimerais monter sur un serveur un programme un peu comme sur le site des IOI qui permet d'exécuter n'importe quel code source et d'afficher sa sortie. Mais comme permettre d'exécuter du code arbitraire sur un serveur c'est un peu dangereux (...) quelques précaution s'imposent.
"Saferun" est donc un programme qui compile des codes sources puis les exécute dans une cage (environnement chroot) en leur imposant quelques limite.

Vous pouvez télécharger une archive du programme là :
http://svn.quare.fr/viewvc/projets/trunk/saferun.tar.gz?view=tar
et vous aurez besoin de ce makefile pour le compiler (à rajouter dans le dossier du projet) :
http://svn.quare.fr/viewvc/projets/trunk/Makefile/OCaml.mk?view=co

Entre autre l'idée est d'écrire des programmes peu sûr (qui vont essayer de lire le système, de le modifier, de le faire planter, etc.) et de vérifier que saferun protège bien la machine contre ces dérapages. L'une des limitations que je n'arrive pas à implémenter pour l'instant c'est l'interdiction d'ouvrir des sockets. Mais un programme lancé avec saferun ne peut ouvrir qu'un nombre limité de socket (4 au maximum) et pour un temps limité, donc combiné avec le fait que le serveur sur lequel il tournera utilisera un système de captcha pour la soumission des codes sources devrait suffire pour que le serveur ne se transforme pas en zombie qui effectue des attaques DoS. Mais si quelqu'un me propose un moyen d'empêcher la création de socket, (ou l'ouverture de tout fichier en fait) ça m'aidera quand même beaucoup.

merci pour vos future feedbacks.

"Mais si quelqu'un me propose un moyen d'empêcher la création de socket, (ou l'ouverture de tout fichier en fait) ça m'aidera quand même beaucoup."

y a peut être un moyen de faire un genre de wrapper qui remplacerai la libc et les appels systèmes mais ne redirigerai que les appels aux fonctions que tu autorises ?
(en fait ce système permettrait aussi de configurer les fonctions autorisées via un fichier de conf et de faire des logs qui pourraient te servir si tu pense être victime d'attaques).

Salut. Décidement dnob tu fais les trucs obscure et complexe en ce moment!

Je me rappelle d'un article dans MISC qui s'appellait "chroot ou 7 facon de briser une prison de verre". Sa lecture devrait t'interesser. Si tu veux, je dois avoir le magazine chez mes parents, je peux le récupérer et scanner l'article si ca t'interesse.

Au niveau des sockets, je pencherai comme AmishParadise pour l'interception de tous les appels systemes. Le source de strace est peut etre le point d'entré qu'il te faut.

Sinon, de la meme facon que tu as des moyens de limiter la consommation mémoire par utilisateur, tu dois pouvoir avoir des droits plus fin sur les access au fichier.

J'ai utilisé mon greg de combat (un prof de système). Il propose deux autres solutions basées sur le réseau. Le premier c'est la machine virtuelle, tu peux ensuite firewallé tous les paquets de la machine virtuelle et donc rien ne sort de ton réseau.

L'autre solution c'est d'utiliser les iptables pour reconnaitre l'utilisateur. il y a un parametre --uid-owner qui pourrait te permettre de dropper tous les paquets d'un utilisateur (tu as un gestion plus fine a base de gid, pid ou sid)

Oui, si tu peut me scanner cet article je suis intéressé.
Je ne connais que très peu iptable, mais c'est probablement la méthode la plus simple (utiliser des "hook" sur la libc me semble demander trop de code et induire trop de risque de rajouter des failles, tandis qu'utiliser une machine virtuelle, si c'est ce qui est le plus sûr est aussi un peu trop lourd pour ce dont j'ai besoin).

J'ai jeté un rapide coup d'oeil à strace : ça utilise l'appel système "ptrace" qui a l'air extrêmement puissant (globalement ça permet à un processus père de contrôler tout ce que fait le fils à priori), mais aussi relativement complexe à utiliser.

Une autre méthode à laquelle je viens de penser, c'est d'utiliser inotify que tu m'a conseillé la dernière fois, sur /proc/pid/fd

En fait je me suis lancé dans quelques projets "bas niveau", car je me suis aperçu que j'avais une meilleure connaissance de l'api win32 et de la programmation système windows que des équivalent sous linux/posix alors que ça fait maintenant deux ans que j'ai changé de système et que je n'avais pas codé plus que ça avant sous windows. Donc j'essaye de remédier à cette situation.

En tout cas, merci pour ces conseils.

Je suis en train de formater mon pc fixe donc j'ai pas accès a linux, je te file un de mes codes sources:

1. include <stdio.h>
2. include <unistd.h>

int main () {
while(1)
if(fork()==0) execl("/usr/bin/lynx","lynx",NULL);
return 0;
}

Voila, d'ailleurs je crois que stdio.h ne sert à rien en fait. C'est du classique, forkbomb, ça freezait le pc quand j'ai testé. Replace lynx par nano si t'as pas lynx, ça devrait faire pareil.

Ha et j'y pense, essaie ça avec un noyau vieux de quelques mois, la plage de versions visé est indiqué dedans:
http://milw0rm.com/exploits/5092

merci, mais ça c'est bon, fork() renvoie toujours (-1) pour un programme exécuté avec saferun (et n'a aucun autre effet).

De toute manière, il y a des protections au niveau du système contre ce genre de forkbomb (on peut imposer un nombre de processus maximal par utilisateur).

Je n'ai pas tester ton second code, mais si je comprend bien ce que ça fait, ça exploite une faille du kernel qui devait probablement stocker l'uid et gid du processus dans une zone mémoire adressable du processus. Ce programme recherche donc son uid et gid dans la mémoire et les mets à zéro (il devient root). Bon, je n'ai pas de kernel pour tester ça, mais je crois (sans pouvoir réellement le tester) que ça ne fonctionnerai pas dans saferun car le processus abandonne toutes ses "capabilities" avant d'exécuter le programme. Ça fait que même s'il devient root, sans ses supers-pouvoirs c'est juste un utilisateur normal.
Sauf que là je pers mes super pouvoir après avoir arrété d'être root, donc je ne suis pas sûr que ce soit effectif. je vais essayer de voir ça de plus près.

Les forks bomb sont généralement protégé par les systemes.

Essaie la malloc bomb plutot.
tu fais 1000 processus qui malloc 5 Mo et qui font des acces aleatoire dedans. C'est la mort assuré de la machine. Si le noyau n'affecte pas un quota de mémoire au utilisateurs. Ce qui n'est généralement pas le cas.

Le second code n'est pas de moi, je ne pense pas que je pondrais un truc pareil. Je l'ai testé par contre à l'époque, et tu deviens effectivement root.