virli/tutorial/4/project.md

153 lines
4.8 KiB
Markdown
Raw Normal View History

2016-10-19 03:24:05 +00:00
\newpage
Projet et rendu
===============
## Sujet
**Ce projet, étalé sur ce TP et le TP précédent, constitue le cœur de la
notation de ce cours.**
Vous allez continuer aujourd'hui le projet qui s'étendra depuis le TP précédent
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 s'exécute indépendemment de votre système.
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 !
### Stage 5 : Une vraie isolation
En plus du `chroot`, assignez de nouveaux namespaces au processus que vous
allez lancer : CGroups, IPC, mount, net, PID, UTS, user.
Il est requis que le nouveau processus ne puisse pas s'échapper de ses
namespaces !
Astuce : `clone(2)`.
### Stage 6 : Empêcher les fuites d'information
Démonter tous les sytèmes de fichiers qui ne sont pas nécessaire au
fonctionnement de votre conteneur et remontez les partitions
N'oubliez pas de remonter les systèmes de fichiers pour lequel cette opération
est nécessaire pour terminer l'étape d'isolation.
Astuce : `mount(2)`.
### Stage 7 : Identification du conteneur
Maintenant que vous avez votre conteneur, personalisez-le un peu en lui donnant
un nom unique.
Astuce : `sethostname(2)`
### Stage 8 : `pivot_root`
Effectuer un `pivot_root(2)` de telle sorte qu'il ne reste plus de trace du
système de fichiers hôte.
Astuce : `pivot_root(2)`, `umount(2)`.
### Stage 9 : Bac à sable connecté
Partant d'une liste d'interfaces sur la machine hôte similaire à :
```
42sh$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 90:2b:34:5e:fa:a7 brd ff:ff:ff:ff:ff:ff
```
Vous devrez pouvoir `ping` votre conteneur depuis votre hôte :
```
42sh$ ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
[...]
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
[...]
3: veth3e06cad@if82: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default
link/ether 42:a2:a0:89:54:ef brd ff:ff:ff:ff:ff:ff
inet 10.10.10.41/24 brd 10.10.10.255 scope global veth3e06cad
valid_lft forever preferred_lft forever
42sh$ ping 10.10.10.42
PING 10.10.10.42 (10.10.10.42) 56(84) bytes of data.
64 bytes from 10.10.10.42: icmp_seq=1 ttl=56 time=3.90 ms
64 bytes from 10.10.10.42: icmp_seq=2 ttl=56 time=3.78 ms
^C
--- 10.10.10.42 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1003ms
rtt min/avg/max/mdev = 3.789/3.847/3.906/0.085 ms
```
Dans l'exemple ci-dessus, l'interface dans le conteneur a l'IP `10.10.10.42`,
tandis que la machine hôte a l'IP `10.10.10.41`.
Astuces : vous pouvez utiliser la `libnetlink(3)` ou même faire des appels aux
programmes `ip(8)`, `brctl(8)`, ...
<https://github.com/shemminger/iproute2/blob/master/ip/ipnetns.c>
### Stage 10 (bonus) : seccomp
Filtrez les appels systèmes de telle sorte qu'aucun programme exécuté dans
votre bac à sable ne puisse plus appeler les appels systèmes suivants :
* `nfsservctl(2)` ;
* `personality(2)` ;
* `pivot_root(2)`.
Astuce : `seccomp(2)`.
## 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-TP4/questions.txt
login_x-TP4/chroot/escape.c
login_x-TP4/pseudofs/rev_kdb_leds.sh
login_x-TP4/pseudofs/procinfo
login_x-TP4/caps/view_caps
login_x-TP4/cgroups/monitor
login_x-TP4/cgroups/monitor_init
login_x-TP4/mymoulette/README
login_x-TP4/mymoulette/...
```