TP orthograf
This commit is contained in:
parent
fbd7a235e9
commit
356477228f
@ -1,11 +1,11 @@
|
||||
\newpage
|
||||
|
||||
Les capabilities
|
||||
================
|
||||
Les *capabilities*
|
||||
==================
|
||||
|
||||
## Présentation
|
||||
|
||||
Historiquement, dans la tradition UNIX, on distingait deux catégories de
|
||||
Historiquement, dans la tradition UNIX, on distinguait deux catégories de
|
||||
processus :
|
||||
|
||||
* les processus *privilégiés* : dont l'identifiant de son utilisateur est 0 ;
|
||||
@ -60,7 +60,7 @@ besoin. Ainsi, `ping` pourrait se contenter de `CAP_NET_RAW`.
|
||||
## Les attributs de fichier étendus
|
||||
|
||||
Une grosse majorité des systèmes de fichiers (ext[234], XFS, btrfs, ...)
|
||||
permettent d'enregistrer, pour chaque fichier, des attributs (dits attributs
|
||||
permet d'enregistrer, pour chaque fichier, des attributs (dits attributs
|
||||
*étendus*, par opposition aux attributs *réguliers* qui sont réservés à l'usage
|
||||
du système de fichiers).
|
||||
|
||||
@ -116,10 +116,10 @@ system.posix_acl_access=0sgAAEAD/////AgAEOgDAEAA/////xAABAD////8=
|
||||
|
||||
### `ping`
|
||||
|
||||
De la même manière que l'on peut définir de manière plus fine les droits
|
||||
d'accès par utilisateur, un attribut de l'espace de nom *security* peut être
|
||||
définit pour accroître les *capabilities* d'un processus lorsqu'il est lancé
|
||||
par un utilisateur non-privilégié. On peut alors voir le Setuid root comme
|
||||
De la même manière que l'on peut définir de façon plus fine les droits d'accès
|
||||
par utilisateur, un attribut de l'espace de nom *security* peut être défini
|
||||
pour accroître les *capabilities* d'un processus lorsqu'il est lancé par un
|
||||
utilisateur non-privilégié. On peut alors voir le Setuid root comme
|
||||
l'utilisation de cet attribut auquel on accroîtrait l'ensemble des
|
||||
*capabilities*.
|
||||
|
||||
|
||||
@ -5,8 +5,8 @@ Utiliser les *cgroup*s
|
||||
|
||||
Les *cgroup*s (pour *Control Group*s) permettent de collecter des statistiques
|
||||
sur des groupes de processus (appelés tâches) et de leur attribuer des
|
||||
propriétés, comme par exemple pour leur imposer des limitations d'utilisation
|
||||
de ressources ou altérer leurs priorités.
|
||||
propriétés. Par exemple, il est possible leur imposer des limites d'utilisation
|
||||
de ressources ou d'altérer leur comportement.
|
||||
|
||||
|
||||
## Premiers tests
|
||||
@ -30,7 +30,7 @@ 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 contenus dans cette racine sont donc des
|
||||
sous-groupes.
|
||||
|
||||
|
||||
@ -83,10 +83,10 @@ adaptés.
|
||||
|
||||
### Consultation de l'état
|
||||
|
||||
En affichant le contenu du dossier `virli`, nous pouvons constater que celui-ci
|
||||
contenait déjà un certain nombre de fichiers. Certain d'entre-eux sont en
|
||||
lecture seule et permettent de lire des statistiques instantanées sur le groupe
|
||||
; tandis que d'autres sont des propriétés que nous pouvons modifier.
|
||||
En affichant le contenu du dossier `virli`, nous pouvions constater que
|
||||
celui-ci contenait déjà un certain nombre de fichiers. Certain d'entre-eux sont
|
||||
en lecture seule et permettent de lire des statistiques instantanées sur le
|
||||
groupe ; tandis que d'autres sont des propriétés que nous pouvons modifier.
|
||||
|
||||
Nous pouvons consulter l'état de gel du groupe en affichant le contenu du
|
||||
fichier\newline `/sys/fs/cgroup/freezer/virli/freezer.state`.
|
||||
@ -155,7 +155,7 @@ EOF
|
||||
```
|
||||
</div>
|
||||
|
||||
Vérifiez bien que la base de données `metrics` a bien été créée.
|
||||
Vérifiez que la base de données `metrics` a bien été créée.
|
||||
|
||||
|
||||
### Monitoring instantané vers la console
|
||||
@ -165,16 +165,16 @@ mémoire utilisée par le groupe monitoré.
|
||||
|
||||
* Arguments de la ligne de commande :
|
||||
- premier fils à lancer dans le groupe,
|
||||
- intervalle de temps entre deux rafraîchissement ;
|
||||
- intervalle de temps entre deux rafraîchissements ;
|
||||
* *cgroup* `memory`;
|
||||
* `memory.usage_in_bytes`.
|
||||
|
||||
Vous pouvez utiliser un programme comme `memhog` pour remplir rapidement votre
|
||||
mémoire.
|
||||
|
||||
Si vous n'avez pas le *cgroup* memory, il est possible qu'il ne soit pas activé
|
||||
par défaut par votre système. Si vous êtes dans ce cas, essayez d'ajouter
|
||||
`cgroup_enable=memory` à la ligne de commande de votre noyau.
|
||||
Si vous n'avez pas le *cgroup* *memory*, il est possible qu'il ne soit pas
|
||||
activé par défaut par votre système. Si vous êtes dans ce cas, essayez
|
||||
d'ajouter `cgroup_enable=memory` à la ligne de commande de votre noyau.
|
||||
|
||||
|
||||
### Monitoring vers InfluxDB
|
||||
@ -219,8 +219,8 @@ Maintenant, séparons notre 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.
|
||||
bons droits, tandis que le deuxième va effectuer le monitoring, sans privilèges
|
||||
particuliers.
|
||||
|
||||
#### Exemple
|
||||
|
||||
|
||||
@ -23,7 +23,7 @@ mkdir newroot
|
||||
### `busybox`
|
||||
|
||||
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
|
||||
*linké* statiquement, c'est-à-dire qu'il ne va pas chercher ni 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 :
|
||||
@ -83,7 +83,7 @@ environnement qui tient dans 300 MB.
|
||||
|
||||
## Exercice
|
||||
|
||||
Écrivons maintenant un programme dont le seul but est de s'échaper du `chroot`:
|
||||
Écrivons maintenant un programme dont le seul but est de s'échapper du `chroot`:
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
|
||||
@ -44,14 +44,14 @@ Device Drivers --->
|
||||
|
||||
### Vérification via `menuconfig`
|
||||
|
||||
L'arbre ci-dessous correspond aux options qui seront *built-in* (signalée par
|
||||
une `*`) ou installées en tant que module (signalée par un `M`). En effet,
|
||||
L'arbre ci-dessous correspond aux options qui seront *built-in* (signalées par
|
||||
une `*`) ou installées en tant que module (signalées par un `M`). En effet,
|
||||
chaque noyau Linux peut être entièrement personnalisé en fonction des options
|
||||
et des pilotes que l'on voudra utiliser.
|
||||
|
||||
Pour parcourir l'arbre des options du noyau, il est nécessaire d'avoir les
|
||||
sources de celui-ci. Les dernières versions stables et encore maintenues sont
|
||||
disponible sur la page d'accueil de <https://kernel.org>.
|
||||
disponibles sur la page d'accueil de <https://kernel.org>.
|
||||
|
||||
Dans les sources, on affiche la liste des options avec la commande :
|
||||
|
||||
|
||||
@ -16,9 +16,9 @@ Gestion de la mémoire
|
||||
|
||||
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.
|
||||
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ée 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 utilise largement plus de mémoire
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
### Stage 1 : Restreindre l'environnement (2 points)
|
||||
### Palier 1 : Restreindre l'environnement (2 points)
|
||||
|
||||
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 utiliser les
|
||||
@ -17,7 +17,7 @@ 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* (2 points)
|
||||
### Palier 2 : Réduire les *capabilities* (2 points)
|
||||
|
||||
Réduisez au maximum les capabilities, de telle sorte qu'il ne soit pas possible
|
||||
de faire un ping dans l'environnement restreint :
|
||||
@ -48,7 +48,7 @@ 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 (1 point)
|
||||
### Palier 3 : Utilisable par un utilisateur (1 point)
|
||||
|
||||
Jouez avec les attributs étendus pour qu'un utilisateur non-privilégié puisse
|
||||
exécuter votre moulinette. Ajouter la/les commande(s) à votre Makefile ou
|
||||
@ -66,23 +66,23 @@ dans la partie sur les *chroot*.
|
||||
sera seulement utile pour faire des tests.**
|
||||
|
||||
|
||||
### Stage 4 : Isolation du pauvre (1 point)
|
||||
### Palier 4 : Isolation du pauvre (1 point)
|
||||
|
||||
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 une
|
||||
meilleure d'isolation !
|
||||
meilleure isolation !
|
||||
|
||||
|
||||
### Stage 5 (bonus) : automatisation de la création de l'environnement (5 points)
|
||||
### Palier 5 (bonus) : automatisation de la création de l'environnement (5 points)
|
||||
|
||||
Pour moulinéter plusieurs étudiants en parallèle, vous allez avoir besoin de
|
||||
Pour *moulinéter* plusieurs étudiants en parallèle, vous allez avoir besoin de
|
||||
plusieurs environnements identiques. Plutôt que de recopier cet environnement,
|
||||
de le nettoyer, de le recréer, pour chaque étudiant, ajoutez à votre moulinette
|
||||
un support pour LVM : utiliser des *snapshots* pour figer votre environnement
|
||||
et le dupliquer facilement pour chaque étudiant.
|
||||
|
||||
L'usage est laissé à votre discrétion : vous pouvez ajouter un/des paramètres à
|
||||
votre moulette pour indiquer le volume LVM à utiliser ou le définir en dur ou
|
||||
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.
|
||||
|
||||
@ -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ème.
|
||||
principalement question de faire des appels systèmes.
|
||||
|
||||
@ -10,7 +10,7 @@ envoyé à une autre adresse et/ou non signé et/ou reçu après la correction n
|
||||
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).
|
||||
[l'évaluation du cours](https://www.epitaf.fr/moodle/mod/quiz/view.php?id=40).
|
||||
|
||||
|
||||
## Tarball
|
||||
|
||||
@ -85,7 +85,7 @@ Voici les notes retrouvées dans les derniers échanges avec le sous-traitant :
|
||||
</div>
|
||||
|
||||
|
||||
### Pallier 0 : Récupérer les images
|
||||
### Palier 0 : Récupérer les images
|
||||
|
||||
Le sous-traitant a laissé des images Docker sur le Docker Hub, vous pourrez
|
||||
vous baser dessus pour commencer.
|
||||
@ -112,7 +112,7 @@ docker pull nemunaire/fic-admin nemunaire/fic-backend nemunaire/fic-frontend
|
||||
```
|
||||
|
||||
|
||||
### Pallier 1 : `docker-compose.yml`
|
||||
### Palier 1 : `docker-compose.yml`
|
||||
|
||||
Maintenant que vous arrivez à lancer les images, rendez cela reproductible en
|
||||
inscrivant tout ça dans un fichier YAML, compréhensible par `docker-compose` !
|
||||
@ -126,7 +126,7 @@ Vous devriez avoir ces services :
|
||||
* `nginx` (ou `apache`, ...)
|
||||
|
||||
|
||||
### Pallier 2 : retrouver les `Dockerfile`
|
||||
### Palier 2 : retrouver les `Dockerfile`
|
||||
|
||||
Maintenant que vous êtes en mesure de lancer le service, il serait temps de ne
|
||||
plus dépendre d'une image que l'on ne peut plus modifier facilement.
|
||||
@ -164,14 +164,14 @@ scripts et autant de `Dockerfile` que nécessaire à la tarball (mais vous
|
||||
devriez considérer l'option de mettre à jour votre Docker).
|
||||
|
||||
|
||||
### Pallier 3 : `fic-server.yml` prêt pour le déploiement
|
||||
### Palier 3 : `fic-server.yml` prêt pour le déploiement
|
||||
|
||||
À présent, faites les éventuelles adaptations nécessaires pour que votre
|
||||
fichier `docker-compose.yml` puisse s'exécuter au sein d'un cluster de
|
||||
plusieurs machines. Via `docker stack deploy`.
|
||||
|
||||
|
||||
### Pallier 4 : `fic-server.yml` prêt pour la production
|
||||
### Palier 4 : `fic-server.yml` prêt pour la production
|
||||
|
||||
Comme indiqué dans les notes du prestataire, en production, le frontend se
|
||||
trouve sur une machine distincte du backend.
|
||||
@ -181,7 +181,7 @@ données ! Il est fort probable que vous ayez à ajouter des services à votre
|
||||
fichier YAML.
|
||||
|
||||
|
||||
### Pallier 5 (bonus) : `fic-server.yml` sécurisé
|
||||
### Palier 5 (bonus) : `fic-server.yml` sécurisé
|
||||
|
||||
Vous avez indiqués des mots de passes bidons dans votre YAML ? Rangez les
|
||||
informations sensibles au sein de
|
||||
|
||||
Loading…
Reference in New Issue
Block a user