2015-09-28 00:23:15 +00:00
|
|
|
[file]
|
|
|
|
slides.pdf
|
|
|
|
[duration]
|
|
|
|
180
|
|
|
|
[notes]
|
2015-09-29 19:34:30 +00:00
|
|
|
### Accueil
|
2015-09-28 00:23:15 +00:00
|
|
|
Bonjour
|
|
|
|
Hésitez pas à poser des questions
|
2015-09-29 19:34:30 +00:00
|
|
|
### John von Neumann
|
2015-09-28 00:23:15 +00:00
|
|
|
Commençons par parler de quelqu'un d'important...
|
2015-09-28 20:31:53 +00:00
|
|
|
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)
|
2015-09-29 19:34:30 +00:00
|
|
|
### Est-ce bien nécessaire : un noyau ?
|
2015-09-28 20:31:53 +00:00
|
|
|
- Gestion de la concurrence d'accès au matériel
|
2015-09-28 00:23:15 +00:00
|
|
|
- Répartition du temps CPU entre les tâches
|
|
|
|
- Gestion du contexte des tâches (mémoire, registres, context switch, ...)
|
2015-09-28 20:31:53 +00:00
|
|
|
- Gestion des erreurs (division par 0)
|
2015-09-28 00:23:15 +00:00
|
|
|
- Diverses couches d'abstraction :
|
|
|
|
- matériel : clavier/souris/...
|
|
|
|
- FS
|
2015-09-29 19:34:30 +00:00
|
|
|
### Est-ce bien nécessaire : le temps de boot ?
|
2015-09-28 00:23:15 +00:00
|
|
|
- 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
|
2015-09-29 19:34:30 +00:00
|
|
|
### Les techniques d'isolation : chroot
|
2015-09-28 00:23:15 +00:00
|
|
|
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é ?
|
2015-09-28 20:31:53 +00:00
|
|
|
pourquoi partager les données de services qui ne communiquent pas entre eux ?
|
2015-09-29 19:34:30 +00:00
|
|
|
### Est-ce bien nécessaire : d'isoler ?
|
2015-09-28 20:31:53 +00:00
|
|
|
- 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, ...
|
2015-09-29 19:34:30 +00:00
|
|
|
### Les techniques d'isolation : chroot
|
2015-09-28 00:23:15 +00:00
|
|
|
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)
|
2015-09-29 19:34:30 +00:00
|
|
|
=> ok pour de la défense en profondeur
|
|
|
|
Exemple : ING1 exams machine
|
|
|
|
### Les techniques d'isolation : virtualisation/paravirtualisation
|
2015-09-28 00:23:15 +00:00
|
|
|
- accès concurent au matos : périphériques émulés
|
|
|
|
- VT-x/AMD-v
|
|
|
|
- plusieurs serveurs sur le même port
|
|
|
|
- limitation des ressources
|
2015-09-29 19:34:30 +00:00
|
|
|
- on peut lancer différents OS/version
|
|
|
|
- similaire dupliqué : autant de noyaux lancés que de services, FS non partagés, MAJ
|
|
|
|
### Les techniques d'isolation : mais ...
|
|
|
|
- partager le même noyau, avec KVM : tout existe déjà : ordonanceur
|
|
|
|
- les FS identiques (on met à jour le système de base une seule)
|
2015-09-28 00:23:15 +00:00
|
|
|
|
|
|
|
* 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 !
|
2015-09-29 19:34:30 +00:00
|
|
|
PAUSE ?
|
|
|
|
### Made in Unix: Que doit-on isoler ?
|
2015-09-28 00:23:15 +00:00
|
|
|
- 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
|
2015-09-29 19:34:30 +00:00
|
|
|
- réseau : iface, table de routage, ports, etc.
|
2015-09-28 00:23:15 +00:00
|
|
|
- users, groups, nom de machine et IPC : pas de raison qu'ils soient partagés
|
2015-09-29 19:34:30 +00:00
|
|
|
- horloge : non, la timezone est un fichier
|
|
|
|
DEMO strace date => /etc/timezone
|
|
|
|
- logs kernel prévu dans une prochaine version
|
|
|
|
### Pour cette mission...
|
|
|
|
Que doit-on implémenter concrétement ?
|
|
|
|
- KVM fourni déjà plein de trucs
|
|
|
|
- ordonanceur VM/process => groupe
|
|
|
|
+ statistiques diverses pour limitation
|
|
|
|
+ mécanisme pour avoir plusieurs structures similaires (point de montage, user, iface réseau)
|
|
|
|
+ problématique de root : si on peut tout faire, on peut se balader partout...
|
|
|
|
### Made in Linux
|
2015-09-28 00:23:15 +00:00
|
|
|
- isoler plein de choses : Namespace
|
|
|
|
DEMO make menuconfig
|
2015-09-29 19:34:30 +00:00
|
|
|
DEMO namespace UTS, PID, (user?)
|
2015-09-28 00:23:15 +00:00
|
|
|
- limiter les ressources : cgroups
|
|
|
|
DEMO make menuconfig
|
|
|
|
DEMO limitation CPU
|
|
|
|
DEMO limitation mémoire
|
|
|
|
DEMO statistiques réseau
|
2015-09-29 19:34:30 +00:00
|
|
|
- capabilities : ~40 : CAP_KILL, CAP_SYS_TIME
|
2015-09-28 00:23:15 +00:00
|
|
|
DEMO capabilities
|
2015-09-29 19:34:30 +00:00
|
|
|
### Mais Jamy, comment ça marche ?
|
|
|
|
- recopie de la structure du parent (UTS, mount)
|
|
|
|
- création d'une nouvelle struct (network, PID, users, IPC)
|
|
|
|
- réseau : 1 iface = 1 ns
|
|
|
|
- processus : premier lancé PID 1 (2 PID : in/out NS)
|
|
|
|
- chaque process est lié à des namespace /proc/PID/ns/*
|
|
|
|
DEMO sudo ls -l /proc/1/ns/*
|
|
|
|
+ ouvrir ces fichiers : récupérer fd sur NS
|
|
|
|
### pour les nuls: SYSCALLS
|
|
|
|
utilise 3 syscalls pour gérer les NS :
|
|
|
|
- clone(2): nouveau process fils avec création de nouveau namespace en fonction des flags
|
|
|
|
- unshare(2): nouveau namespace pour le process courant
|
|
|
|
- setns(2): rejoindre un namespace existant
|
|
|
|
+ second argument pour filtrer le type de namespace, 0 accepte tout
|
|
|
|
### pour les nuls: FileSystem
|
|
|
|
- sous-arbre de la racine
|
|
|
|
- pivot_root: initramfs, racine d'une partition, pas d'autre FS monté sur celui qui va disparaître
|
|
|
|
- UnionFS: peut avoir plusieurs couches
|
|
|
|
+ cache les fichiers d'une même couche
|
|
|
|
+ récemment intégré dans le kernel 3.18 (décembre)
|
|
|
|
- Thin provisioning: allocation dynamique de l'espace disque
|
|
|
|
### pour les nuls: le réseau
|
2015-09-28 00:23:15 +00:00
|
|
|
- Réseau : pas évident :
|
|
|
|
* 1 carte réseau = 1 seule IP
|
|
|
|
* promiscuité
|
|
|
|
* routage
|
2015-09-29 19:34:30 +00:00
|
|
|
### pour les nuls: le réseau
|
2015-09-28 00:23:15 +00:00
|
|
|
- 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.
|
2015-09-29 19:34:30 +00:00
|
|
|
DEMO network namespace
|
|
|
|
### MAIS !
|
|
|
|
LXC stable depuis le 20 février 2014
|
2015-09-28 00:23:15 +00:00
|
|
|
DEMO LXC busybox
|
2015-09-29 19:34:30 +00:00
|
|
|
|
|
|
|
Doit-on tout virtualiser ? avoir toutes les bibliothèques et fichiers de base (init, syslog, cron, sshd, ...) ?
|
2015-09-28 00:23:15 +00:00
|
|
|
!!! QUESTIONS + PAUSE !!!
|