teach/virli
1
0
Fork 0
Code Issues Pull Requests Releases Activity

Work on TP3

Browse Source
This commit is contained in:
nemunaire 2017-10-23 00:14:32 +02:00
parent d3abdfa1d1
commit 1aa9530f3a
8 changed files with 132 additions and 105 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
tutorial/3/capabilities.md
View File

@ -5,7 +5,7 @@ Les capabilities
## Présentation
Historiquement, dans la tradition UNIX, on distingue deux catégories de
Historiquement, dans la tradition UNIX, on distingait deux catégories de
processus :
* les processus *privilégiés* : dont l'identifiant de son utilisateur est 0 ;
@ -40,16 +40,16 @@ faire, il est nécessaire de pouvoir écrire directement sur l'interface ; ça,
seul le super-utilisateur peut le faire.
Pour permettre à tous les utilisateurs de pouvoir envoyer des ping, le
programme est donc généralement Setuid root. Cela permet à n'importe quel
programme est donc généralement *Setuid root*. Cela permet à n'importe quel
utilisateur de prendre les droits du super-utilisateur, le temps de l'exécution
du programme.
Les problèmes surviennent lorsque l'on découvre des vulnérabilités dans les
programmes Setuid root. En effet, s'il devient possible pour un utilisateur
programmes *Setuid root*. En effet, s'il devient possible pour un utilisateur
d'exécuter du code arbitraire, ce code sera exécuté avec les privilèges de
l'utilisateur root ! Dans le cas de ping, on se retrouverait alors à pouvoir
lire l'intégralité de la mémoire, alors que l'on avait juste besoin d'écrire
sur une interface réseau.
l'utilisateur *root* ! Dans le cas de `ping`, on se retrouverait alors à
pouvoir lire l'intégralité de la mémoire, alors que l'on avait juste besoin
d'écrire sur une interface réseau.
C'est donc à ce moment que les *capabilities* entrent en jeu : un processus (ou
même un thread) privilégié peut décider, généralement à son lancement, de
@ -197,4 +197,4 @@ Et de ces quelques articles :
Pour revenir à Docker, par défaut, un certain nombre de *capabilities* sont
désactivées par défaut ; vous pouvez en ajouter et en retirer via les arguments
`--cap-add` et `--cap-drop` du `docker run`.
`--cap-add` et `--cap-drop` du `docker container run`.

62
tutorial/3/cgroups.md
View File

@ -11,7 +11,7 @@ de ressources ou altérer leurs priorités.
## Premiers tests
Nous allons commencer par faire quelques tests avec le *cgroup* freezer, qui
Nous allons commencer par faire quelques tests avec le *cgroup* *freezer*, qui
permet d'interrompre l'exécution d'un groupe de processus et de la reprendre.
@ -30,17 +30,16 @@ mount -t cgroup -o freezer none /sys/fs/cgroup/freezer/
</div>
Cette dernière commande monte le groupe de processus racine, pour le *cgroup*
freezer. Tous les dossiers contenu dans cette racine sont donc des
*freezer*. Tous les dossiers contenu dans cette racine sont donc des
sous-groupes.
### Création d'un nouveau groupe
La première étape dans l'utilisation d'un *cgroup* est de créer un nouveau
groupe.
La première étape dans l'utilisation d'un *cgroup* est de créer un groupe.
Pour créer un groupe, il suffit de créer un nouveau dossier dans un groupe
existant, par exemple la racine :
Pour ce faire, il suffit de créer un nouveau dossier dans un groupe existant,
par exemple la racine :
<div lang="en-US">
```
@ -50,7 +49,7 @@ ls /sys/fs/cgroup/freezer/virli/
</div>
Nous avons maintenant un nouveau groupe de processus `virli` dans le *cgroup*
Freezer. Comme il s'agit d'une hiérarchie, le groupe `virli` hérite des
*Freezer*. Comme il s'agit d'une hiérarchie, le groupe `virli` hérite des
propriétés de son (ses) père(s).
@ -58,7 +57,7 @@ propriétés de son (ses) père(s).
Pour le moment, ce nouveau groupe ne contient aucune tâche.
Ouvrons un nouveau terminal (c'est lui que l'on va freezer), et récupérons son
Ouvrons un nouveau terminal (c'est lui que l'on va geler), et récupérons son
PID : `echo $$`.
La liste des processus rattachés à un *cgroup* se trouve dans le fichier `task`
@ -76,6 +75,11 @@ En validant cette commande, nous avons déplacé le processus dans ce groupe, il
n'est alors plus dans aucun autre groupe (pour ce *cgroup*, il ne bouge pas
dans les autres *cgroup*s).
Malgré l'utilisation de la redirection `>` (et non `>>`), il s'agit belle et
bien d'un ajout au fichier et non d'un écrasement. Il faut garder en tête que
le système de fichier est entièrement simulé et que certains comportements sont
adaptés.
### Consultation de l'état
@ -88,7 +92,7 @@ Nous pouvons consulter l'état de gel du groupe en affichant le contenu du
fichier\newline `/sys/fs/cgroup/freezer/virli/freezer.state`.
Pour plus d'information sur les différents fichiers présents dans ce *cgroup*,
consulter
consultez
[la documentation associée](https://www.kernel.org/doc/Documentation/cgroup-v1/freezer-subsystem.txt).
@ -135,23 +139,28 @@ l'installer sur notre machine) :
<div lang="en-US">
```shell
docker run -d -p 8086:8086 -p 8083:8083 influxdb
docker container run --name mytsdb -d -p 8086:8086 influxdb
```
</div>
Il nous faut ensuite créer une base de données pour y stocker les métriques,
rendez-vous à <http://localhost:8083/> puis entrez la requête :
Il nous faut ensuite créer une base de données pour y stocker nos
métriques. Voici comment on s'était débrouillé dans un précédent TP :
<div lang="en-US">
```sql
```shell
docker container exec -i mytsdb <<EOF
CREATE DATABASE metrics;
SHOW DATABASES;
EOF
```
</div>
Vérifiez bien que la base de données `metrics` a bien été créée.
### Monitoring instantané vers la console
Dans un premier temps, commençons par afficher dans la console la quantité de
Dans un premier temps, commençons par afficher dans la console, la quantité de
mémoire utilisée par le groupe monitoré.
* Arguments de la ligne de commande :
@ -171,7 +180,7 @@ par défaut par votre système. Si vous êtes dans ce cas, essayez d'ajouter
### Monitoring vers InfluxDB
Maintenant, envoyons nos données vers la base
<https://docs.influxdata.com/influxdb/v1.0/guides/writing_data/> :
<https://docs.influxdata.com/influxdb/v1.3/guides/writing_data/> :
<div lang="en-US">
```
@ -181,7 +190,7 @@ curl -i -XPOST 'http://localhost:8086/write?db=metrics' --data-binary \
</div>
Pour vérifier que les données ont bien été ajoutées, nous pouvons effectuer la
requête suivante dans l'interface web d'InfluxDB :
requête suivante dans notre client `influx` :
<div lang="en-US">
```sql
@ -225,12 +234,27 @@ privilèges particuliers.
## Fixer des limites
Au delà de la simple consultation,
Au delà de la simple consultation, les *cgroup*s peuvent servir à limiter la
quantité de ressources mise à disposition à un groupe de processus.
Pour définir une limite, nous allons écrire la valeur dans le fichier
correspondant à une valeur limite, comme par exemple
`memory.max_usage_in_bytes`, qui limite le nombre d'octets que notre groupe de
processus va pouvoir allouer au maximum :
## OOM-killer
```shell
42sh$ cat /sys/fs/cgroup/memory/virli/memory.max_usage_in_bytes
0
# 0 = Aucune limite
42sh$ echo 4M > /sys/fs/cgroup/memory/virli/memory.max_usage_in_bytes
# Maintenant, la limite est à 4MB, vérifions...
42sh$ cat /sys/fs/cgroup/memory/virli/memory.max_usage_in_bytes
4194304
```
<!-- https://lwn.net/Articles/590960/ -->
Chaque *cgroup*s défini de nombreux indicateurs et possède de nombreux
limiteurs, n'hésitez pas à consulter la documentation associée à chaque
*cgroup*.
## Pour aller plus loin

35
tutorial/3/chroot.md
View File

@ -5,7 +5,8 @@ L'isolation ... du pauvre
Depuis les premières versions d'Unix, il est possible de changer le répertoire
vu comme étant la racine du système de fichiers. En anglais : *change root*:
`chroot`.
`chroot`. Le processus effectuant cette action ainsi que tous ses fils, verront
donc une racine différente du reste du système.
## Mise en place de l'environnement
@ -21,11 +22,11 @@ mkdir newroot
### `busybox`
On a déjà parlé du projet Busybox : c'est un programme linké statiquement,
c'est-à-dire qu'il n'a pas de dépendance sur des bibliothèques
dynamiques. Il se suffit donc à lui-même dans un chroot (dans lequel on ne peut
pas accéder aux bibliothèques du système, il faudrait toutes les copier à la
main).
Queques mots, pour commencer, à propos du projet Busybox : c'est un programme
*linké* statiquement, c'est-à-dire qu'il ne va pas chercher et charger de
bibliothèque dynamique à son lancement. Il se suffit donc à lui-même dans un
*chroot*, car il n'a pas de dépendances. Nous pouvons donc tester notre
première isolation :
<div lang="en-US">
```shell
@ -34,11 +35,24 @@ chroot newroot /busybox ash
```
</div>
Jusque là ... ça fonctionne, rien de surprenant ! Mais qu'en est-il pour
`bash` :
<div lang="en-US">
```shell
42sh$ cp $(which bash) newroot/
42sh# chroot newroot /bash
chroot: failed to run command ‘bash’: No such file or directory
```
</div>
De quel fichier est-il question ici ?
### `debootstrap`
`debootstrap` est le programme utilisé par l'installeur des distributions
Debian et ses dérivés. Il permet d'installer dans un dossier (en général, ce
Debian et ses dérivées. Il permet d'installer dans un dossier (en général, ce
dossier correspond au point de montage de la nouvelle racine choisie par
l'utilisateur lors de l'installation) le système de base.
@ -95,10 +109,3 @@ Mais une fois votre programme `escape` exécuté, vous devriez pouvoir !
cat /path/to/foo
```
</div>
## Rendu
### Questions
1. Citez une solution empêchant l'échappement d'un `chroot`.

5
tutorial/3/installation.md
View File

@ -110,7 +110,7 @@ Dans la plupart des autres distributions, la configuration est accessible à
travers le fichier `/proc/config.gz`. Comme vous ne pouvez pas écrire dans
`/proc` pour décompresser le fichier, utilisez les outils `zcat`, `zgrep`, ...
Vous devez retrouves les mêmes options que celles de la section précédente.
Vous devez retrouver les mêmes options que celles de la section précédente.
@ -121,4 +121,5 @@ requises seront a priori déjà sélectionnées et vous n'aurez donc pas à comp
votre propre noyau. Néanmoins, durant ce TP, nous allons nous interfacer avec
le noyau, il est donc nécessaire d'avoir les en-têtes de votre noyau.
Sous Debian, vous pouvez les installer via le paquet `linux-headers`.
Sous Debian, vous pouvez les installer via le paquet au nom semblable
à `linux-headers`.

6
tutorial/3/project-intro.md
View File

@ -3,14 +3,8 @@
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 !

19
tutorial/3/project-rendu.md
View File

@ -9,21 +9,26 @@ 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.
Par ailleurs, n'oubliez pas de répondre à
[l'évaluation du cours](https://www.epitaf.fr/moodle/mod/quiz/view.php?id=34).
## 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 :
Voici une arborescence type (adaptez les extensions et les éventuels
fichiers supplémentaires associés au langage que vous aurez choisi
pour chaque exercice) :
<div lang="en-US">
```
login_x-TP3/questions.txt
login_x-TP3/mymoulette/README
login_x-TP3/mymoulette/...
login_x-TP3/escape.c
login_x-TP3/procinfo.sh
login_x-TP3/rev_kdb_leds.sh
login_x-TP3/view_caps.c
login_x-TP3/monitor.sh
login_x-TP3/monitor_init.sh
```
</div>

85
tutorial/3/pseudofs.md
View File

@ -6,10 +6,14 @@ Pseudos systèmes de fichiers
## Rappels sur les points de montage
Les systèmes Unix définissent le système de fichiers comme étant un arbre
unique partant d'une racine[1] et où l'on peut placer au sein de son arborescence
unique partant d'une racine[^FHS] et où l'on peut placer au sein de son arborescence
des points de montage. Ainsi, l'utilisateur définit généralement deux points de
montage :
[^FHS]: Consultez
<https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard> pour
plus de détails sur l'arboresence.
<div lang="en-US">
```
/dev/sda1 on / type ext4 (rw,relatime,data=ordered)
@ -38,10 +42,10 @@ Linux emploie de nombreux systèmes de fichiers virtuels :
- `/proc` : contient, principalement, la liste des processus (`top` et ses
dérivés se contentent de lire les fichiers de ce point de montage) ;
- `/proc/sys` : configuration du noyau ;
- `/sys` : contient des informations à propos du matériel (utilisées
notamment pour peupler `/dev`) et des périphériques (taille des
tampons, clignottement des DELs, ...) ;
- `/proc/sys` : contient la configuration du noyau ;
- `/sys` : contient des informations à propos du matériel (utilisées notamment
par `udev` pour peupler `/dev`) et des périphériques (taille des tampons,
clignottement des DELs, ...) ;
- `/sys/firmware/efi/efivars` : pour accéder et modifier les variables de
l'UEFI ;
- ...
@ -53,33 +57,25 @@ exemple, pour modifier les paramètres du noyau, on passe par le fichier
`/etc/sysctl.conf` et du programme `sysctl`.
## Exercices
### Consultation et modification
### `rev_kdb_leds.sh`
La consultation d'un élément se fait généralement à l'aide d'un simple `cat` :
Explorons le pseudo système de fichiers `/sys` pour écrire un script
qui va inverser l'état des diodes de notre clavier.
Si vous avez :
* numlock On,
* capslock Off,
* scrolllock Off ;
Après avoir exécuté le script, nous devrions avoir :
* numlock Off,
* capslock On,
* scrolllock On.
Voici un exemple d'utilisation :
<div lang="en-US">
```shell
42sh$ ./rev_kdb_leds.sh input20
42sh$ cat /sys/power/state
freeze mem
```
</div>
La modification d'un élément se fait avec `echo`, comme ceci :
```shell
echo mem > /sys/power/state
```
Vous devriez constater l'effet de cette commande sans plus attendre !
## Exercices
### `procinfo`
@ -124,25 +120,28 @@ uts:[4026531838]
```
</div>
## Rendu
### Questions
### `rev_kdb_leds.sh`
Sur le serveur `antares`, un serveur applicatif critique tourne aux côtés de sa
base de données PostgreSQL. Le serveur applicatif étant connu pour produire un
grand nombre de leak, il est relancé chaque nuit. Le serveur applicatif tourne
en root car plus personne ne sait le paramétrer ; la base de données a été
installé par le système de paquets de la distribution.
Explorons le pseudo système de fichiers `/sys` pour écrire un script
qui va inverser l'état des diodes de notre clavier.
Il arrive quelque fois que le serveur de base de données soit tué par
l'OOM-killer alors que le serveur applicatif utilise largement plus de mémoire
à la fin de la journée.
Si vous avez :
1. Quel paramètre du processus pourrait-on modifier pour que ce soit le serveur
applicatif qui aie plus de chance de se faire tuer par l'OOM-killer ?
* numlock On,
* capslock Off,
* scrolllock Off ;
2. Pourquoi est-ce le serveur de base de données qui est principalement tiré au
sort pour être tué en cas de manque de mémoire plutôt que le serveur
applicatif qui occupe pourtant bien plus de mémoire ?
Après avoir exécuté le script, nous devrions avoir :
[1]: Consultez <https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard> pour plus de détails sur l'arboresence.
* numlock Off,
* capslock On,
* scrolllock On.
Voici un exemple d'utilisation :
<div lang="en-US">
```shell
42sh$ ./rev_kdb_leds.sh input20
```
</div>

11
tutorial/3/tutorial.md
View File

@ -3,24 +3,21 @@ title: Virtualisation légère -- TP n^o^ 3
subtitle: Linux Internals partie 1
author: Pierre-Olivier *Nemunaire* Mercier
institute: EPITA
date: Jeudi 6 octobre 2016
date: Jeudi 26 octobre 2017
...
Ce premier TP consacré aux Linux Internals va nous permettre d'appréhender les
notions de pseudos systèmes de fichiers, de cgroups ainsi que de capabilities.
Certains éléments de ce TP (questions et projet) sont à rendre à
<virli@nemunai.re> au plus tard le jeudi 20 octobre 2016 à 8 h 42. Consultez la
dernière section de chaque partie pour plus d'information sur les éléments à
rendre.
Certains éléments de ce TP sont à rendre à <virli@nemunai.re> au plus tard le
jeudi 2 novembre 2017 à 8 h 42. Consultez la dernière section de chaque partie
pour plus d'information sur les éléments à rendre.
En tant que personnes sensibilisées à la sécurité des échanges électroniques,
vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
[me](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x842807A84573CC96) faire
signer votre clef et n'hésitez pas à
[faire signer votre clef](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
Vous pouvez utiliser l'adresse <signcheck@nemunai.re> pour savoir si vous vous
y prenez correctement.
\hypersetup{linkcolor=black}
\tableofcontents