Typo + exo not in submissions
This commit is contained in:
parent
b459443d9e
commit
6fd83df1fd
@ -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`.
|
||||
|
||||
@ -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 :
|
||||
<https://www.kernel.org/doc/Documentation/cgroup-v1/>
|
||||
|
||||
|
||||
### 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 !
|
||||
|
||||
@ -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`.
|
||||
|
||||
@ -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/...
|
||||
```
|
||||
|
||||
@ -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 ?
|
||||
|
||||
@ -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 à
|
||||
<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.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user