From 6b6f37b4a30df21611eda1706af5b9737c020710 Mon Sep 17 00:00:00 2001 From: Pierre-Olivier Mercier Date: Tue, 18 Oct 2022 16:40:31 +0200 Subject: [PATCH] tuto3: Spelling --- subject/2/project-part1.md | 2 +- tutorial/3/capabilities.md | 33 ++++++++++++++------------- tutorial/3/cgroups-influx.md | 2 +- tutorial/3/cgroups.md | 14 +++++++----- tutorial/3/chroot-intro.md | 2 +- tutorial/3/chroot.md | 10 ++++---- tutorial/3/intro.md | 5 ++-- tutorial/3/oom.md | 4 ++-- tutorial/3/project-body.md | 2 +- tutorial/3/project-intro.md | 2 +- tutorial/3/pseudofs.md | 21 +++++++++-------- tutorial/3/rendu.md | 4 ++-- tutorial/3/seccomp.md | 7 +++--- tutorial/3/tutorial.md | 4 ++-- tutorial/4/howto.md | 2 +- tutorial/4/lesson.md | 2 +- tutorial/4/tutorial.md | 2 +- tutorial/docker-advanced/security.md | 2 +- tutorial/docker-internals/registry.md | 16 +++++++------ 19 files changed, 73 insertions(+), 63 deletions(-) diff --git a/subject/2/project-part1.md b/subject/2/project-part1.md index 1fc69ba..5f2627f 100644 --- a/subject/2/project-part1.md +++ b/subject/2/project-part1.md @@ -103,7 +103,7 @@ meilleure isolation ! ## Palier 4 : seccomp (2 points) {-} Filtrez les appels système de telle sorte qu'aucun programme exécuté dans -votre bac à sable ne puisse plus lancer les appels systèmes suivants : +votre bac à sable ne puisse plus lancer les appels système suivants : * `nfsservctl(2)` ; * `personality(2)` ; diff --git a/tutorial/3/capabilities.md b/tutorial/3/capabilities.md index a67b4d4..d213ef8 100644 --- a/tutorial/3/capabilities.md +++ b/tutorial/3/capabilities.md @@ -9,9 +9,10 @@ processus : * les processus *non-privilégiés* : dont l'identifiant numérique de son utilisateur n'est pas 0. -Lors des différents tests de permission fait par le noyau, les processus +Lors des différents tests de permission faits par le noyau, les processus privilégiés outrepassaient ces tests, tandis que les autres devaient passer les -tests de l'effective UID, effective GID, et autres groupes supplémentaires... +tests de l'*effective UID*, *effective GID*, et autres groupes +supplémentaires... Dans les années 90, ce système s'est rélévé être un peu trop basique et conduisait régulièrement à des abus, au moyen de vulnérabilités trouvées dans @@ -37,7 +38,7 @@ passe. Pourtant bien que l'on puisse lire le fichier `/etc/passwd`, seul `root` peut y apporter des modifications (il en est de même pour `/etc/shadow` qui contient les hashs des mots de passe). -C'est ainsi qu'est apparu le `suid-bit` parmi les modes des fichiers. Lorsque +C'est ainsi qu'est apparu le `suid-bit` parmi les modes de fichiers. Lorsque ce bit est défini sur un binaire exécutable, au moment de l'exécution, le contexte passe à celui du propriétaire du fichier (`root` si le propriétaire est `root`, mais cela fonctionne quelque soit le propriétaire du fichier : on @@ -68,7 +69,7 @@ d'écrire sur une interface réseau. ### Et ainsi les privilèges furent séparés Depuis Linux 2.2 (en 1998), les différentes actions réclamant des privilèges -sont regroupés en catégories que l'on appelle *capabilities*. Chacune donne +sont regroupées en catégories que l'on appelle *capabilities*. Chacune donne accès à un certain nombre d'actions, on trouve notamment : * `CAP_CHOWN` : permet de modifier le propriétaire d'un fichier de manière @@ -83,7 +84,7 @@ accès à un certain nombre d'actions, on trouve notamment : Petit point historique, Linux n'est pas à l'origine du concept de *capabilities*, il s'agit au départ de la norme POSIX 1003.1e, mais celle-ci -s'est éteinte auprès le 17e *draft*. Il devait y être standardisé de nombreux +s'est éteinte après le 17\textsuperscript{ème} *draft*. Il devait y être standardisé de nombreux composants améliorant la sécurité des systèmes POSIX, notamment les *capabilities* POSIX, les *ACL POSIX*, ... @@ -142,7 +143,7 @@ Tout d'abord, il faut noter que chaque *thread* dispose de 5 ensembles de *capabilities*. Ceux-ci sont utilisés de la façon suivante : - ***bounding*** (B) : c'est l'ensemble limitant des *capabilities* qui pourront - faire l'objet d'un calcul lors des prochaines exécutions. Quelques soit les + faire l'objet d'un calcul lors des prochaines exécutions. Quelques soient les *capabilities* que peut nous faire gagner une exécution, si la *capability* ne se trouve pas dans le *bounding set*, elle ne sera pas considérée et il sera impossible de l'obtenir. L'option `--cap-drop` de Docker modifie cet @@ -328,7 +329,7 @@ struct vfs_cap_data { La valeur `magic` contient la version sur 1 octet, puis 3 octets sont réservés -pour des flags. Actuellement un seul flag existe, il s'agit de +pour des *flags*. Actuellement un seul *flag* existe, il s'agit de `VFS_CAP_FLAGS_EFFECTIVE` qui détermine si la liste effective de *capabilities* du programme doit être remplie avec les *capabilities* *permitted* si elle doit rester vide (auquel cas ce sera au programme de s'ajouter les *capabilities* au @@ -391,7 +392,7 @@ naissance au nouveau processus et $p′$ le nouveau processus.\ On remarque que sans les *ambients capabilities*, on perd systématiquement les *capabilities* dont on disposait avant l'`execve(2)`, car $f_I$ n'est que très rarement défini sur un exécutable. Dans le cas général, on récupère donc soit -$f_P$, soit $p_A$ (les deux étant exclusif : si $f_P$ est défini, $p′_A$ est +$f_P$, soit $p_A$ (les deux étant exclusifs : si $f_P$ est défini, $p′_A$ est vide). Bien entendu, lorsque l'on se trouve dans le contexte d'exécution de `root` (ou @@ -436,7 +437,7 @@ par l'ensemble *bounding*. On utilise les appels système `capget(2)` et `capset(2)` pour respectivement connaître les *capabilities* actuelles de notre fil d'exécution et pour les -écraser. Ces appels systèmes utilisent une structure d'en-tête et une structure +écraser. Ces appels système utilisent une structure d'en-tête et une structure de données, qui sont définies dans `linux/capability.h` :
@@ -479,9 +480,9 @@ structures `vfs_cap_data` et `vfs_ns_cap_data` : il n'y a pas de notion de *namespace* ici. Il y a eu un couac dans les en-têtes distribués avec Linux 2.6.25, causant des -*buffers overflow* dans les applications qui n'avaient pas prévues de gérer les +*buffers overflow* dans les applications qui n'avaient pas prévu de gérer les versions. Cela a été corrigé dans la version 2.6.26 : un avertissement est -consigné dans les journaux systèmes en cas d'utilisation malheureuse de la +consigné dans les journaux système en cas d'utilisation malheureuse de la version 2. ::::: @@ -515,7 +516,7 @@ Le second paramètre attendu est l'une des constantes représentant une *capability*.\ Avec `PR_CAPBSET_READ`, `prctl(2)` retournera 0 si la *capability* ne fait pas -parti de l'ensemble *bounding*, ou 1 si elle est bien présente. +partie de l'ensemble *bounding*, ou 1 si elle est bien présente. Avec `PR_CAPBSET_DROP`, `prctl(2)` retirera la *capability* passée en argument de l'ensemble *bounding*. Une fois cette action effectuée, il est impossible de @@ -527,7 +528,7 @@ Dans la pratique, on préférera utiliser `cap_get_bound(3)` et ::::: Enfin, le *thread* peut aussi modifier à sa guise l'ensemble *ambient*, à -condition que les *capabilities* ajoutées soient dans les ensemble *permitted* +condition que les *capabilities* ajoutées soient dans les ensembles *permitted* et *inheritable*. ::::: {.code} @@ -541,7 +542,7 @@ préciser l'action que l'on veut réaliser :\ - `PR_CAP_AMBIENT_LOWER` : retire la *capability* précisée comme troisième paramètre ; - `PR_CAP_AMBIENT_IS_SET` : retourne 1 si la *capability* précisée comme - troisième paramètre fait parti de l'ensemble *ambient*, sinon retourne 0 ; + troisième paramètre fait partie de l'ensemble *ambient*, sinon retourne 0 ; - `PR_CAP_AMBIENT_CLEAR_ALL` : vide l'ensemble *ambient*. ::::: @@ -682,7 +683,7 @@ amont. Je vous recommande la lecture des *man* suivants : -* `capabilities(7)` : énumérant tous les capabilities, leur utilisation, etc. ; +* `capabilities(7)` : énumérant tous les *capabilities*, leur utilisation, etc. ; * `xattrs(7)` : à propos des attributs étendus. Et de ces quelques articles : @@ -697,5 +698,5 @@ Et de ces quelques articles : * [Linux Capabilities on HackTricks](https://book.hacktricks.xyz/linux-unix/privilege-escalation/linux-capabilities) :\ -- [POSIZ Access Control Lists on Linux](https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html) :\ +- [POSIX Access Control Lists on Linux](https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html) :\ diff --git a/tutorial/3/cgroups-influx.md b/tutorial/3/cgroups-influx.md index ab643a5..9d9ae42 100644 --- a/tutorial/3/cgroups-influx.md +++ b/tutorial/3/cgroups-influx.md @@ -68,7 +68,7 @@ SELECT * from "$my_cgroup_name"; Liste non exhaustive de données à monitorer : * Nombre d'IOs effectué ; -* nobre d'octets lus/écrits sur les disques ; +* nombre d'octets lus/écrits sur les disques ; * temps de calcul utilisé (`userspace`, `system`, tout confondu) ; * ... diff --git a/tutorial/3/cgroups.md b/tutorial/3/cgroups.md index 9a76c75..e044a5b 100644 --- a/tutorial/3/cgroups.md +++ b/tutorial/3/cgroups.md @@ -1,5 +1,3 @@ -\newpage - Les *cgroup*s ------------- @@ -33,10 +31,10 @@ spécifique : - [`freezer` :](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/freezer-subsystem.html) pour suspendre et reprendre l'exécution d'un groupe de tâches ; -- [`hugetlb` :](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/hugetlb.html) statistiques et limitation de l'usage de la fonctionnalité `HugeTLB` (permettant d'obtenir des pages mémoires plus grande que 4 kB) ; +- [`hugetlb` :](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/hugetlb.html) statistiques et limitation de l'usage de la fonctionnalité `HugeTLB` (permettant d'obtenir des pages mémoires plus grandes que 4 kB) ; - [`memory` :](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/memory.html) statistiques et limitation d'usage de la mémoire vive et de la *swap* ; - [`net_cls` (v1 seulement) :](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/net_cls.html) applique un `classid` à tous les paquets émis par les tâches du *cgroup*, pour filtrage par le pare-feu en sortie ; -- [`net_prio` (v1 seulement) :](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/net_prio.html) surcharge la valeur de l'option de priorité `SO_PRIORITY`, ordonant la file d'attente des paquets sortants ; +- [`net_prio` (v1 seulement) :](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/net_prio.html) surcharge la valeur de l'option de priorité `SO_PRIORITY`, ordonnant la file d'attente des paquets sortants ; - [`pids` :](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/pids.html) statistiques et limitation du nombre de processus ; - ... @@ -83,12 +81,16 @@ Avant d'aller plus loin, notez que les exemples seront donnés pour les deux versions des `cgroup`s à chaque fois. ::::: {.question} + +#### Quelles sont différences entre les deux versions des *cgroups* ? {-} + La principale différence entre les deux est la fusion des différents sous-systèmes au sein d'une même arborescence. Dans la première version, chaque sous-système disposait de sa propre arborescence et il fallait créer les groupes et associer les tâches pour chaque sous-système. Avec la seconde version, une seule création est nécessaire, quelque soit le nombre de sous-systèmes que l'on souhaite utiliser. + ::::: @@ -236,7 +238,7 @@ for i in $(seq 9999); do echo -n $i; sleep .1; echo -n " - "; sleep .1; done ```
-Maintenant, nous alloner donné l'ordre au noyau de ne plus allouer de temps de +Maintenant, nous allons donner l'ordre au noyau de ne plus allouer de temps de calcul à notre shell et ses fils :
@@ -388,7 +390,7 @@ limites que vous avez définies : ### Pour aller plus loin {-} -Pour tout connaître en détails, [la série d'articles de Neil Brown sur les +Pour tout connaître en détail, [la série d'articles de Neil Brown sur les Control groups](https://lwn.net/Articles/604609/)[^lwncgroups] est excellente ! Plus [cet article sur la version 2](https://lwn.net/Articles/679786/)[^lwncgroupsv2]. diff --git a/tutorial/3/chroot-intro.md b/tutorial/3/chroot-intro.md index b81822e..fce0b5b 100644 --- a/tutorial/3/chroot-intro.md +++ b/tutorial/3/chroot-intro.md @@ -4,7 +4,7 @@ En route vers la contenerisation ================================ Nous avons vu un certain nombre de fonctionnalités offertes par le noyau Linux -pour limiter ou autoriser ou contraindre différents usages des ressources de +pour limiter, autoriser ou contraindre différents usages des ressources de notre machine. Il est temps maintenant de commencer à parler d'isolation, mais ... cela fait diff --git a/tutorial/3/chroot.md b/tutorial/3/chroot.md index fc39261..30db29d 100644 --- a/tutorial/3/chroot.md +++ b/tutorial/3/chroot.md @@ -85,7 +85,7 @@ Oui, seul un utilisateur avec la *capability* `CAP_SYS_CHROOT` peut le faire !\ En fait, il est possible de duper le système avec un fichier `/etc/passwd` et `/etc/shadow` que l'on maîtrise, et un binaire *setuid root* tel que `su` : -`su` pourra nous demander le mot de passe `root` ou d'autre autre utilisateur, +`su` pourra nous demander le mot de passe `root` ou d'un autre utilisateur, mais comme on a la maîtrise du fichier `/etc/shadow`, on aura mis préalablement une valeur qui nous arrange. @@ -95,10 +95,10 @@ Jusque-là ... ça fonctionne, rien de surprenant ! Mais qu'en est-il pour `bash` :
-```bash +``` 42sh$ cp $(which bash) newroot/ 42sh# chroot newroot /bash -chroot: failed to run command ‘bash’: No such file or directory +chroot: failed to run command 'bash': No such file or directory ```
@@ -108,7 +108,7 @@ De quel fichier est-il question ici ? ### `debootstrap`, `pacstrap` `debootstrap` est le programme utilisé par l'installeur des distributions -Debian et ses dérivées. Il permet d'installer dans un dossier (en général, ce +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 choisie par l'utilisateur lors de l'installation) le système de base. @@ -122,7 +122,7 @@ debootstrap bullseye newroot/ http://httpredir.debian.org/debian/ peut s'utiliser depuis n'importe quel environnement ou distribution, `pacstrap` nécessite d'avoir installé et configuré `pacman` (le gestionnaire de paquets d'Arch Linux), ce qui est le cas si vous êtes sous Arch Linux ou ses -dérivées. +dérivés.
```bash diff --git a/tutorial/3/intro.md b/tutorial/3/intro.md index 5c3d08c..d6bbb22 100644 --- a/tutorial/3/intro.md +++ b/tutorial/3/intro.md @@ -4,8 +4,9 @@ Statistiques et contrôle des processus ====================================== Maintenant que nous avons pu voir en détail comment utiliser Docker, nous -allons tâcher d'apprendre comment il fonctionne en nous penchant sur un certain -nombre de fonctionnalités de Linux. +allons tâcher d'appréhender les techniques qu'il met en œuvre. De nombreuses +fonctionnalités du noyau Linux sont en effet sollicitées : certaines sont là +depuis longtemps, quelques unes sont standardisées, d'autres sont plus récentes. Dans un premier temps, nous allons aborder la manière dont le noyau Linux permet de contrôler les processus : que ce soit en collectant des informations diff --git a/tutorial/3/oom.md b/tutorial/3/oom.md index e44d85e..7060ef6 100644 --- a/tutorial/3/oom.md +++ b/tutorial/3/oom.md @@ -114,7 +114,7 @@ compte sont ceux contenus dans le `cgroup`. ## Esquiver l'OOM killer ? Le passage de l'OOM killer relevant parfois de la roulette russe, il peut être -intéressant, pour certain processus, de vouloir faire en sorte qu'ils aient +intéressant, pour certains processus, de vouloir faire en sorte qu'ils aient moins de chance d'arriver en tête du classement, même s'ils occupent beaucoup de mémoire. On pourrait par exemple vouloir que des services importants ou des programmes contenant notre travail en cours (potentiellement non-enregistré !) @@ -158,7 +158,7 @@ read(, &ret, sizeof(ret)); D'autres notifications peuvent être mises en place, selon le même principe sur d'autres fichiers, notamment `memory.usage_in_bytes`, pour être prévenu dès -lors que l'on franchi dans un sens ou dans l'autre un certain palier. Le palier +lors que l'on franchit dans un sens ou dans l'autre un certain palier. Le palier qui nous intéresse est à indiquer comme troisième argument à `cgroup.event_control`. diff --git a/tutorial/3/project-body.md b/tutorial/3/project-body.md index 1fc69ba..5f2627f 100644 --- a/tutorial/3/project-body.md +++ b/tutorial/3/project-body.md @@ -103,7 +103,7 @@ meilleure isolation ! ## Palier 4 : seccomp (2 points) {-} Filtrez les appels système de telle sorte qu'aucun programme exécuté dans -votre bac à sable ne puisse plus lancer les appels systèmes suivants : +votre bac à sable ne puisse plus lancer les appels système suivants : * `nfsservctl(2)` ; * `personality(2)` ; diff --git a/tutorial/3/project-intro.md b/tutorial/3/project-intro.md index ded052c..b271a49 100644 --- a/tutorial/3/project-intro.md +++ b/tutorial/3/project-intro.md @@ -21,4 +21,4 @@ moment où vous n'utilisez pas une bibliothèque qui abstrait complètement cett 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èmes. +principalement question de faire des appels système. diff --git a/tutorial/3/pseudofs.md b/tutorial/3/pseudofs.md index 893cdaf..940c4f1 100644 --- a/tutorial/3/pseudofs.md +++ b/tutorial/3/pseudofs.md @@ -126,10 +126,10 @@ uts:[4026531838] Explorons le pseudo système de fichiers `/sys` pour écrire un script qui va, en fonction de ce que vous avez de disponible : -* afficher des statistiques sur notre batterie ; -* afficher des statistiques la fréquence du CPU. +* afficher des statistiques sur votre batterie ; +* afficher des statistiques sur la fréquence du CPU. -##### `batinfo.sh` {-}\ +##### `batinfo.sh` {-} Voici un exemple d'utilisation : @@ -157,8 +157,9 @@ Remaining time: N/A Pour les détails sur l'organisation de ce dossier, regardez :\ . +--- -##### `cpuinfo.sh` {-}\ +##### `cpuinfo.sh` {-} Voici un exemple d'utilisation : @@ -181,7 +182,7 @@ Thermal throttle count: 0 ```
-N'hésitez pas à rajouter toute sorte d'information intéressantes ! +N'hésitez pas à rajouter toute sorte d'informations intéressantes ! #### `rev_kdb_leds.sh`, `suspend_schedule.sh` @@ -190,10 +191,10 @@ Maintenant que vous savez lire des informations dans `/sys`, tentons d'aller modifier le comportement de notre système. Au choix, réalisez l'un des scripts suivants, en fonction du matériel dont vous disposez : -* inverser l'état des diodes de notre clavier ; +* inverser l'état des diodes de votre clavier ; * mettre en veille votre machine, en ayant programmé une heure de réveil. -##### `rev_kdb_leds.sh` {-}\ +##### `rev_kdb_leds.sh` {-} Si vous avez : @@ -201,7 +202,7 @@ Si vous avez : * capslock Off, * scrolllock Off ; -Après avoir exécuté le script, nous devrions avoir : +Après avoir exécuté le script, vous devriez avoir : * numlock Off, * capslock On, @@ -218,7 +219,9 @@ Voici un exemple d'utilisation : `input20` correspond à l'identifiant de votre clavier, sous `/sys/class/input/`. -##### `suspend_schedule.sh` {-}\ +--- + +##### `suspend_schedule.sh` {-} Votre script prendra en argument l'heure à laquelle votre machine doit être réveillée, avant de la mettre effectivement en veille. diff --git a/tutorial/3/rendu.md b/tutorial/3/rendu.md index e195982..77ece97 100644 --- a/tutorial/3/rendu.md +++ b/tutorial/3/rendu.md @@ -7,10 +7,10 @@ Est attendu d'ici le cours suivant : - vos réponses à l'évaluation du cours, - [SRS] tous les exercices de ce TP, -- [GISTRE] les projets paliers du [projet final](https://virli.nemunai.re/project-gistre.pdf). +- [GISTRE] les premiers paliers du [projet final](https://virli.nemunai.re/project-gistre.pdf). -Arborescence attendue +Arborescence attendue (SRS) ------- Tous les fichiers identifiés comme étant à rendre sont à placer dans un dépôt diff --git a/tutorial/3/seccomp.md b/tutorial/3/seccomp.md index 53383c9..183a938 100644 --- a/tutorial/3/seccomp.md +++ b/tutorial/3/seccomp.md @@ -2,7 +2,7 @@ Secure Computing Mode --------------------- Plus connue sous l'acronyme *seccomp*, cette fonctionnalité du noyau Linux -permet de restreindre les appels systèmes qu'un processus est autorisé à +permet de restreindre les appels système qu'un processus est autorisé à utiliser. En cas d'appel non autorisé, le processus fautif est directement tué (`SIGKILL`) par le noyau, ou, lorsque c'est précisé, un code `errno` particulier peut être renvoyé au programme. @@ -53,7 +53,7 @@ autorisé conduit à un `SIGKILL` du processus. Plus modulable que le mode strict, le mode de filtrage permet une grande amplitude en permettant au programmeur de définir finement quels appels -systèmes le programme est autorisé à faire ou non, et quelle sentence est +système le programme est autorisé à faire ou non, et quelle sentence est exécutée en cas de faute. Notons que les processus fils issus (`fork(2)` ou `clone(2)`) d'un processus @@ -87,6 +87,7 @@ sleep: cannot read realtime clock: Operation not permitted ```
-Dans cet exemple, l'appel système filtré est `nanosleep(2)`. +Dans cet exemple, l'appel système filtré est `nanosleep(2)` (on +utilise `strace(2)` pour le découvrir). ::::: diff --git a/tutorial/3/tutorial.md b/tutorial/3/tutorial.md index a874b12..8decf02 100644 --- a/tutorial/3/tutorial.md +++ b/tutorial/3/tutorial.md @@ -7,11 +7,11 @@ date: Mercredi 19 octobre 2022 abstract: | 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. + *cgroups* ainsi que de *capabilities*. \vspace{1em} - Les exercices de ce cours sont à rendre au plus tard le mercredi 9 + Les exercices de ce cours sont à rendre au plus tard le mardi 8 novembre 2022 à 23 h 42. Consultez la dernière partie pour plus d'informations sur les éléments à rendre. ... diff --git a/tutorial/4/howto.md b/tutorial/4/howto.md index 219ac16..6d8b67c 100644 --- a/tutorial/4/howto.md +++ b/tutorial/4/howto.md @@ -55,7 +55,7 @@ Nous avons pu ici modifier le nom de la machine, sans que cela n'affecte notre machine hôte. -#### Les appels systèmes +#### Les appels système L'appel système par excellence pour contrôler l'isolation d'un nouveau processus est `clone(2)`. diff --git a/tutorial/4/lesson.md b/tutorial/4/lesson.md index bb7c5a7..e8d4cbc 100644 --- a/tutorial/4/lesson.md +++ b/tutorial/4/lesson.md @@ -6,7 +6,7 @@ institute: EPITA date: Mercredi 7 novembre 2018 abstract: | Le but de cette seconde partie sur les mécanismes internes du noyau - va nous permettre d'utiliser les commandes et les appels systèmes + va nous permettre d'utiliser les commandes et les appels système relatifs aux espaces de noms du noyau Linux ainsi que d'appréhender la complexité des sytèmes de fichiers. ... diff --git a/tutorial/4/tutorial.md b/tutorial/4/tutorial.md index 9e0b902..f6cf426 100644 --- a/tutorial/4/tutorial.md +++ b/tutorial/4/tutorial.md @@ -6,7 +6,7 @@ institute: EPITA date: Jeudi 7 octobre 2021 abstract: | Le but de ce second TP sur les mécanismes internes du noyau va nous - permettre d'utiliser les commandes et les appels systèmes relatifs + permettre d'utiliser les commandes et les appels système relatifs aux *namespaces* ainsi que d'appréhender la complexité des systèmes de fichiers. diff --git a/tutorial/docker-advanced/security.md b/tutorial/docker-advanced/security.md index 719c218..a9cb8f2 100644 --- a/tutorial/docker-advanced/security.md +++ b/tutorial/docker-advanced/security.md @@ -75,7 +75,7 @@ Si les capabilities sont un regroupement grossier de fonctionnalités du noyau, seccomp est un filtre que l'on peut définir pour chaque appel système. Liste blanche, liste noire, tout est possible. -Docker filtre notamment tous les appels systèmes qui pourraient +Docker filtre notamment tous les appels système qui pourraient déborder à l'extérieur du conteneur : il n'est par exemple pas possible de changer l'heure dans un conteneur, car il n'y a aujourd'hui aucun mécanisme pour isoler les visions des dates d'un diff --git a/tutorial/docker-internals/registry.md b/tutorial/docker-internals/registry.md index 343e780..1c23de1 100644 --- a/tutorial/docker-internals/registry.md +++ b/tutorial/docker-internals/registry.md @@ -14,7 +14,7 @@ contient pas de modification ou de suppression : chaque fichier est normal). L'authentification est facultative et est laissée à l'appréciation du fournisseur de service. Étant donné que nous allons utiliser le [Docker Hub](https://hub.docker.com/), le registre par défaut de `docker`, nous allons -devoir nous plier à leur mécanisme d'authentification : chaque requête au +devoir nous plier à son mécanisme d'authentification : chaque requête au registre doit être effectuée avec un jeton, que l'on obtient en s'authentifiant auprès d'un service dédié. Ce service peut délivrer un jeton sans authentifier l'interlocuteur, en restant anonyme ; dans ce cas, on ne pourra accéder qu'aux @@ -79,14 +79,14 @@ curl -s \ ``` -Dans la liste des manifests retournés, nous devons récupérer son `digest`. Dans +Dans la liste des *manifests* retournés, nous devons récupérer son `digest`. Dans tout l'écosystème OCI, les `digest` servent à la fois de chemin d'accès et de somme de contrôle. -## Lecture du manifest +## Lecture du *manifest* -Demandons maintenant le manifest correspondant à notre matériel et à notre +Demandons maintenant le *manifest* correspondant à notre matériel et à notre système d'exploitation :
@@ -99,14 +99,14 @@ curl -s \ ```
-Nous voici donc maintenant avec le manifest de notre image. Nous pouvons +Nous voici donc maintenant avec le *manifest* de notre image. Nous pouvons constater qu'il n'a bien qu'une seule couche, ouf ! ## Récupération de la configuration et de la première couche Les deux éléments que l'on cherche à récupérer vont se trouver dans le -répertoire `blobs`, il ne s'agit en effet plus de manifest. Si les manifests +répertoire `blobs`, il ne s'agit en effet plus de *manifest*. Si les *manifests* sont toujours stockés par le registre lui-même, les blobs peuvent être délégués à un autre service, par exemple dans le cloud, chez Amazon S3, un CDN, etc. @@ -133,7 +133,7 @@ wget --header "Authorization: Bearer ${TOKEN}" \ ## Extraction -Le type indiqué par le manifest pour cette couche était : +Le type indiqué par le *manifest* pour cette couche était : application/vnd.docker.image.rootfs.diff.tar.gzip @@ -159,6 +159,8 @@ Hello from Docker! ::::: {.exercice} +#### Assemblage {-} + Réalisez un script pour automatiser l'ensemble de ces étapes :