Projet et rendu

Les exercices de ce TP ne sont pas à rendre.

Sujet

Ce projet, étalé sur ce TP et le TP suivant, constitue le cœur de la notation de ce cours.

Vous allez commencer aujourd'hui un projet qui s'étendra au prochain TP et qui consistera à réaliser la partie d'isolation de la moulinette des ACUs !

Cette semaine, il faudra faire en sorte de restreindre un groupe de processus pour qu'il ne puisse pas faire de déni de service sur notre machine.

Il n'y a pas de restriction sur le langage utilisé, vous pouvez tout aussi bien utiliser du C, du C++, du Python, etc.

L'usage de bibliothèques non relatives au projet est autorisé : le but de ce sujet est d'évaluer votre compréhension et votre utilisation de la tuyauterie bas-niveau du noyau liée à la virtualisation légère. À partir du moment où vous n'utilisez pas une bibliothèque qui abstrait complètement cette plomberie, n'hésitez pas à l'utiliser !

Gardez en tête que ce projet sera à continuer au prochain TP, où il sera principalement question de faire des appels système.

Stage 1 : Restreindre l'environnement (2 points)

Après avoir mis en place les bases de votre programme, commencez par créer les différentes hiérarchies (si vous avez un noyau récent, vous pouvez utiliser les cgroups-v2) dont vous allez avoir besoin pour limiter l'utilisation de ressources.

Puis, mettez en place ces limites :

pas plus d'1 GB de mémoire utilisée ;
1 seul CPU au maximum ;
100 PIDs ;
...

En bonus, vous pouvez gérer les cas où le noyau sur lequel s'exécute votre moulinette ne possède pas tous ces CGroups, au lieu de planter, ne rien faire n'est pas forcément une mauvaise solution.

Stage 2 : Réduire les capabilities (2 points)

Réduisez au maximum les capabilities, de telle sorte qu'il ne soit pas possible de faire un ping dans l'environnement restreint :

42sh# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=3.93 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=3.97 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 3.931/3.954/3.978/0.067 ms

42sh# ./mymoulette /bin/bash
  bash# curl http://www.linuxcontainers.org/ | md5sum
  59e714c4331e71ac3529a6502994ef1d

  bash# ping 8.8.8.8
  ping: icmp open socket: Permission denied

Astuces : prctl(2), capabilities(7), capget(2), capset(2), ...

Aidez-vous du visualisateur de capabilities de la partie 4, pour voir si vous êtes sur la bonne voie.

Stage 3 : Utilisable par un utilisateur (1 point)

Jouez avec les attributs étendus pour qu'un utilisateur non-privilégié puisse exécuter votre moulinette. Ajouter la/les commande(s) à votre Makefile ou script d'installation.

Création d'un environnement d'exécution minimal

Plutôt que d'utiliser votre système hôte au complet, avec tous ses programmes et toutes ses bibliothèques, il faudrait utiliser un système contenant le strict minimum. Recréez un environnement minimaliste, comme on a pu en voir dans la partie sur les chroot.

Ne mettez pas cet environnement dans votre tarball de rendu, il vous sera seulement utile pour faire des tests.

Stage 4 : Isolation du pauvre (1 point)

Nous n'avons pas encore vu de meilleure méthode pour mieux isoler l'environnement que de faire un chroot, ajouter à votre programme cette isolation rudimentaire. Et rendez-vous au prochain cours pour avoir une meilleure d'isolation !

Stage 5 (bonus) : automatisation de la création de l'environnement (5 points)

Pour moulinéter plusieurs étudiants en parallèle, vous allez avoir besoin de plusieurs environnements identiques. Plutôt que de recopier cet environnement, de le nettoyer, de le recréer, pour chaque étudiant, ajoutez à votre moulinette un support pour LVM : utiliser des snapshots pour figer votre environnement et le dupliquer facilement pour chaque étudiant.

L'usage est laissé à votre discrétion : vous pouvez ajouter un/des paramètres à votre moulette pour indiquer le volume LVM à utiliser ou le définir en dur ou encore séparer la création de l'environnement et de la snapshot initiale dans un programme distinct.

Modalité de rendu

Un service automatique s'occupe de réceptionner vos rendus, de faire les vérifications nécessaires et de vous envoyer un accusé de réception (ou de rejet).

Ce service écoute sur l'adresse virli@nemunai.re, c'est donc à cette adresse et exclusivement à celle-ci que vous devez envoyer vos rendus. Tout rendu envoyé à une autre adresse et/ou non signé et/ou reçu après la correction ne sera pas pris en compte.

Tarball

Tous les fichiers identifiés comme étant à rendre pour ce TP sont à placer dans une tarball (pas d'archive ZIP, RAR, ...).

Les réponses aux questions sont à regrouper dans un fichier questions.txt à placer à la racine de votre rendu.

Voici une arborescence type :

login_x-TP3/questions.txt
login_x-TP3/mymoulette/README
login_x-TP3/mymoulette/...

5.0 KiB Raw Blame History