teach/virli
1
0
Fork 0
Code Issues Pull requests Releases Activity

Edit a subject

Browse source
This commit is contained in:
nemunaire 2016-12-09 16:17:49 +01:00
commit cad67995ae
14 changed files with 162 additions and 294 deletions
Download patch file Download diff file Expand all files Collapse all files

147
tutorial/3/project.md
View file

@ -1,147 +0,0 @@
\newpage
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, du shell, 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 *CGroup*s, 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 :
```shell
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/...
```