diff --git a/tutorial/3/capabilities.md b/tutorial/3/capabilities.md index 52bb090..f16b7cc 100644 --- a/tutorial/3/capabilities.md +++ b/tutorial/3/capabilities.md @@ -27,7 +27,8 @@ On trouve par exemple : * `CAP_KILL` : permet de tuer n'importe quel processus ; * `CAP_SYS_BOOT` : permet d'arrêter ou de redémarrer la machine ; * `CAP_SYS_MODULE` : permet de charger et décharger des modules ; -* et beaucoup d'autres, il y en a environ 39 en tout ! +* et beaucoup d'autres, il y en a environ 39 en tout (ça dépend de la + version du noyau) ! ### `ping` @@ -44,16 +45,16 @@ 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 à 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. C'est donc à ce moment que les *capabilities* entrent en jeu : un processus (ou -même un thread) privilégié peut décider, à son lancement, de réduire ses -*capabilities*, pour ne garder que celles dont il a réellement besoin. Ainsi, -`ping` pourrait se contenter de `CAP_NET_RAW`. +même un thread) privilégié peut décider, généralement à son lancement, de +réduire ses *capabilities*, pour ne garder que celles dont il a réellement +besoin. Ainsi, `ping` pourrait se contenter de `CAP_NET_RAW`. ## Les attributs de fichier étendus @@ -95,8 +96,8 @@ cat: toto: Permission denied Hello World! ``` -Bien que les droits UNIX traditionnels ne vous donne pas accès au fichier, les -ACL POSIX vous autorisent à lire le contenu du fichier. +Bien que les droits UNIX traditionnels ne vous donnent pas accès au fichier, +les ACL POSIX vous autorisent à le lire. Vous pouvez voir ces attributs avec la commande : @@ -134,18 +135,41 @@ Ou, dans sa version plus lisible : ## Exercice : visualisateur de capabilities d'un processus -Écrivons maintenant un script permettant de voir les *capabilities* d'un -processus : +Écrivons maintenant un programme permettant de voir les *capabilities* +d'un processus : ```shell +42sh$ ./view_caps 1 +cap_user_header_t +----------------- +Version: 20080522 +PID: 1 + +cap_user_data_t +--------------- +effective: 0xffffffff + CAP_AUDIT_CONTROL + CAP_AUDIT_READ + CAP_AUDIT_WRITE + CAP_BLOCK_SUSPEND + CAP_CHOWN + CAP_DAC_OVERRIDE + CAP_DAC_READ_SEARCH +permitted: 0xffffffff + CAP_AUDIT_CONTROL + CAP_AUDIT_READ + CAP_AUDIT_WRITE + CAP_BLOCK_SUSPEND + CAP_CHOWN + CAP_DAC_OVERRIDE + CAP_DAC_READ_SEARCH +inheritable: 0x0 ``` -## Rendu +Astuces : `capget(2)`, X-macros, ... - - -## Aller plus loin +## Pour aller plus loin Je vous recommande la lecture des *man* suivants : @@ -154,7 +178,10 @@ Je vous recommande la lecture des *man* suivants : Et de ces quelques articles : -* [https://www.freedesktop.org/wiki/CommonExtendedAttributes/](Guidelines for - extended attributes) -* [https://lwn.net/Articles/211883/](File-based capabilities) -* [http://lwn.net/Articles/199004/](A bid to resurrect Linux capabilities) +* [Guidelines for extended attributes](https://www.freedesktop.org/wiki/CommonExtendedAttributes/) +* [File-based capabilities](https://lwn.net/Articles/211883/) +* [A bid to resurrect Linux capabilities](https://lwn.net/Articles/199004/) + +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`. diff --git a/tutorial/3/cgroups.md b/tutorial/3/cgroups.md index 177ff2b..ed54f00 100644 --- a/tutorial/3/cgroups.md +++ b/tutorial/3/cgroups.md @@ -165,7 +165,7 @@ curl -i -XPOST 'http://localhost:8086/write?db=metrics' --data-binary \ Pour vérifier que les données ont bien été ajoutées, vous pouvez effectuez la requête suivante dans l'interface web d'InfluxDB : -``` +```sql SELECT * from "$my_cgroup_name"; ``` @@ -183,13 +183,14 @@ Liste non exhaustive de données à monitorer : -### Permettre à l'utilisateur de monitorer des process +### Permettre à l'utilisateur de monitorer des processus Maintenant, séparer votre script en deux parties afin qu'un utilisateur normal (non-root) puisse utiliser la partie monitoring de notre script. Un premier script doit s'occuper de créer le(s) *cgroup*s et lui attribuer les bons droits, tandis que le deuxième va utiliser effectuer le monitoring, sans +privilèges particuliers. #### Exemple @@ -199,24 +200,6 @@ bons droits, tandis que le deuxième va utiliser effectuer le monitoring, sans ``` -## Rendu - -### Script de monitoring - -Rendez la révision la plus avancée de vos scripts de monitoring de processus. - -### Questions - -1. Un même processus peut-il être dans plusieurs *cgroup*s de type différents - (freezer et cpuacct par exemple) ? - -1. Que sera-t-il possible de limiter via un nouveau *cgroup* dans la prochaine - version du noyau (4.3) ? - -1. Actuellement, comment peut-on limiter le nombre de processus lancés par un - utilisateur ou un groupe ? - - ## Pour aller plus loin Depuis les noyaux 4.5, il est possible d'utiliser la nouvelle version du @@ -224,10 +207,9 @@ pseudo système de fichiers des *CGroup*s. Le principal changement vient du regroupement au sein d'une seule hiérarchie des différents *CGroup*s que l'on avait dans la v1. Davantage d'informations sont disponibles : -* [https://lwn.net/Articles/679786/](Understanding the new control groups API) +* [Understanding the new control groups API](https://lwn.net/Articles/679786/) ; -* [https://www.kernel.org/doc/Documentation/cgroup-v2.txt](Kernel Document - about Control Group v2). +* [Kernel Document about Control Group v2](https://www.kernel.org/doc/Documentation/cgroup-v2.txt). Pour tout connaître en détails, [la série d'articles de Neil Brown sur les Control groups](https://lwn.net/Articles/604609/) est excellente ! diff --git a/tutorial/3/chroot.md b/tutorial/3/chroot.md index f3b48ce..458bb47 100644 --- a/tutorial/3/chroot.md +++ b/tutorial/3/chroot.md @@ -3,7 +3,7 @@ L'isolation ... du pauvre ========================= -Depuis les premières version d'Unix, il est possible de changer le répertoire +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. @@ -18,7 +18,7 @@ mkdir newroot ### `busybox` -On a déjà parlé du porjet Busybox : c'est un programme linké statiquement, +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 @@ -34,7 +34,7 @@ chroot newroot /busybox ash `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 -dossier correspond au point de montage de la nouvelle racine choisi par +dossier correspond au point de montage de la nouvelle racine choisie par l'utilisateur lors de l'installation) le système de base. ```shell @@ -78,19 +78,12 @@ Mais une fois votre programme `escape` exécuté, vous devriez pouvoir ! ```shell ./escape -cat /path/to/foo + cat /path/to/foo ``` ## Rendu -### Fichiers - -Rendez un fichier `.c` contenant un programme qui, lorsqu'il est compilé puis -exécuté dans un chroot, permet de s'en échapper pour rejoindre la véritable -racine. - - ### Questions -1. Citez un moyen d'empêcher l'échappement du `chroot`. +1. Citez une solution empêchant l'échappement d'un `chroot`. diff --git a/tutorial/3/project.md b/tutorial/3/project.md index c01f178..6555f65 100644 --- a/tutorial/3/project.md +++ b/tutorial/3/project.md @@ -3,6 +3,9 @@ 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 @@ -30,7 +33,7 @@ principalement question de faire des appels système. ### Stage 1 : Restreindre l'environnement 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 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. @@ -38,8 +41,13 @@ 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. + ### Stage 2 : Réduire les *capabilities* @@ -61,11 +69,14 @@ rtt min/avg/max/mdev = 3.931/3.954/3.978/0.067 ms 59e714c4331e71ac3529a6502994ef1d bash# ping 8.8.8.8 - Operation not permitted + ping: icmp open socket: Permission denied ``` Astuces : `prctl(2)`, `capabilities(7)`, `capget(2)`, `capset(2)`, ... +Aidez-vous du visualisateur de *capabilities* de la partie 4, pour voir si vous +êtes sur la bonne voie. + ### Stage 3 : Utilisable par un utilisateur @@ -81,16 +92,16 @@ 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 rendez pas cet environnement, il vous sera seulement utile pour faire des - tests.** +**Ne mettez pas cet environnement dans votre tarball de rendu, il vous + sera seulement utile pour faire des tests.** ### Stage 4 : Isolation du pauvre Nous n'avons pas encore vu de meilleure méthode pour mieux isoler l'environnement que de faire un `chroot`, ajouter à votre programme cette -isolation rudimentaire. Et rendez-vous au prochain cours pour avoir de -moyen d'isolation ! +isolation rudimentaire. Et rendez-vous au prochain cours pour avoir une +meilleure d'isolation ! ### Stage 5 (bonus) : automatisation de la création de l'environnement @@ -127,16 +138,10 @@ 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 : ``` login_x-TP3/questions.txt -login_x-TP3/chroot/escape.c -login_x-TP3/pseudofs/rev_kdb_leds.sh -login_x-TP3/pseudofs/procinfo -login_x-TP3/caps/view_caps -login_x-TP3/cgroups/monitor -login_x-TP3/cgroups/monitor_init login_x-TP3/mymoulette/README login_x-TP3/mymoulette/... ``` diff --git a/tutorial/3/pseudofs.md b/tutorial/3/pseudofs.md index 933d8a9..191b2bf 100644 --- a/tutorial/3/pseudofs.md +++ b/tutorial/3/pseudofs.md @@ -28,11 +28,11 @@ programme d'initialisation en utilisant des systèmes de fichiers virtuels, mis à disposition par le noyau. Ces systèmes sont virtuels, car ils ne correspondent à aucune partition d'aucun -disque : l'arborescence est créé de toute pièce par le noyau pour trier les +disque : l'arborescence est créée de toute pièce par le noyau pour trier les informations mises à disposition, mais il n'est pas toujours possible d'y apporter des modifications. -Linux emploi de nombreux systèmes de fichiers virtuels : +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) ; @@ -44,14 +44,14 @@ Linux emploi de nombreux systèmes de fichiers virtuels : l'UEFI ; - ... -Tous ces systèmes de fichiers sont généralement exclusivement stocké en +Tous ces systèmes de fichiers sont généralement exclusivement stockés en RAM. Pour rendre une modification persistante, il est nécessaire de modifier un fichier de configuration qui sera chargé par le programme d'initialisation. Par exemple, pour modifier les paramètres du noyau, on passe par le fichier `/etc/sysctl.conf` et du programme `sysctl`. -## Exercice +## Exercices ### `rev_kdb_leds.sh` @@ -118,9 +118,22 @@ user:[4026531837] uts:[4026531838] ``` - ## Rendu -### Fichiers +### Questions -Rendez vos scripts `rev_kdb_leds.sh` et `procinfo`. +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. + +Il arrive quelque fois que le serveur de base de données soit tué par +l'OOM-killer alors que le serveur applicatif + +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 ? + +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 ? diff --git a/tutorial/3/tutorial.md b/tutorial/3/tutorial.md index c413193..07bf712 100644 --- a/tutorial/3/tutorial.md +++ b/tutorial/3/tutorial.md @@ -9,7 +9,7 @@ date: Jeudi 6 octobre 2016 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. -Tous les éléments de ce TP (exercices et questions) sont à rendre à +Certains éléments de ce TP (questions et projet) sont à rendre à 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.