tuto3: Spelling
This commit is contained in:
parent
be453216f8
commit
6b6f37b4a3
|
|
@ -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)` ;
|
||||
|
|
|
|||
|
|
@ -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 {
|
|||
</div>
|
||||
|
||||
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` :
|
||||
|
||||
<div lang="en-US">
|
||||
|
|
@ -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 :
|
|||
<https://forums.grsecurity.net/viewtopic.php?f=7&t=2522#p10271>
|
||||
* [Linux Capabilities on HackTricks](https://book.hacktricks.xyz/linux-unix/privilege-escalation/linux-capabilities) :\
|
||||
<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) :\
|
||||
<https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html>
|
||||
|
|
|
|||
|
|
@ -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) ;
|
||||
* ...
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
|||
```
|
||||
</div>
|
||||
|
||||
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 :
|
||||
|
||||
<div lang="en-US">
|
||||
|
|
@ -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].
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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` :
|
||||
|
||||
<div lang="en-US">
|
||||
```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
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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(<fd of eventfd()>, &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`.
|
||||
|
||||
|
|
|
|||
|
|
@ -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)` ;
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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 :\
|
||||
<https://www.kernel.org/doc/Documentation/power/power_supply_class.txt>.
|
||||
|
||||
---
|
||||
|
||||
##### `cpuinfo.sh` {-}\
|
||||
##### `cpuinfo.sh` {-}
|
||||
|
||||
Voici un exemple d'utilisation :
|
||||
|
||||
|
|
@ -181,7 +182,7 @@ Thermal throttle count: 0
|
|||
```
|
||||
</div>
|
||||
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
|||
```
|
||||
</div>
|
||||
|
||||
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).
|
||||
|
||||
:::::
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
...
|
||||
|
|
|
|||
|
|
@ -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)`.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
...
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 \
|
|||
```
|
||||
</div>
|
||||
|
||||
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 :
|
||||
|
||||
<div lang="en-US">
|
||||
|
|
@ -99,14 +99,14 @@ curl -s \
|
|||
```
|
||||
</div>
|
||||
|
||||
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 :
|
||||
|
||||
<div lang="en-US">
|
||||
|
|
|
|||
Loading…
Reference in New Issue