153 lines
4.8 KiB
Markdown
153 lines
4.8 KiB
Markdown
\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/...
|
|
```
|