\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: 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: 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: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 [...] 2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 [...] 3: veth3e06cad@if82: 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)`, ... ### 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 , 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/... ```