Edit a subject

This commit is contained in:
nemunaire 2016-12-09 16:17:49 +01:00
parent 330199cf24
commit cad67995ae
14 changed files with 156 additions and 288 deletions

View File

@ -1,9 +1,21 @@
SOURCES = subject.md project-part1.md project-part2.md rendu.md end.md
PANDOCOPTS = --latex-engine=xelatex \
--standalone \
--normalize \
--smart \
-M lang=french \
-M fontsize=12pt \
-M papersize=a4paper \
-M mainfont="Linux Libertine O" \
-M monofont="Inconsolata" \
-M sansfont="Linux Biolinum O" \
--include-in-header=../tutorial/header.tex
all: subject.pdf
.md.pdf:
pandoc --latex-engine=xelatex --toc --normalize -M lang=frenchb --standalone -N --template=../template.tex -M fontsize=12pt -M papersize=a4paper -o $@ $<
subject.pdf: ${SOURCES}
pandoc ${PANDOCOPTS} -o $@ $+
.md.tex:
pandoc --latex-engine=xelatex --toc --normalize -N --template=../template.tex -M fontsize=12pt -M papersize=a4paper -o $@ $<
.SUFFIXES: .md .tex .pdf
clean::
rm subject.pdf

1
subject/end.md Normal file
View File

@ -0,0 +1 @@
Bon courage !

1
subject/project-part1.md Symbolic link
View File

@ -0,0 +1 @@
../tutorial/3/project-body.md

1
subject/project-part2.md Symbolic link
View File

@ -0,0 +1 @@
../tutorial/4/project-body.md

1
subject/rendu.md Symbolic link
View File

@ -0,0 +1 @@
../tutorial/4/project-rendu.md

View File

@ -1,163 +1,28 @@
% Virtualisation légère
% Pierre-Olivier *Nemunaire* Mercier
% Samedi 29 novembre 2014
---
title: Virtualisation légère -- Projet
author: Pierre-Olivier *Nemunaire* Mercier
institute: EPITA
date: EPITA -- SRS 2017
...
# Introduction
Le laboratoire des assistants a besoin de votre expertise afin de renforcer la
sécurité et la réactivité de son système de correction automatisé.
## Présentation du sujet
Durant ces prochaines heures, vous allez devoir réaliser un service de
déploiement de *machines virtuelles* légères, mettant en pratique les
connaissances que vous avez acquises durant le cours et le TP.
N'oublier pas de lire le sujet en entier, plusieurs fois, avant de
commencer. Vous n'êtes pas forcément tenu de réaliser les étapes dans l'ordre.
## Quelques conseils
* L'utilisation d'un gestionnaire de version est fortement recommandé.
* N'hésitez pas à préférer utiliser les
[API](https://qa.linuxcontainers.org/master/current/doc/api/) (et leur
bindings) plutôt que de faire des appels à des fonctions de type `system(3)`.
* N'oubliez pas de consulter avant toutes choses les `man` très fournis des
commandes que vous utiliserez ; en particulier tous les `lxc-*`,
`capabilities(7)`, ...
* Vous pouvez utiliser ou vous inspirer des images présentes sur le Hub Docker.
* Ne passez pas trop de temps sur l'interface, l'architecture des containers
est bien plus intéressante.
## Modalités de rendu
L'heure du rendu est fixé au dimanche 30 novembre 2014 à 11h42 CET.
Il est attendu que vous rendiez, à <virli@nemunai.re>, une tarball contenant un
ou plusieurs `Dockerfile` permettant d'obtenir l'interface de contrôle des
conteneurs, accompagnés d'un script automatisant le déploiement de la solution
sur une nouvelle machine (voir la section 2.2 pour les modalités de ce script).
## Notation
Chaque partie du sujet rapporte un certain nombre de points tenant compte de la
difficulté. Il est attendu que vous présentiez succinctement votre travail le
dimanche matin entre 8h et 12h. Vous pouvez effectuer votre rendu avant ou
après cette présentation à condition de respecter l'horaire indiqué à la
section précédente.
L'accent sera mis sur le respect des bonnes pratiques, en particulier sur
celles vue en cours ou en TP.
Votre projet consistera à réaliser la partie d'isolation de la moulinette des
ACUs : dans un premier temps vous ferez en sorte de restreindre un groupe de
processus pour qu'il ne puisse pas faire de déni de service sur notre machine ;
puis dans une seconde partie, vous vous assurerez de l'isolation de chaque
étudiant.
# Étapes de réalisation
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.
## Interface utilisateur
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 !
La première étape est de réaliser l'interface avec laquelle les utilisateurs
vont utiliser votre service.
Le langage (et le framework si besoin) est laissé à votre discrétion parmi
[Perl Dancer](https://metacpan.org/pod/Dancer),
[Python Django](http://djangoproject.com/) ou encore [PHP](http://php.net/).
Vous allez avoir besoin d'une base de données (MySQL/MariaDB ou PostgreSQL)
pour stocker la liste des conteneurs lancés, de leurs configuration, des images
disponibles, des utilisateurs, etc.
L'interface pourra prendre la forme d'une simple API ou de formulaires sur des
pages classiques. Chaque étape de ce sujet donne généralement lieu à une série
de pages.
## Recettes de déploiement (bonus)
Concevez les recettes de déploiement à destination d'un gestionnaire de
configuration (tel qu'[Ansible](http://docs.ansible.com/)) pour construire les
images des conteneurs et configurer la machine qui exécutera votre service.
La tarball que vous rendez doit permettre de déployer facilement (installation
de dépendance et docker build) votre solution ; prévoyez un script (non
optionel) si plus d'étape sont nécessaire pour construire vos conteneurs.
## Gestion d'un conteneur
Pour cette étape, votre site doit être en mesure de lancer et d'arrêter un
conteneur que vous aurez préalablement créé.
Le choix de la technologie de virtualisation est laissé à votre
discrétion.
Dans un premier temps, vous pouvez lancer vos conteneurs sans considération de
sécurité, en donnant tous les privilèges au conteneur de votre site, puis dans
un second temps, organisez une séparation des privilèges pour qu'un exploit sur
votre site ne remette pas en cause la sécurité de l'ensemble de la machine.
## Lancement de conteneur à partir de templates
Maintenant que vous êtes capable de lancer et d'arrêter un conteneur,
laissez la possibilité à l'utilisateur de lancer un nouveau conteneur à partir
d'un template LXC ou d'une image Docker.
À la fin de l'étape, vous devez être capable de lancer n'importe quel template
ou image.
## Quota disque (bonus)
Permettez à l'utilisateur de configurer l'espace disque dont il disposera dans
sa nouvelle machine virtuelle.
Cela peut se faire via l'utilisation d'un système de fichier gérant les quotas
(XFS, Btrfs, ZFS, ...) ou via LVM.
## Quota CPU/RAM/Réseau
Laissez la possibilité à l'utilisateur de configurer la quantité de mémoire
maximale que le conteneur peu utiliser ainsi que de permettre la limitation de
l'utilisation du CPU. Donner également la possibilité de limiter la bande
passante.
## Configuration réseau
Faites en sorte que l'utilisateur puisse exposer des ports de son conteneur sur
des ports de la machine hôte.
## Configuration réseau (avancé)
Mettez en place l'une des solutions de virtualisation réseau vue en cours,
permettant d'assigner à chaque conteneur une IP non-NATée.
## Gestion de conteneurs (avancé)
### Gel de conteneur
Donner la possibilité à l'utilisateur de suspendre (freeze) l'exécution d'un
conteneur et de la reprendre lorsqu'il le désire.
### Clone
Permettez à l'utilisateur de dupliquer un conteneur.
### Snapshots
Mettez en place un système de snapshots permettant de restaurer un
état antérieur, préalablement capturé.
# Astuces pour la présentation
* Des questions pourront vous être posées à propos de l'infrastructure
que vous avez mis en place, de notions vues durant le cours ou le
TP.
* Soyez en mesure de justifier vos choix !
* Vous êtes en SRS, n'oubliez pas de vous renseigner sur les techniques de
hardening à mettre en place ; si vous ne les avez pas mises en place ou pas
automatisé via le script de déploiement, n'oubliez pas d'indiquer les
changements durant la présentation.
Bon courage !
\hypersetup{linkcolor=black}
\tableofcontents

View File

@ -1,4 +1,4 @@
SOURCES = tutorial.md installation.md chroot.md pseudofs.md capabilities.md cgroups.md project.md
SOURCES = tutorial.md installation.md chroot.md pseudofs.md capabilities.md cgroups.md project-intro.md project-body.md project-rendu.md
PANDOCOPTS = --latex-engine=xelatex \
--standalone \
--normalize \

View File

@ -1,35 +1,3 @@
\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
@ -116,32 +84,3 @@ L'usage est laissé à votre discrétion : vous pouvez ajouter un/des paramètre
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/...
```

View File

@ -0,0 +1,30 @@
\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.

View File

@ -0,0 +1,27 @@
## 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/...
```

View File

@ -1,4 +1,4 @@
SOURCES = tutorial.md mount.md namespaces.md networkns.md pidns.md mountns.md userns.md project.md
SOURCES = tutorial.md mount.md namespaces.md networkns.md pidns.md mountns.md userns.md project-intro.md project-body.md project-rendu.md sondage.md
PANDOCOPTS = --latex-engine=xelatex \
--standalone \
--normalize \

View File

@ -1,30 +1,4 @@
\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, 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 !
### Stage 5 : Une vraie isolation
### Stage 5 : Une vraie isolation (3 points)
En plus du `chroot`, assignez de nouveaux namespaces au processus que vous
allez lancer : CGroups, IPC, mount, net, PID, UTS, user.
@ -35,7 +9,7 @@ namespaces !
Astuce : `unshare(2)`.
### Stage 6 : Empêcher les fuites d'information
### Stage 6 : Empêcher les fuites d'information (2 points)
Démonter tous les sytèmes de fichiers qui ne sont pas nécessaire au
fonctionnement de votre conteneur et remontez les partitions
@ -46,7 +20,7 @@ est nécessaire pour terminer l'étape d'isolation.
Astuce : `mount(2)`.
### Stage 7 : Identification du conteneur
### Stage 7 : Identification du conteneur (1 point)
Maintenant que vous avez votre conteneur, personalisez-le un peu en lui donnant
un nom unique.
@ -54,7 +28,7 @@ un nom unique.
Astuce : `sethostname(2)`
### Stage 8 : `pivot_root`
### Stage 8 : `pivot_root` (4 points)
Effectuer un `pivot_root(2)` de telle sorte qu'il ne reste plus de trace du
système de fichiers hôte.
@ -62,7 +36,7 @@ système de fichiers hôte.
Astuce : `pivot_root(2)`, `umount(2)`.
### Stage 9 : Bac à sable connecté
### Stage 9 : Bac à sable connecté (4 points)
Partant d'une liste d'interfaces sur la machine hôte similaire à :
@ -103,7 +77,7 @@ Astuces : vous pouvez utiliser la `libnetlink(3)` ou même faire des appels aux
programmes `ip(8)`, `brctl(8)`, ...
### Stage 10 (bonus) : seccomp
### Stage 10 (bonus) : seccomp (2 points)
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 :
@ -113,33 +87,3 @@ votre bac à sable ne puisse plus appeler les appels systèmes suivants :
* `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
Le projet à rendre pour ce cours est à placer dans une tarball (pas d'archive
ZIP, RAR, ...).
Voici une arborescence type:
```
login_x-mymoulette/README
login_x-mymoulette/...
```
## Sondage
Afin de me permettre d'améliorer ce cours, je vous invite à répondre à
[ces quelques questions](https://virli.nemunai.re/survey/). Merci d'avance !

View File

@ -0,0 +1,24 @@
\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, 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 !

View File

@ -0,0 +1,23 @@
## 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
Le projet à rendre pour ce cours est à placer dans une tarball (pas d'archive
ZIP, RAR, ...).
Voici une arborescence type:
```
login_x-mymoulette/README
login_x-mymoulette/...
```