virli/slides/slides.pdfpc

[file]
slides.pdf
[duration]
180
[notes]
### 1
Bonjour
Hésitez pas à poser des questions
### 2
Commençons par parler de quelqu'un d'important...
Pourquoi aurait-on besoin de gaspiller du temps de calcul scientifique si précieux pour générer du code binaire ?
- 1 machine = 1 programme => perte de temps de calcul pendant les I/O
=> Ordonnanceur rudimentaires : partager le temps de calcul entre les bloquages d'I/O
=> problèmes : ex : partage de l'espace d'adressage (=> MMU)
### 3
- Gestion de la concurrence d'accès au matériel
- Répartition du temps CPU entre les tâches
- Gestion du contexte des tâches (mémoire, registres, context switch, ...)
- Gestion des erreurs (division par 0)
- Diverses couches d'abstraction :
  - matériel : clavier/souris/...
  - FS
### 4
- bootloader: charge le noyau en mem et jump
- détection du matériel
- mise en place des interfaces : réseau, FS, nom de machine, utilisateurs, droits, permissions, ...
- montage de la racine
- /sbin/init
### 5
Le noyau seul ne fait rien, il lui faut des programmes et des données.

Tous les programmes n'ont pas besoin de toutes les données.
Mais certains programmes échangent des données entre-eux (IPC, socket, ...)
Et s'il y a une vulnérabilité ?
pourquoi partager les données de services qui ne communiquent pas entre eux ?
### 7
- limitation quantité de RAM, BP réseau
- allocation du temps de calcul par groupe (1 serveur peut avoir plusieurs process qui sont schedulés indépendamment = triche !)
- DOS locaux => machine à genoux
- plusieurs serveur web/ssh
- sécu : droits root, exploit, ...
### 8
DEMO chroot
- complexe à mettre en œuvre
on peut pas avoir 2 serveurs web/ssh
- faible sécurité (grsec) + DEMO escape
- si un process tombe, on peut lui voler son port et hop
- arbre de process partagé
- pas de limitation des ressources
- coût : maj pas simples, monitoring peu précis (limitation des ports)
### 9
- accès concurent au matos : périphériques émulés
- VT-x/AMD-v
- plusieurs serveurs sur le même port
- limitation des ressources
- non partage des ressources similaires : autant de noyau lancé que de services, FS non partagés
### 10
- partager le même noyau (KVM...), les FS identiques (on met à jour le système de base une seule)

* 1998 : Jails BSD
* 2005 : Zones Solaris
* 2005 : patch Linux OpenVZ
* 2008 : début du projet Linux Container (LXC)
* 2015 : Windows 10

On appel ça des conteneurs !
### 11
Que doit-on implémenter concrétement ?
- matos : non, le noyau l'abstrait déjà (ex webcam/group video) mais limitation des ressources
- processus, interfaces réseau et liste de partitions montées pour éviter l'espionnage et l'accès à des données sensibles
- réseau :
- users, groups, nom de machine et IPC : pas de raison qu'ils soient partagés
- horloge : non, la timezone peut changer
### 12
- isoler plein de choses : Namespace
DEMO make menuconfig
DEMO namespace
- limiter les ressources : cgroups
DEMO make menuconfig
DEMO limitation CPU
DEMO limitation mémoire
DEMO statistiques réseau
- mais dans le monde Unix, root peut tout faire ... => capabilities
DEMO capabilities
### 13
- crée listes distinctes ou ajoute des propriétés
- FS : sous-arbre de la racine comme chroot + AUFS/OverlayFS (cache), LVM (thin provisioning)
- Processus : premier lancé PID 1 (2 PID : in/out NS)
### 14
- Réseau : pas évident :
* 1 carte réseau = 1 seule IP
* promiscuité
* routage
- iface physique : Ok
- MAC-VLAN : chaque machine a une MAC différente (promiscuité filtrée par le noyau)
2 modes : VEPA : tous les paquets sortent, le switch doit les renvoyer vers la même machine
Bridge : le noyau analyse les paquets sortant avant transmission
- veth : on partage une interface virtuelle entre l'hôte et l'invité et on relie le tout à un bridge.
### 15
LXC stable depuis
Doit-on tout virtualiser ? avoir toutes les bibliothèques et fichiers de base (init, syslog, cron, sshd, ...) ?
DEMO LXC busybox
!!! QUESTIONS + PAUSE !!!