virli/subject/2/project-part1.md

## Palier 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.


## Palier 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 :

<div lang="en-US">
```
42sh# ping 9.9.9.9
PING 9.9.9.9 (9.9.9.9) 56(84) bytes of data.
64 bytes from 9.9.9.9: icmp_seq=1 ttl=56 time=3.93 ms
64 bytes from 9.9.9.9: icmp_seq=2 ttl=56 time=3.97 ms
^C
--- 9.9.9.9 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
    c7d68d1cb4737125a84cd69f55add202

    bash# ping 9.9.9.9
    ping: icmp open socket: Permission denied
```
</div>

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

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


## Palier bonus : Utilisable par un utilisateur (2 points)  {-}

Jouez avec les attributs étendus pour qu'un utilisateur non-privilégié puisse
exécuter votre moulinette. Ajoutez 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.**


## Palier 3 : 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`, ajoutez à votre programme cette
isolation rudimentaire. Et rendez-vous au prochain cours pour avoir une
meilleure isolation !

<div lang="en-US">
```
42sh$ which firefox
/usr/bin/firefox
42sh# ./mymoulette ./newrootfs/ /bin/bash
    bash# which firefox
    which: no firefox in (/usr/bin:/usr/local/bin:/bin:/opt/bin)
```
</div>


## Palier 4 : seccomp (2 points)  {-}

Filtrez les appels systèmes de telle sorte qu'aucun programme exécuté dans
votre bac à sable ne puisse plus lancer les appels systèmes suivants :

* `nfsservctl(2)` ;
* `personality(2)` ;
* `pivot_root(2)` ;
* ...

N'hésitez pas à en utiliser d'autres pour vos tests ;)

**Astuces\ :** `seccomp(2)`, `seccomp_init(3)`, `seccomp_load(3)`, ...


## Palier 5 : Automatisation de la création de l'environnement (1 point)  {-}

Intégrer le script `registry_play.sh`, réalisé au TP précédent, à votre
programme afin de pouvoir créer un environnement neuf à chaque nouvelle
exécution.

Vous pouvez l'utiliser tel quel, ou le réécrire pour qu'il s'intègre plus
facilement au sein du langage que vous avez choisi.

L'appel du programme se fera alors ainsi, avec l'otion `-I` pour préciser que
l'on s'attend à trouver le nom d'une image Docker :

<div lang="en-US">
```
42sh# ./mymoulette -I library/alpine:latest /bin/ash
    ash# which apk
    /sbin/apk
```
</div>

Vous pourriez utiliser `mkdtemp(3)` pour déterminer l'emplacement de
décompression des tarballs d'image.