Docker, Inc.

Docker Community Edition (CE)

Logiciel libre de gestionnaire de conteneurs

Plan de tests

Version 1.0

16 avril 2019
Table des matières

1 Introduction 3
1.1 Objet du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Identification du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Documents applicables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Installation du produit 4
2.1 Options d’installation retenues pour le produit . . . . . . . . . . . . . . . . . . . 4
2.2 Description de l’installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Analyse de résistance des fonctions et mécanismes 8

3.1 Fonctions métier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1 Fonctions d’administration . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2 Fonctions de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.3 Journalisation locale d’évènements . . . . . . . . . . . . . . . . . . . . . . 8
3.1.4 Journalisation des conteneurs . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Fonctions de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1 Cloisonnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2 Isolation des ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3 Restriction des privilèges . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.4 Limitation des accès aux ressources . . . . . . . . . . . . . . . . . . . . . . 15
3.2.5 Filtrage des accès système . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Analyse de la conformité 17
4.1 Conformité du produit à la cible de sécurité . . . . . . . . . . . . . . . . . . . . . 17
4.1.1 Cloisonnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.2 Isolation des ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.3 Restriction des privilèges . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.4 Limitation des accès aux ressources . . . . . . . . . . . . . . . . . . . . . . 19

5 Analyse des vulnérabilités 21

5.1 Liste des vulnérabilités connues ou potentielles . . . . . . . . . . . . . . . . . . . 21
5.1.1 Vulnérabilités connues pour le produit ou pour des versions précédentes . 21
5.1.2 Vulnérabilités connues pour les composants du produit . . . . . . . . . . . 23

6 Analyse de la facilité d’emploi 27

6.1 Recommandations pour une utilisation sûre du produit . . . . . . . . . . . . . . . 27
6.2 Recommandations du Center for Internet Security . . . . . . . . . . . . . . 29

7 Synthèse 32
7.1 Installation du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.2 Résistance des fonctions et mécanismes . . . . . . . . . . . . . . . . . . . . . . . . 32
7.3 Conformité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.4 Vulnérabilités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.5 Facilité d’emploi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Annexe A Fichiers de configuration Vagrant et Ansible 34

Annexe B Debian Stretch 40

B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
B.2 Image Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Annexe C MediaWiki 41
C.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
C.2 Image Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
C.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Annexe D Preuve de concept CVE-2019-5736 45
 Logiciel libre de gestionnaire de conteneurs

1 Introduction
1.1 Objet du document
Le présent document constitue l’évaluation BSS Express du produit Docker Community
Edition (CE) dans sa version 18.09.3, build 774a1f4 développé par Docker, Inc..

1.2 Identification du produit

Éditeur Docker, Inc.
Lien vers l’éditeur [Link]
Nom commercial du produit Docker Community Edition (CE)
Numéro de la version du produit 18.09.3, build 774a1f4
Catégorie de produit Logiciel libre de gestionnaire de conteneurs

1.3 Documents applicables

Référence Document
[R1] Recommandations pour la sécurisation des sites web, n˚ DAT-NT-
009/ANSSI/SDE/NP du 13 août 2013, disponible sur http ://[Link]
[R2] Recommandations relatives à l’administration sécurisée des systèmes d’informa-
tion, n˚ ANSSI-PA-022 du 24 avril 2018, disponible sur http ://[Link]
[R3] Recommandations de configuration d’un système GNU/Linux, n˚ DAT-NT-
28/ANSSI/SDE/NP du 12 janvier 2016, disponible sur http ://[Link]
[R4] Documentation de sécurité Docker en ligne, disponible sur https ://-
[Link]/engine/security
[R5] Cible de sécurité, version n˚ 1.0 du 1er février 2019
[R6] Cible de sécurité, version n˚ 1.1 du 10 avril 2019

16 avril 2019 Version 1.0 3

 Logiciel libre de gestionnaire de conteneurs

2 Installation du produit
2.1 Options d’installation retenues pour le produit
L’environnement prévu pour l’évaluation représenté à la figure 1 est une architecture trois tiers
ou à trois couches. La mise en œuvre de cet environnement est réalisée grâce à l’environnement
virtualisé VirtualBox 1 et déployé grâce à l’outil Vagrant 2 . L’installation, la configuration et
le déploiement des différents logiciels (Docker, images Docker, conteneurs applicatifs, . . .) sont
réalisés grâce à l’outil Ansible 3 .

Figure 1 – Environnement virtualisé prévu pour l’évaluation

L’installation de Vagrant est réalisée en exécutant la commande suivante après avoir téléchargé
1. [Link]
2. [Link]
3. [Link]

16 avril 2019 Version 1.0 4

 Logiciel libre de gestionnaire de conteneurs

le paquet Debian vagrant_2.2.3_x86_64.deb disponible sur la page de téléchargement du site

Vagrant 4 :

$ sudo dpkg − i vagrant_2 . 2 . 3 _x86_64 . deb

Pour permettre à Vagrant de redémarrer la machine virtuelle, le module d’extension vagrant-reload

doit être installé en exécutant la commande suivante :

$ v a g r a n t p l u g i n i n s t a l l vagrant −r e l o a d

L’installation de Ansible est réalisée en exécutant les commandes suivantes :

$ sudo apt−g e t update

$ sudo apt−g e t i n s t a l l s o f t w a r e −p r o p e r t i e s −common
$ sudo apt−add−r e p o s i t o r y −−y e s −−update ppa : a n s i b l e / a n s i b l e
$ sudo apt−g e t i n s t a l l a n s i b l e

L’environnement prévu pour l’évaluation est créé lors de l’exécution de la commande suivante :

$ v a g r a n t up

Cette création se déroule en plusieurs étapes décrites dans le fichier de configuration Vagrant
appelé Vagranfile et dans les fichiers de configuration Ansible appelés playbook disponibles en
annexe A :
1. Installation de la machine virtuelle officielle Ubuntu 64bits Bionic depuis la bibliothèque
de Vagrant
2. Redirection du port 80 de la machine virtuelle sur le port 8080 de l’interface réseau locale
ou localhost de l’hôte de la machine virtuelle permettant à l’opérateur de se connecter en
HTTP à partir d’un client WEB ([Link] à la couche de traitement métier
des données, le serveur HTTP (App A)
3. Installation et configuration de Docker dans la machine virtuelle grâce au fichier de con-
figuration Ansible, [Link]. La configuration de Docker nécessite un redémarrage de la
machine virtuelle
4. Déploiement des conteneurs applicatifs, serveur HTTP (App A) et serveur de bases de
données (App B), et un conteneur Debian (App C) grâce aux fichiers de configuration
Ansible respectifs, [Link], [Link] et [Link].
L’évaluateur se connecte en SSH à la machine virtuelle pour accéder au Client Docker CLI
grâce à la commande suivante :
4. [Link]

16 avril 2019 Version 1.0 5

 Logiciel libre de gestionnaire de conteneurs

$ vagrant ssh
Welcome t o Ubuntu 1 8 . 0 4 . 2 LTS (GNU/ Linux 4.15.0 −46 − g e n e r i c x86_64 )
[...]
vagrant@ubuntu−b i o n i c : ~ $

L’évaluateur est connecté sur la machine virtuelle avec le compte vagrant qui appartient
au groupe docker ce qui permet d’utiliser le client Docker CLI (utilisateur client Docker CLI
défini dans le document [R5] au chapitre 1.3). Ce compte a été ajouté au fichier /etc/sudoers
pour permettre d’exécuter les tâches d’administration (utilisateur administrateur défini dans le
document [R5] au chapitre 1.3).

L’applicatif installée sur le serveur HTTP (App A) est le logiciel open-source MediaWiki 5 qui
utilise un serveur de bases de données, ici MySQL 6 (App B), pour stocker les pages dynamiques.
La configuration de MediaWiki, hors scope de l’évaluation, est présentée en annexe C.

2.2 Description de l’installation

À l’issue de l’installation de Docker CE sur la machine virtuelle Ubuntu décrite à la section 2.1
et conforme à la procédure d’installation décrite sur le site officiel de Docker 7 , les deux nouveaux
services ou processus (figure 2) suivants s’exécutent :
– le processus containerd 8 (/usr/bin/containerd) qui s’exécute en root (UID 0). Ce processus
a été introduit dans Docker v1.11 [3]. C’est une application de conteneur standard, disponible
sous la forme de daemon pour Linux et Windows, qui gère le cycle de vie complet du conteneur
de son système hôte :
– transfert et stockage d’images ;
– exécution et configuration « bas niveau »(capabilities, Namespace, etc.) du conteneur
en appelant runC ;
– supervision des conteneurs ;
– stockage bas niveau ;
– gestion des primitives réseau pour les interfaces ;
– etc. . .
– le processus dockerd 9 (/usr/bin/dockerd) qui s’exécute en root (UID 0) qui est le daemon
Docker. Il écoute les requêtes REST du client Docker CLI transmises via une socket UNIX
ou l’interface réseau physique de l’hôte (REST API). Il utilise containerd.

$ ps a x j f
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
[...]
1 613 613 613 ? −1 Ssl 0 0:00 / usr / bin / containerd
1 618 618 618 ? −1 Ssl 0 0 : 0 1 / u s r / b i n / d o c k e r d −H f d : / /

Figure 2 – Liste des processus Docker

Pour le déploiement d’un conteneur, par exemple le conteneur de l’image officielle de Debian
Stretch (App C) présentée en annexe B, le processus containerd-shim (/usr/bin/containerd-
shim) (figure 3) est exécuté à partir du processus containerd. Ce processus permet de « découpler »
le gestionnaire de conteneurs containerd du conteneur [1].
5. [Link]
6. [Link]
7. [Link]
8. [Link]
9. [Link]

16 avril 2019 Version 1.0 6

 Logiciel libre de gestionnaire de conteneurs

$ d o c k e r run −−name d e b i a n −−i n t e r a c t i v e −−d e t a c h −−t t y d e b i a n : s t r e t c h −s l i m / b i n /

bash
[...]
$ ps a x j f
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
[...]
1 613 613 613 ? −1 Ssl 0 0:00 / usr / bin / containerd
613 1395 1395 613 ? −1 Sl 0 0 : 0 0 \_ c o n t a i n e r d −shim [ . . . ]
1395 1411 1411 1411 p t s /0 1411 Ss+ 0 0:00 \_ / b i n / bash
1 618 618 618 ? −1 Ssl 0 0 : 0 1 / u s r / b i n / d o c k e r d −H f d : / /

Figure 3 – Liste des processus Docker et d’un conteneur Docker

16 avril 2019 Version 1.0 7

 Logiciel libre de gestionnaire de conteneurs

3 Analyse de résistance des fonctions et mécanismes

3.1 Fonctions métier
3.1.1 Fonctions d’administration
La TOE est administrée à partir du service ou daemon Docker comme un autre service du
système d’exploitation. Ce service, dockerd 10 , est configurable en ligne de commande ou à l’aide
d’un fichier de configuration en JSON, par défaut sous Linux /etc/docker/[Link].

3.1.2 Fonctions de configuration

La configuration de la TOE, la construction, le fonctionnement et la distribution des conteneurs
Docker sont effectués à partir de l’interface REST (ou REST API) du daemon Docker. Un client en
ligne de commande, docker 11 ou Client Docker CLI, permet de communiquer avec cette interface.
Ce client est accessible à l’utilisateur root et, si le groupe existe, aux membres du groupe docker.

3.1.3 Journalisation locale d’évènements

La TOE génère, par défaut, des journaux d’évènements notamment de sécurité et d’adminis-
tration issus des processus dockerd et containerd dans l’outil de gestion des logs de l’hôte, par
exemple, syslog ou journald.

3.1.4 Journalisation des conteneurs

La TOE permet d’accéder et éventuellement de rediriger les flux standard STDERR et STDOUT des
conteneurs 12 vers l’outil de gestion des logs de l’hôte, par exemple, syslog, en exécutant le daemon
Docker avec l’option --log-driver 13 (en ligne de commande ou dans le fichier de configuration).
Cependant, la journalisation des évènements issus des applications « conteneurisées » dépend
fortement de l’application.

3.2 Fonctions de sécurité

3.2.1 Cloisonnement
La TOE permet de définir le système de fichier et les fichiers indispensables (figure 6) suivants
du conteneur :
– un système de fichiers racine (/ ) ou root filesystem construit à partir d’une série de
calques ou couches (layers 14 ) dont chaque couche représente une instruction dans le
Dockerfile de l’image. Chaque couche est :
– un système de fichiers de type union filesystem supporté par Docker 15 (aufs,
btrfs, zfs, etc.), par exemple, overlay2 utilisé par défaut et recommandé sur Debian
Stretch ou Ubuntu,
– en lecture seule (figure 4), sauf la dernière couche (Thin R/W layer),
– et stockée séparément dans la zone de stockage local de Docker, qui est, par défaut,
/var/lib/docker/ sur Linux,
10. [Link]
11. [Link]
12. [Link]
13. [Link]
14. [Link]
15. [Link]

16 avril 2019 Version 1.0 8

 Logiciel libre de gestionnaire de conteneurs

Figure 4 – Conteneur et couches

– un système de fichiers des périphériques (/dev) de type tmpfs dans lequel Docker crée un
nombre restreint de périphériques matériels ou pseudo-périphériques (ou devices) (figure 5).

$ d o c k e r run −−name d e b i a n −−i n t e r a c t i v e −−t t y d e b i a n : s t r e t c h −s l i m / b i n / bash

[...]
root@5b666287be44 : /# t r e e / dev
/ dev
|−− c o n s o l e
|−− c o r e −> / p r o c / k c o r e
|−− f d −> / p r o c / s e l f / f d
|−− f u l l
|−− mqueue
|−− n u l l
|−− ptmx −> p t s /ptmx
|−− p t s
| |−− 0
| ‘−− ptmx
|−− random
|−− shm
|−− s t d e r r −> / p r o c / s e l f / f d /2
|−− s t d i n −> / p r o c / s e l f / f d /0
|−− s t d o u t −> / p r o c / s e l f / f d /1
|−− t t y
|−− urandom
‘−− z e r o

Figure 5 – Périphériques et pseudo-périphériques (ou Devices) par défaut

L’option --device 16 permet d’ajouter un périphérique de l’hôte au conteneur, par défaut,

en lecture et écriture et de créer une FIFO, un fichier spécial en mode caractère, ou un fichier
spécial en mode bloc, avec ce périphérique. Les options complémentaires rwm permettent
de limiter l’accès à ce périphérique ;
– un fichier /etc/[Link] créé par Docker et contenant la configuration DNS (configuration
de l’hôte par défaut) du conteneur ;
– un fichier /etc/hostname créé par Docker et contenant le nom du conteneur,
– un fichier /etc/hosts créé par Docker et contenant la définition des adresses loopback et
l’adresse IP attribuée au conteneur ;
16. [Link]

16 avril 2019 Version 1.0 9

 Logiciel libre de gestionnaire de conteneurs

– un système de fichiers processus (/proc) de type proc ;

– un système de fichiers virtuel (/sys) type sysfs.

$ d o c k e r run −−name d e b i a n −−i n t e r a c t i v e −−t t y d e b i a n : s t r e t c h −s l i m / b i n / bash

[...]
root@5b666287be44 : /# mount
o v e r l a y on / t y p e o v e r l a y ( rw , r e l a t i m e , l o w e r d i r = [ . . . ]
p r o c on / p r o c t y p e p r o c ( rw , n o s u i d , nodev , noexec , r e l a t i m e )
tmpfs on / dev t y p e tmpfs ( rw , n o s u i d , s i z e =65536k , mode=755 , u i d =165536 , g i d =165536)
[...]
s y s f s on / s y s t y p e s y s f s ( ro , n o s u i d , nodev , noexec , r e l a t i m e )
[...]
/ dev / mapper / ubuntu1804−−vg−r o o t on / e t c / r e s o l v . c o n f t y p e e x t 4 ( rw , r e l a t i m e , e r r o r s=
remount−ro , data=o r d e r e d )
/ dev / mapper / ubuntu1804−−vg−r o o t on / e t c / hostname t y p e e x t 4 ( rw , r e l a t i m e , e r r o r s=
remount−ro , data=o r d e r e d )
/ dev / mapper / ubuntu1804−−vg−r o o t on / e t c / h o s t s t y p e e x t 4 ( rw , r e l a t i m e , e r r o r s=
remount−ro , data=o r d e r e d )
[...]

Figure 6 – Système de fichiers d’un conteneur

L’environnement par défaut créé par Docker contient les variables d’environnement représentées
à la figure 7.

root@5b666287be44 : /# env
HOSTNAME=5b666287be44
PWD=/
HOME=/ r o o t
TERM=xterm
SHLVL=1
PATH=/u s r / l o c a l / s b i n : / u s r / l o c a l / b i n : / u s r / s b i n : / u s r / b i n : / s b i n : / b i n
_=/u s r / b i n / env

Figure 7 – Variables d’environnement par défaut d’un conteneur

La TOE crée, par défaut, un réseau de type « pont réseau » ou bridge, docker0, pour séparer
le réseau de l’hôte du réseau des conteneurs. Le cloisonnement de ce réseau par rapport au réseau
de l’hôte lorsque des conteneurs doivent communiquer par l’interface de l’hôte est réalisé à partir
d’un ensemble de règles iptables (figure 8).

16 avril 2019 Version 1.0 10

 Logiciel libre de gestionnaire de conteneurs

$ d o c k e r run −−name d e b i a n −−p u b l i s h 8 0 : 8 0 8 0 −−i n t e r a c t i v e −−d e t a c h −−t t y d e b i a n :

s t r e t c h −s l i m / b i n / bash
[...]
$ ip a
[...]
3 : d o c k e r 0 : <BROADCAST, MULTICAST, UP,LOWER_UP> mtu 1500 q d i s c noqueue s t a t e UP
group d e f a u l t
l i n k / e t h e r 0 2 : 4 2 : 1 d : 0 7 : 1 6 : 2 e brd f f : f f : f f : f f : f f : f f
i n e t 1 7 2 . 1 7 . 0 . 1 / 1 6 brd 1 7 2 . 1 7 . 2 5 5 . 2 5 5 s c o p e g l o b a l d o c k e r 0
valid_lft forever preferred_lft forever
i n e t 6 f e 8 0 : : 4 2 : 1 d f f : f e 0 7 : 1 6 2 e /64 s c o p e l i n k
valid_lft forever preferred_lft forever
[...]
$ sudo i p t a b l e s −− l i s t −−numeric
Chain INPUT ( p o l i c y ACCEPT)
target p r o t opt s o u r c e destination

Chain FORWARD ( p o l i c y DROP)

target prot opt source destination
DOCKER−USER all −− [Link]/0 [Link]/0
DOCKER−ISOLATION−STAGE−1 a l l −− [Link]/0 [Link]/0
ACCEPT all −− [Link]/0 0 . 0 . 0 . 0 / 0 c t s t a t e RELATED, ESTABLISHED
DOCKER all −− [Link]/0 [Link]/0
ACCEPT all −− [Link]/0 [Link]/0
ACCEPT all −− [Link]/0 [Link]/0

Chain OUTPUT ( p o l i c y ACCEPT)

target p r o t opt s o u r c e destination

Chain DOCKER ( 1 r e f e r e n c e s )
target p r o t opt s o u r c e destination
ACCEPT t c p −− 0 . 0 . 0 . 0 / 0 1 7 2 . 1 7 . 0 . 2 t c p dpt : 8 0 8 0

Chain DOCKER−ISOLATION−STAGE−1 ( 1 references )

target p r o t opt source destination
DOCKER−ISOLATION−STAGE−2 a l l −− [Link]/0 [Link]/0
RETURN a l l −− [Link]/0 [Link]/0

Chain DOCKER−ISOLATION−STAGE−2 ( 1 references )

target p r o t opt source destination
DROP a l l −− [Link]/0 [Link]/0
RETURN a l l −− [Link]/0 [Link]/0

Chain DOCKER−USER ( 1 r e f e r e n c e s )
target p r o t opt s o u r c e destination
RETURN a l l −− 0 . 0 . 0 . 0 / 0 [Link]/0

Figure 8 – Règles iptables définies par Docker pour exposer le port 8080 du conteneur

Lorsqu’un conteneur est créé, la TOE le connecte, par défaut, à ce réseau (figure 9), et définit
les règles adéquates iptables pour autoriser les communications initiées par le conteneur vers
l’interface de l’hôte. Si le conteneur expose des ports, la TOE définit des règles particulières
iptables pour rediriger les communications des ports concernés de l’interface réseau de l’hôte
vers les ports définis de l’interface réseau du conteneur. Cependant, dans cette configuration, les
ports exposés d’un conteneur sont aussi accessibles à l’ensemble des conteneurs.

16 avril 2019 Version 1.0 11

 Logiciel libre de gestionnaire de conteneurs

$ d o c k e r run −−name d e b i a n 1 −−i n t e r a c t i v e −−d e t a c h −−t t y d e b i a n : s t r e t c h −s l i m / b i n /

bash
[...]
$ d o c k e r run −−name d e b i a n 2 −−i n t e r a c t i v e −−d e t a c h −−t t y d e b i a n : s t r e t c h −s l i m / b i n /
bash
[...]
$ ip a
[...]
3 : d o c k e r 0 : <BROADCAST, MULTICAST, UP,LOWER_UP> mtu 1500 q d i s c noqueue s t a t e UP
group d e f a u l t
l i n k / e t h e r 0 2 : 4 2 : 4 c : 8 d : 7 6 : 1 8 brd f f : f f : f f : f f : f f : f f
i n e t 1 7 2 . 1 7 . 0 . 1 / 1 6 brd 1 7 2 . 1 7 . 2 5 5 . 2 5 5 s c o p e g l o b a l d o c k e r 0
valid_lft forever preferred_lft forever
inet6 fe80 : : 4 2 : 4 c f f : fe8d :7618/64 scope l i n k
valid_lft forever preferred_lft forever
5 : v e t h 9 1 c 7 5 6 c @ i f 4 : <BROADCAST, MULTICAST, UP,LOWER_UP> mtu 1500 q d i s c noqueue
master d o c k e r 0 s t a t e UP group d e f a u l t
l i n k / e t h e r 2 e : 8 c : b3 : 5 c : 6 0 : 7 0 brd f f : f f : f f : f f : f f : f f l i n k −n e t n s i d 0
i n e t 6 fe80 : : 2 c8c : b 3 f f : f e 5 c :6070/64 scope l i n k
valid_lft forever preferred_lft forever
7 : v e t h 7 9 d 2 4 3 f @ i f 6 : <BROADCAST, MULTICAST, UP,LOWER_UP> mtu 1500 q d i s c noqueue
master d o c k e r 0 s t a t e UP group d e f a u l t
l i n k / e t h e r 3 a : 8 3 : e7 : 5 a : 0 2 : d2 brd f f : f f : f f : f f : f f : f f l i n k −n e t n s i d 1
i n e t 6 f e 8 0 : : 3 8 8 3 : e 7 f f : f e 5 a : 2 d2 /64 s c o p e l i n k
valid_lft forever preferred_lft forever
[...]
$ sudo b r c t l show
b r i d g e name b r i d g e i d STP e n a b l e d interfaces
docker0 8 0 0 0 . 0 2 4 2 4 c8d7618 no veth79d243f
veth91c756c

Figure 9 – Réseau bridge, docker0 par défaut de Docker

La TOE permet de ne pas connecter les connecteurs au réseau bridge, docker0, lors de leur
création en exécutant le daemon Docker avec l’option --bridge=none 17 (en ligne de commande ou
dans le fichier de configuration).
La TOE permet aussi de créer de nouveaux réseaux dont des réseaux de type bridge à
partir de la commande suivante : docker network create [OPTIONS] NETWORK 18 , et ainsi de
connecter un ou plusieurs conteneurs à ce réseau (option --network 19 ).

3.2.2 Isolation des ressources

La TOE exploite la fonctionnalité Kernel Namespaces offerte par le noyau Linux pour isoler
les conteneurs.
Lorsqu’un conteneur est créé, la TOE lui associe, par défaut (figure 10), l’ensemble des
Namespaces suivants qui fournit une couche d’isolation :
– Namespace MNT pour les points de montage du système de fichiers : le conteneur accède
uniquement à ses propres points de montage et ne voit pas ceux de l’hôte ;
– Namespace PID pour les processus : le conteneur accède uniquement à ses propres
processus, et n’a donc pas connaissance des processus s’exécutant sur l’hôte ou dans d’autres
conteneurs. La numérotation de processus (PID) est réinitialisé et le processus principal du
conteneur possède le PID 1 ;
– Namespace NET pour les interfaces réseau : le conteneur accède uniquement à ses propres
interfaces réseau et ne voit pas ceux de l’hôte ou des autres conteneurs ;
– Namespace IPC pour la communication inter-processus de type SysV : le conteneur
bénéficie de canaux IPC dédiés (objets IPC System V, files de messages POSIX) et ne peut
pas accéder aux autres canaux définis sur l’hôte ;
17. [Link]
18. [Link]
19. [Link]

16 avril 2019 Version 1.0 12

 Logiciel libre de gestionnaire de conteneurs

– Namespace UTS pour le hostname et le nom de domaine NIS : le conteneur possède son
propre hostname et son propre nom de domaine NIS distincts de ceux de l’hôte ou des
autres conteneurs.

$ d o c k e r run −−name d e b i a n −−i n t e r a c t i v e −−d e t a c h −−t t y d e b i a n : s t r e t c h −s l i m / b i n /

bash
[...]
$ sudo l s n s −l r u
NS TYPE NPROCS PID USER COMMAND
[...]
4026532173 mnt 1 2256 root / b i n / bash
4026532174 u t s 1 2256 root / b i n / bash
4026532175 ipc 1 2256 root / b i n / bash
4026532176 p i d 1 2256 root / b i n / bash
4026532178 n e t 1 2256 root / b i n / bash

Figure 10 – Isolation, par défaut, des ressources par Namespaces après la création d’un conteneur

Pour que la TOE associe, avec quelques limitations 20 , un Namespace USER ID (figure 11),
lors de la création d’un conteneur, pour isoler le ou les utilisateurs ou UID/GID d’un conteneur
des utilisateurs de l’hôte et des autres conteneurs, le daemon Docker doit être exécuté avec
l’option --userns-remap 21 (en ligne de commande ou dans le fichier de configuration). L’utilisateur
root (UID=0) du conteneur est associé par conséquent à un utilisateur non privilégié sur l’hôte
(UID=165536 sur la figure 11).

$ d o c k e r run −−name d e b i a n −−i n t e r a c t i v e −−d e t a c h −−t t y d e b i a n : s t r e t c h −s l i m / b i n /

bash
[...]
$ sudo l s n s −l r u
NS TYPE NPROCS PID USER COMMAND
[...]
4026532173 user 1 2595 165536 / b i n / bash
4026532174 mnt 1 2595 165536 / b i n / bash
4026532175 u t s 1 2595 165536 / b i n / bash
4026532176 ipc 1 2595 165536 / b i n / bash
4026532177 p i d 1 2595 165536 / b i n / bash
4026532179 n e t 1 2595 165536 / b i n / bash

Figure 11 – Isolation des ressources par Namespaces après la création d’un conteneur

La TOE ne peut pas associée à un conteneur un Namespace CGROUP distinct de l’hôte

pour les identités de CGroup et les membres de ces CGroups. Cependant, le dossier /sys/fs/cgroup
du conteneur (figure 12) est remplacé par un système de fichiers tmpfs dans lequel sont montés de
nouveaux dossiers spécifiques pour chacun des types de CGroup. Ce mécanisme permet à chaque
conteneur de ne pas visualiser les CGroups de l’hôte et des autres conteneurs.

$ d o c k e r run −−name d e b i a n −−i n t e r a c t i v e −−t t y d e b i a n : s t r e t c h −s l i m / b i n / bash

[...]
root@5b666287be44 : /# mount
[...]
tmpfs on / s y s / f s / cgr oup t y p e tmpfs ( rw , n o s u i d , nodev , noexec , r e l a t i m e , mode=755 , u i d
=165536 , g i d =165536)

Figure 12 – Isolation des identités de CGroups et les membres de ces CGroups d’un conteneur
20. [Link]
21. [Link]

16 avril 2019 Version 1.0 13

 Logiciel libre de gestionnaire de conteneurs

3.2.3 Restriction des privilèges

La TOE permet de démarrer les conteneurs sans les privilèges du super-administrateur
(conteneur non privilégié) ou avec un ensemble restreint de capabilities 22 . Par défaut, les
conteneurs sont démarrés avec les capabilities 23 suivantes (figure 13) :
– CAP_CHOWN pour effectuer toute modification des UID et GID de fichiers ;
– CAP_DAC_OVERRIDE pour contourner les permissions de lecture, écriture et exécu-
tion ;
– CAP_FOWNER pour :
– contourner les vérifications pour les opérations qui demandent que le FS-UID du
processus corresponde à l’UID du fichier, à l’exclusion des opérations couvertes par
CAP_DAC_OVERRIDE et CAP_DAC_READ_SEARCH ;
– positionner les attributs de fichier étendus pour n’importe quel fichier ;
– positionner les listes de contrôle d’accès ACL pour n’importe quel fichier ;
– ignorer le bit sticky des répertoires pour les suppressions de fichier ;
– spécifier O_NOATIME dans open et fcntl pour n’importe quel fichier.
– CAP_FSETID pour ne pas effacer les bits de permission Set-UID et Set-GID quand un
fichier est modifié et positionner le bit Set-GID sur un fichier dont le GID ne correspond à
aucun GID du processus appelant ;
– CAP_MKNOD pour créer des fichiers spéciaux avec mknod ;
– CAP_NET_RAW pour :
– utiliser des sockets RAW et PACKET ;
– attacher à n’importe quelle adresse pour un service mandataire transparent.
– CAP_SETGID pour effectuer toute manipulation des GID du processus et de la liste de
groupes supplémentaires, utiliser de faux GID sur les socket UNIX ;
– CAP_SETUID pour effectuer toute manipulation des UID de processus, transmettre un
faux UID sur une socket dans le domaine UNIX ;
– CAP_SETFCAP pour définir des capabilities de fichier ;
– CAP_SETPCAP pour ajouter toute capability de l’ensemble de limitation de capabilities
cités du thread appelant à son ensemble hérité ; supprimer les capabilities cités de l’ensem-
ble de limitation de capabilities cités ; modifier l’attribut securebits ;
– CAP_NET_BIND_SERVICE pour attacher une socket sur un port privilégié (numéro
de port inférieur à 1024) ;
– CAP_SYS_CHROOT pour utiliser chroot ;
– CAP_KILL pour contourner les vérifications pour l’émission de signaux ;
– CAP_AUDIT_WRITE pour activer et désactiver l’audit du noyau ; changer les règles
de filtrage d’audit ; accéder à l’état de l’audit, et aux règles de filtrage ;

$ d o c k e r run −−name d e b i a n −−i n t e r a c t i v e −−d e t a c h −−t t y d e b i a n : s t r e t c h −s l i m / b i n /

bash
[...]
$ ps a x j f
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
1 557 557 557 ? −1 Ssl 0 0:00 / usr / bin / containerd
557 1874 1874 557 ? −1 Sl 0 0 : 0 0 \_ c o n t a i n e r d −shim [ . . . ]
1874 1899 1899 1899 p t s /0 1899 Ss+ 165536 0:00 \_ / b i n / bash

$ g e t p c a p s 1899
C a p a b i l i t i e s f o r ‘ 1 8 9 9 ’ : = cap_chown , cap_dac_override , cap_fowner , c a p _ f s e t i d ,
c a p _ k i l l , c a p _ s e t g i d , c a p _ s e t u i d , cap_setpcap , cap_net_bind_service , cap_net_raw ,
cap_sys_chroot , cap_mknod , cap_audit_write , c a p _ s e t f c a p+e i p

Figure 13 – Capabilities, par défaut, d’un conteneur

22. [Link]
23. [Link]

16 avril 2019 Version 1.0 14

 Logiciel libre de gestionnaire de conteneurs

La TOE peut démarrer un conteneur avec des capabilities supplémentaires ou en ôtant

des capabilities présentes par défaut grâce aux options --cap-add ou --cap-drop (la valeur ALL
est possible) (figure 14).

$ d o c k e r run −−name d e b i a n −−i n t e r a c t i v e −−d e t a c h −−cap−drop=ALL −−t t y d e b i a n :

s t r e t c h −s l i m / b i n / bash
[...]
$ ps a x j f
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
1 557 557 557 ? −1 Ssl 0 0:01 / usr / bin / containerd
557 2031 2031 557 ? −1 Sl 0 0 : 0 0 \_ c o n t a i n e r d −shim [ . . . ]
2031 2055 2055 2055 p t s /0 2055 Ss+ 165536 0 : 0 0 \_ / b i n / bash

$ g e t p c a p s 2055
Capabilities for ‘2055 ’: =

Figure 14 – Suppression des capabilities, par défaut, d’un conteneur

3.2.4 Limitation des accès aux ressources

La TOE exploite les control groups (ou CGroups) qui permettent de limiter, mesurer et
prioritiser l’accès aux ressources système (CPU, mémoire, I/O disque. . .) pour chaque conteneur.
Par défaut, un conteneur n’a pas de contraintes de ressources et peut utiliser toutes les
ressources disponibles sur l’hôte. La TOE peut démarrer un conteneur en limitant :
– l’accès d’un conteneur à la mémoire de l’hôte 24 ;
– l’accès d’un conteneur aux cycles CPU de l’hôte 25 .
La TOE permet d’afficher en temps réel l’utilisation de la mémoire et la charge du CPU de
chaque conteneur grâce la commande docker stats <nom du conteneur>.
Au même titre que la mémoire et les cycles CPU, l’espace disque des conteneurs est partagé
avec l’espace disque de l’hôte. Par défaut, tous les fichiers créés à l’intérieur d’un conteneur sont
stockés sur le calque ou couche (layer), Thin R/W layer (figure 4), en lecture et en écriture,
mais ils ne sont pas conservés lorsque le conteneur n’existe plus. La TOE permet de démarrer un
conteneur en limitant :
– l’accès au système de fichiers racine ou root filesystem du conteneur en lecture
seule (option --read-only 26 ) ;
– l’espace disque de la couche Thin R/W layer de chaque conteneur, sous certaines
conditions (option --storage-opt 27 ).

La TOE permet de stocker et conserver des fichiers sur l’hôte même après la suppression du
conteneur grâce à l’utilisation de bind mount 28 pour monter un fichier ou un répertoire de
l’hôte dans le conteneur. Ce mécanisme permet aussi de partager un fichier ou répertoire entre
l’hôte et un ou plusieurs conteneurs ou pour partager un fichier ou un répertoire entre plusieurs
conteneurs.
La TOE permet aussi de créer un volume Docker 29 à partir de la commande suivante : docker
volume create [OPTIONS] [VOLUME] 30 , et ainsi de monter ce volume dans un ou plusieurs
conteneurs (option --volume ou --mount).
24. [Link]
25. [Link]
26. [Link]
27. [Link]
28. [Link]
29. [Link]
30. [Link]

16 avril 2019 Version 1.0 15

 Logiciel libre de gestionnaire de conteneurs

3.2.5 Filtrage des accès système

La TOE permet de configurer un profil Seccomp pour chaque conteneur permettant de filtrer
les appels systèmes effectués par le conteneur. Dans le temps imparti, l’évaluation de cette fonction
n’a pas pu être réalisée.

16 avril 2019 Version 1.0 16

 Logiciel libre de gestionnaire de conteneurs

4 Analyse de la conformité
4.1 Conformité du produit à la cible de sécurité
4.1.1 Cloisonnement
La fonction de sécurité « cloisonnement » couvre les menaces définies dans la cible de sécurité
(document [R5] au chapitre 1.3) et représentées dans le tableau 1. En effet, elle permet :
– de cloisonner le système de fichier du conteneur du système de fichier de l’hôte et aussi des
systèmes de fichier des autres conteneurs pour éviter :
– toute corruption de Docker et de sa configuration,
– toute compromission de secrets stockés sur l’hôte ou dans un autre conteneur.
– d’isoler et de limiter l’exposition des périphériques matériels ou pseudo-périphériques de
l’hôte et des autres conteneurs dont les flux standard, /dev/stdout et /dev/stderr, utilisés
pour la gestion des journaux d’évènements ;
– de cloisonner les processus de l’hôte pour éviter toute compromission des processus de l’hôte
dont les processus de Docker par un processus du conteneur,
– d’isoler l’interface réseau du conteneur de l’hôte et aussi des autres conteneurs pour toute
altération ou compromission de flux réseau.
Corruption de la configura-

Contournement de la poli-

Corruption des journaux

Corruption des journaux

Vol de secrets de connexion

d’évènements des conteneurs

Vol de secrets de connexion

Compromission des flux

Corruption du logiciel

d’évènements locaux
Altération des flux

Déni de service
des conteneurs

tique de droits
tion

M10
M1

M2

M3

M4

M5

M6

M7

M8

M9

FS1 Cloisonnement 4 4 4 4 4 4 4 4
/ 3 3 3 3
/dev 3 3
/etc/[Link]
/etc/hostname
/proc 3
/sys
réseau bridge 3 3

Tableau 1 – Couverture des menaces par la fonction de sécurité « cloisonnement » (FS1)

4.1.2 Isolation des ressources

La fonction de sécurité « isolation des ressources » couvre les menaces définies dans la cible de
sécurité (document [R5] au chapitre 1.3) et représentées dans le tableau 2. En effet, elle permet
d’isoler les ressources (points de montage, processus, interfaces réseau, utilisateurs, groupes
d’utilisateurs, etc.) de l’hôte vis-à-vis du conteneur et aussi des conteneurs entre eux.
Elle permet aussi de couvrir la menace de déni de service (M8), en limitant l’accès aux
ressources grâce aux CGroups et en isolant les processus de l’hôte et des autres conteneurs.

16 avril 2019 Version 1.0 17

 Logiciel libre de gestionnaire de conteneurs

Par contre, elle ne permet pas de couvrir les menaces de corruption des journaux d’évènements
locaux (M9) et de corruption des journaux d’évènements des conteneurs (M10).

Corruption de la configura-

Contournement de la poli-

Corruption des journaux

Corruption des journaux

Vol de secrets de connexion

d’évènements des conteneurs

Vol de secrets de connexion

Compromission des flux

Corruption du logiciel

d’évènements locaux
Altération des flux

Déni de service
des conteneurs

tique de droits
tion

M10
M1

M2

M3

M4

M5

M6

M7

M8

M9
Isolation des
FS2 4 4 4 4 4 4 4 4 6 6
ressources
Namespace MNT 3 3 3 3
Namespace PID 3
Namespace NET 3 3 3
Namespace IPC
Namespace UTS
Namespace USER ID 3 3 3 3 3 3 3 3
/sys/fs/cgroup tmpfs 3

Tableau 2 – Couverture des menaces par la fonction de sécurité « isolation des ressources » (FS2)

4.1.3 Restriction des privilèges

Par défaut, la fonction de sécurité « restriction des privilèges » ne couvre pas toutes les
menaces définies dans la cible de sécurité (document [R5] au chapitre 1.3) et représentées dans le
tableau 3. En effet, la présence des capabilities :
– CAP_NET_RAW et CAP_NET_BIND_SERVICE en l’absence d’isolation du Namespace
NET de l’hôte (par exemple, avec l’option --network="host" 31 ) ou d’isolation réseau
des conteneurs entre eux, ne permet pas de couvrir la menace d’altération (M5) et de
compromission (M6) des flux,
– CAP_KILL en l’absence d’isolation du Namespace PID de l’hôte ou des autres conteneurs
ne permet pas de couvrir la menace de déni de service (M8).
Elle ne couvre pas aussi les menaces de corruption des journaux d’évènements locaux (M9) et de
corruption des journaux d’évènements des conteneurs (M10).
31. [Link]

16 avril 2019 Version 1.0 18

 Logiciel libre de gestionnaire de conteneurs

Corruption de la configura-

Contournement de la poli-

Corruption des journaux

Corruption des journaux

Vol de secrets de connexion

d’évènements des conteneurs

Vol de secrets de connexion

Compromission des flux

Corruption du logiciel

d’évènements locaux
Altération des flux

Déni de service
des conteneurs

tique de droits
tion

M10
M1

M2

M3

M4

M5

M6

M7

M8

M9
Restriction des privilèges
FS3 4 4 4 4 6 6 4 6 6 6
(Capabilities par défaut)
CAP_CHOWN
CAP_DAC_OVERRIDE
CAP_FOWNER
CAP_FSETID
CAP_MKNOD
CAP_NET_RAW 3 3
CAP_SETGID
CAP_SETUID
CAP_SETFCAP
CAP_SETPCAP
CAP_NET_BIND_SERVICE 3 3
CAP_SYS_CHROOT
CAP_KILL 3
CAP_AUDIT_WRITE

Tableau 3 – Couverture des menaces par la fonction de sécurité « restriction des privilèges » (FS3)

4.1.4 Limitation des accès aux ressources

La fonction de sécurité « limitation des accès aux ressources » couvre les menaces définies
dans la cible de sécurité (document [R5] au chapitre 1.3) et représentées dans le tableau 4. En
effet, elle permet de limiter l’accès aux ressources partagées de l’hôte par le conteneur afin de
répartir leur usage entre l’hôte et les autres conteneurs.

16 avril 2019 Version 1.0 19

 Logiciel libre de gestionnaire de conteneurs

Corruption de la configura-

Contournement de la poli-

Corruption des journaux

Corruption des journaux

Vol de secrets de connexion

d’évènements des conteneurs

Vol de secrets de connexion

Compromission des flux

Corruption du logiciel

d’évènements locaux
Altération des flux

Déni de service
des conteneurs

tique de droits
tion

M10
M1

M2

M3

M4

M5

M6

M7

M8

M9
Limitation des accès aux
FS4 4
ressources
accès d’un conteneur à la mé-
3
moire
accès d’un conteneur aux cycles
3
CPU
accès au système de fichiers
3
racine du conteneur
Tableau 4 – Couverture des menaces par la fonction de sécurité « limitation des accès aux
ressources » (FS4)

16 avril 2019 Version 1.0 20

 Logiciel libre de gestionnaire de conteneurs

5 Analyse des vulnérabilités

5.1 Liste des vulnérabilités connues ou potentielles
5.1.1 Vulnérabilités connues pour le produit ou pour des versions précédentes
Docker, Inc. fournit une liste de vulnérabilités 32 33 représentée au tableau 5. Dans le cadre
de cette évaluation, aucune de ces vulnérabilités n’aurait permis à notre modèle d’attaquant de
compromettre la TOE.

CVE ID Description
CVE-2016-8867 Incorrect application of ambient capabilities
CVE-2014-8178 Attacker controlled layer IDs lead to local graph content poisoning
CVE-2014-8179 Manifest validation and parsing logic errors allow pull-by-digest validation
bypass
CVE-2015-3629 Symlink traversal on container respawn allows local privilege escalation
CVE-2015-3627 Insecure opening of file-descriptor 1 leading to privilege escalation
CVE-2015-3630 Read/write proc paths allow host modification & information disclosure
CVE-2015-3631 Volume mounts allow LSM profile escalation

Tableau 5 – Docker CVE Database

Une recherche par produit sur le site CVE Details 34 fournit une liste 35 de vulnérabilités plus
importantes représentées dans le tableau 6. L’affichage en distributions, par année et par type de
vulnérabilités, est représentée sur la figure 15.
Dans le cadre de cette évaluation, aucune de ces vulnérabilités n’aurait permis à notre modèle
d’attaquant de compromettre la TOE.

CVE ID Description
CVE-2018-15514 HandleRequestAsync in Docker for Windows before 18.06.0-ce-rc3-win68
(edge) and before 18.06.0-ce-win72 (stable) deserialized requests over the
named pipe without verifying the validity of the deserialized .NET objects.
This would allow a malicious user in the "docker-users" group (who may
not otherwise have administrator access) to escalate to administrator
privileges.
CVE-2017-14992 Lack of content verification in Docker-CE (Also known as Moby) versions
1.12.6-0, 1.10.3, 17.03.0, 17.03.1, 17.03.2, 17.06.0, 17.06.1, 17.06.2, 17.09.0,
and earlier allows a remote attacker to cause a Denial of Service via a
crafted image layer payload, aka gzip bombing.
CVE-2017-7297 Rancher Labs rancher server 1.2.0+ is vulnerable to authenticated
users disabling access control via an API call. This is fixed in versions
rancher/server :v1.2.4, rancher/server :v1.3.5, rancher/server :v1.4.3, and
rancher/server :v1.5.3.
CVE-2016-9962 RunC allowed additional container processes via ’runc exec’ to be ptraced
by the pid 1 of the container. This allows the main processes of the
container, if running as root, to gain access to file-descriptors of these new
processes during the initialization and can lead to container escapes or
modification of runC state before the process is fully placed inside the
container.
CVE-2016-8867 Docker Engine 1.12.2 enabled ambient capabilities with misconfigured ca-
pability policies. This allowed malicious images to bypass user permissions
to access files within the container filesystem or mounted volumes.

32. [Link]
33. consulté le 26 mars 2019
34. [Link]
35. consultée le 26 mars 2019

16 avril 2019 Version 1.0 21

 Logiciel libre de gestionnaire de conteneurs

CVE ID Description
CVE-2016-6595 ** DISPUTED ** The SwarmKit toolkit 1.12.0 for Docker allows remote
authenticated users to cause a denial of service (prevention of cluster joins)
via a long sequence of join and quit actions. NOTE : the vendor disputes
this issue, stating that this sequence is not "removing the state that is
left by old nodes. At some point the manager obviously stops being able
to accept new nodes, since it runs out of memory. Given that both for
Docker swarm and for Docker Swarmkit nodes are *required* to provide a
secret token (it’s actually the only mode of operation), this means that
no adversary can simply join nodes and exhaust manager resources. We
can’t do anything about a manager running out of memory and not being
able to add new legitimate nodes to the system. This is merely a resource
provisioning issue, and definitely not a CVE worthy vulnerability."
CVE-2016-3697 libcontainer/user/[Link] in runC before 0.1.0, as used in Docker before
1.11.2, improperly treats a numeric UID as a potential username, which
allows local users to gain privileges via a numeric username in the password
file in a container.
CVE-2015-3631 Docker Engine before 1.6.1 allows local users to set arbitrary Linux Security
Modules (LSM) and docker_t policies via an image that allows volumes
to override files in /proc.
CVE-2015-3630 Docker Engine before 1.6.1 uses weak permissions for (1) /proc/asound,
(2) /proc/timer_stats, (3) /proc/latency_stats, and (4) /proc/fs, which
allows local users to modify the host, obtain sensitive information, and
perform protocol downgrade attacks via a crafted image.
CVE-2015-3627 Libcontainer and Docker Engine before 1.6.1 opens the file-descriptor
passed to the pid-1 process before performing the chroot, which allows
local users to gain privileges via a symlink attack in an image.
CVE-2014-9358 Docker before 1.3.3 does not properly validate image IDs, which allows
remote attackers to conduct path traversal attacks and spoof repositories
via a crafted image in a (1) "docker load" operation or (2) "registry
communications."
CVE-2014-9357 Docker 1.3.2 allows remote attackers to execute arbitrary code with root
privileges via a crafted (1) image or (2) build in a Dockerfile in an LZMA
(.xz) archive, related to the chroot for archive extraction.
CVE-2014-6408 Docker 1.3.0 through 1.3.1 allows remote attackers to modify the default
run profile of image containers and possibly bypass the container by
applying unspecified security options to an image.
CVE-2014-6407 Docker before 1.3.2 allows remote attackers to write to arbitrary files and
execute arbitrary code via a (1) symlink or (2) hard link attack in an
image archive in a (a) pull or (b) load operation.
CVE-2014-5282 Docker before 1.3 does not properly validate image IDs, which allows
remote attackers to redirect to another image through the loading of
untrusted images via ’docker load’.
CVE-2014-5277 Docker before 1.3.1 and docker-py before 0.5.3 fall back to HTTP when the
HTTPS connection to the registry fails, which allows man-in-the-middle
attackers to conduct downgrade attacks and obtain authentication and
image data by leveraging a network position between the client and the
registry to block HTTPS traffic.
CVE-2014-3499 Docker 1.0.0 uses world-readable and world-writable permissions on the
management socket, which allows local users to gain privileges via unspec-
ified vectors.
CVE-2014-0047 Docker before 1.5 allows local users to have unspecified impact via vectors
involving unsafe /tmp usage.

Tableau 6 – CVE Details Database

16 avril 2019 Version 1.0 22

 Logiciel libre de gestionnaire de conteneurs

Figure 15 – CVE Details Trends

5.1.2 Vulnérabilités connues pour les composants du produit

L’application Docker (Docker Community Edition (CE) version 18.09.3, build 774a1f4)
dépend des composants suivants 36 (figure 16 :
– L’interface en ligne de commande iptables permettant de configurer Netfilter ;
– La bibliothèque C GNU standard libc6 ;
– La bibliothèque containerd pour gérer le cycle de vie complet du conteneur ;
– L’interface de haut niveau pour le filtre seccomp de Linux libseccomp2 pour installer les
filtres seccomp passé à l’appel système prctl() du noyau Linux ;
– La bibliothèque libsystemd0 qui fournit des interfaces vers divers composants de systemd
qui est le gestionnaire du système pour les architectures GNU/Linux.
36. [Link]

16 avril 2019 Version 1.0 23

 Logiciel libre de gestionnaire de conteneurs

$ apt-cache depends docker-ce\=5:18.09.3~3-0~ubuntu-bionic

docker-ce
Dépend: docker-ce-cli
Dépend: [Link]
Dépend: iptables
iptables:i386
Dépend: libseccomp2
Dépend: libc6
Dépend: libsystemd0
Est en conflit avec: docker
Est en conflit avec: <docker-engine>
Est en conflit avec: <docker-engine-cs>
Est en conflit avec: [Link]
Est en conflit avec: <lxc-docker>
Est en conflit avec: <lxc-docker-virtual-package>
Recommande: aufs-tools
Recommande: ca-certificates
Recommande: cgroupfs-mount
Recommande: cgroup-lite
Recommande: git
git:i386
Recommande: pigz
Recommande: xz-utils
xz-utils:i386
Recommande: libltdl7
Recommande: apparmor
Remplace: <docker-engine>
Figure 16 – Composants de Docker

Parmi ces composants, la bibliothèque C GNU standard (ou glibc) concentre un grand nombre
de vulnérabilités comme le montrent les distributions 37 , par année et par type de vulnérabilités,
représentées sur la figure 17.
37. consultées le 26 mars 2019

16 avril 2019 Version 1.0 24

 Logiciel libre de gestionnaire de conteneurs

Figure 17 – CVE Details Trends

D’autre part, une récente vulnérabilité CVE-2019-5736 38 affectant le binaire runC de la

bibliothèque [Link] (version 1.0-rc6) utilisé par les versions Docker antérieures à la
version 18.09.2 39 a été publiée et a fait l’objet de publication des plusieurs preuves de concept
(PoC ). Dans le cadre de cette évaluation, elle permet à un attaquant qui a la maîtrise d’un
conteneur, et sous certaines conditions 40 , d’outrepasser les droits de son conteneur et d’exécuter
du code sur l’hôte. Cette exécution de code a été reproduite à la figure 18 dans l’environnement
prévu pour l’évaluation à partir de la preuve de concept présentée en annexe D.
38. [Link]
39. [Link]
40. [Link]

16 avril 2019 Version 1.0 25

 Logiciel libre de gestionnaire de conteneurs

$ v a g r a n t up
[...]
TASK [ Execute / u s r / b i n / docker −runc ] ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗
changed : [ d e f a u l t ]

TASK [ debug ] ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗
ok : [ d e f a u l t ] => {
" ou tp ut . s t d o u t _ l i n e s " : [
"" ,
" ∗∗THE ALL NEW AND IMPROVED RUNC∗∗ " ,
"" ,
" \ t [ + ] Your backdoor h e r e −>"
]
}

Figure 18 – Exploitation de la CVE-2019-5736 pour exécuter du code sur l’hôte

Les mitigations 41 suivantes sont possibles pour cette vulnérabilité :

– activation de SELinux (option --selinux) qui empêche les processus à l’intérieur du conteneur
d’écraser le binaire docker-runc de l’hôte ;
– configuration du système de fichiers en lecture seule sur l’hôte, au moins pour stocker le
binaire docker-runc ;
– configuration un conteneur avec un Namespace USER ID distinct de l’hôte qui donne un
accès en lecture seulement au binaire docker-runc de l’hôte.

41. [Link]

16 avril 2019 Version 1.0 26

 Logiciel libre de gestionnaire de conteneurs

6 Analyse de la facilité d’emploi

6.1 Recommandations pour une utilisation sûre du produit
R1 Le daemon Docker doit être configuré pour collecter les journaux d’évènements issus
des applications « conteneurisées » et les rediriger vers un serveur centralisé (Docker
supporte plusieurs driver de logs 42 et permet d’en créer de nouveaux 43 ) ou vers
l’outil de gestion des logs de l’hôte avec l’option --log-driver=<logging driver> (en
ligne de commande ou dans le fichier de configuration).

Certaines applications « conteneurisées » produisent des journaux d’évènements sous la forme

de fichiers dédiés, par défaut, dans le répertoire ou un sous-répertoire de /var/log. Comme pour
certaines images officielles 44 , la redirection des journaux des applications « conteneurisées » vers
les flux standard, /dev/stdout et /dev/stderr, peut être mise en œuvre et ainsi permettre de
configurer la journalisation des conteneurs à l’aide de Docker.

R1- Une gestion centralisée des journaux d’évènements issus des applications « con-
teneurisées », distincte de Docker, peut être mise en œuvre.

R2 Le daemon Docker doit être configuré pour démarrer un conteneur sans le connecter,
par défaut, au réseau bridge, docker0, avec l’option --bridge=none (en ligne de
commande ou dans le fichier de configuration). Si le conteneur doit être connecté à
l’interface réseau de l’hôte ou à un ou plusieurs autres connecteurs, un réseau doit
être créé à partir de la commande docker network create [OPTIONS] NETWORK et
les interfaces réseau du ou des conteneurs devront alors être connectées à ce réseau
avec l’option --network.

R3 Le daemon Docker doit être configuré pour démarrer un conteneur avec un Namespace
USER ID distinct de l’hôte et des autres conteneurs avec l’option --userns-remap (en
ligne de commande ou dans le fichier de configuration).

R3- Un conteneur peut être démarré en partageant le Namespace USER ID de l’hôte avec
l’option --userns=host quand le daemon Docker est configuré pour démarrer les
conteneurs avec un Namespace USER ID distinct de l’hôte.

R4 Chaque conteneur doit être démarré sans aucune capability avec l’option --cap-
drop=ALL.

En effet, les capabilities par défaut de Docker ne sont pas nécessaires [4] en production :
– CAP_CHOWN : cette capability n’est pas nécessaire en production ;
– CAP_DAC_OVERRIDE : cette capability n’est pas nécessaire en production ;
– CAP_FOWNER : cette capability n’est pas nécessaire en production, le cas échéant
l’action ou les actions nécessitant cette capability doivent être réalisées lors de la con-
struction du conteneur dans le Dockerfile ;
– CAP_FSETID : cette capability n’est pas nécessaire en production ;
– CAP_MKNOD : cette capability n’est pas nécessaire en production, le cas échéant la
création du périphérique doit être réalisée lors du démarrage du conteneur avec l’option
--device ;
– CAP_NET_RAW : cette capability n’est pas nécessaire en production ;
42. [Link]
43. [Link]
44. [Link]
stretch/apache/Dockerfile

16 avril 2019 Version 1.0 27

 Logiciel libre de gestionnaire de conteneurs

– CAP_SETGID : cette capability n’est pas nécessaire en production, sauf si l’application

« conteneurisée » modifie les UID/GIDs, généralement en démarrant avec l’utilisateur
root (UID 0) pour exécuter des actions privilégiées avant changer d’utilisateur ou groupe
d’utilisateur. Certaines applications permettent de modifier ce comportement à partir de la
configuration ;
– CAP_SETUID : cette capability n’est pas nécessaire en production, sauf si l’application
« conteneurisée » modifie les UID/GIDs, généralement en démarrant avec l’utilisateur
root (UID 0) pour exécuter des actions privilégiées avant changer d’utilisateur ou groupe
d’utilisateur. Certaines applications permettent de modifier ce comportement à partir de la
configuration ;
– CAP_SETFCAP : cette capability n’est pas nécessaire en production ;
– CAP_SETPCAP : cette capability n’est pas nécessaire en production, sauf si l’ap-
plication « conteneurisée » modifie les capability, généralement en démarrant avec les
capability nécessaires pour exécuter des actions privilégiées avant de les supprimer. Cer-
taines applications permettent de modifier ce comportement à partir de la configuration ;
– CAP_NET_BIND_SERVICE : cette capability n’est pas nécessaire en production,
le cas échéant une redirection des ports de l’hôte vers des ports, non privilégiés, du conteneur
doit réalisée avec l’option --p 45 ;
– CAP_SYS_CHROOT : cette capability n’est pas nécessaire en production sauf si
l’application « conteneurisée » utilise la commande chroot et qu’il n’est pas possible de
modifier ce comportement à partir de la configuration ;
– CAP_KILL cette capability n’est pas nécessaire en production, sauf si l’application
« conteneurisée » envoie des signaux kill à des processus d’un autre utilisateur et qu’il
n’est pas possible de modifier ce comportement à partir de la configuration ;
– CAP_AUDIT_WRITE cette capability ne devrait pas être nécessaire en production,
en effet, le sous-système audit du noyau ne gère pas actuellement les espaces de nommage
ou Namespaces.

R4- Un conteneur peut être démarré avec un nombre très limité de capabilities avec
les options --cap-drop=ALL et --cap-add={"capability A"}.

R5 Chaque conteneur doit être démarré avec une limite maximale d’utilisation de la
mémoire de l’hôte avec l’option --memory et une limite maximale d’utilisation de la
mémoire SWAP de l’hôte avec l’option --memory-swap 46 .

R6 Chaque conteneur doit être démarré avec une limite maximale d’utilisation du CPU
de l’hôte avec l’option --cpus ou avec les options --cpu-period et --cpu-quota.

Les applications « conteneurisées » produisent au plus trois types de données :

1. les données non persistantes ou temporaires qui sont supprimées à chaque arrêt du conteneur ;
2. les données persistantes qui sont conservées après chaque arrêt ou destruction du conteneur ;
3. les données partagées avec l’hôte ou avec un ou plusieurs autres conteneurs.

R7 Chaque conteneur doit être démarré avec leur système de fichiers racine ou root
filesystem en lecture seule avec l’option --read-only. Après avoir identifié les réper-
toires contenant des données non persistantes ou temporaires, ces répertoires doivent
être montés à l’aide d’un montage bind tmpfs 47 ou avec l’option --mount type=tmpfs.

R7- Un conteneur peut être démarré avec une limite maximale d’utilisation de l’espace
disque de l’hôte pour leur système de fichiers racine ou root filesystem en lecture-
écriture avec l’option --storage-opt.
45. [Link]
46. [Link]
47. [Link] avec l’option --tmpfs

16 avril 2019 Version 1.0 28

 Logiciel libre de gestionnaire de conteneurs

R7-- Un conteneur peut être démarré avec son système de fichiers racine ou root
filesystem en lecture-écriture dès lors que la zone de stockage local de Docker,
qui, par défaut /var/lib/docker/ sur Linux, est une partition dédiée et distincte des
partitions de l’hôte. Dans ce cas, la menace d’un déni de service d’un conteneur vis à
vis d’un autre conteneur ou sur le service Docker est à considérer.

R8 Les répertoires contenant des données persistantes ou partagées avec l’hôte ou avec
d’autres conteneurs doivent être montés à l’aide de :
– un montage bind mount 48 avec une limitation de l’espace disque utilisé grâce
à l’option --mount type=bind, o=size,
– un montage bind volume 49 d’une partition dédiée et distincte des partitions
utilisées par l’hôte ou d’un volume Docker avec une limitation définie de l’espace
disque grâce à l’option --mount type=volume.

6.2 Recommandations du Center for Internet Security

Le Center for Internet Security 50 (CIS) a publié un document de référence [2] de recom-
mandations conçues pour aider les administrateurs système, les professionnels de la sécurité et
de l’audit, . . . à établir une configuration de base sécurisée pour Docker CE. La correspondance
entre les fonctions métier et de sécurité définies à la section 3 et ces recommandations est définie
dans le tableau 7.
48. [Link]
49. [Link]
50. [Link]

16 avril 2019 Version 1.0 29

 Logiciel libre de gestionnaire de conteneurs

Fonctions du produit CIS Docker Community Edition Benchmarki v1.1.0

FM4 Journalisation des conteneurs 2.12 Ensure centralized and remote
logging is configured
5.5 Ensure sensitive host system
directories are not mounted on
FS1 Cloisonnement
containers
5.17 Ensure host devices are not directly
exposed to containers
5.19 Ensure mount propagation mode is not
set to shared
5.29 Ensure Docker’s default bridge
docker0 is not used
2.8 Enable user namespace support
5.9 Ensure sensitive host system
FS2 Isolation des ressources directories are not mounted on
containers
5.15 Ensure the host’s process namespace
is not shared
5.16 Ensure the host’s IPC namespace is
not shared
5.20 Ensure the host’s UTS namespace is
not shared
5.3 Ensure Linux Kernel Capabilities are
FS3 Restriction des privilèges
restricted within containers
5.4 Ensure privileged containers are not
used
5.10 Ensure memory usage for container is
FS4 Limitation des accès aux ressources limited
5.12 Ensure the container’s root
filesystem is mounted as read only
5.24 Ensure cgroup usage is confirmed
FS5 Filtrage des accès système 5.21 Ensure the default seccomp profile
is not Disabled

Tableau 7 – Correspondance des fonctions de sécurité et des recommandations CIS Docker

Community Edition Benchmark v1.1.0

Docker, Inc. fournit un conteneur Docker 51 qui réalise une analyse de sécurité de l’environ-
nement Docker d’un hôte au regard des ces recommandations.

L’analyse effectuée avec le conteneur Docker sur l’architecture trois tiers définie à la section 2
donne le résultat de la figure 19.
51. [Link]

16 avril 2019 Version 1.0 30

 Logiciel libre de gestionnaire de conteneurs

$ d o c k e r run − i t −−n e t h o s t −−p i d h o s t −−u s e r n s h o s t −−cap−add a u d i t _ c o n t r o l \

> −e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
> −v / v a r / l i b : / v a r / l i b \
> −v / v a r / run / d o c k e r . s o c k : / v a r / run / d o c k e r . s o c k \
> −v / u s r / l i b / systemd : / u s r / l i b / systemd \
> −v / e t c : / e t c −−l a b e l d o c k e r _ b e n c h _ s e c u r i t y \
> d o c k e r / docker −bench−s e c u r i t y −c check_2_12 , check_5_5 , check_5_17 , check_5_19 ,
check_5_29 , check_2_8 , check_5_9 , check_5_15 , check_5_16 , check_5_20 , check_5_3 ,
check_5_4 , check_5_10 , check_5_12 , check_5_24 , check_5_21
[...]
# −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
# Docker Bench f o r S e c u r i t y v1 . 3 . 4
#
# Docker , I n c . ( c ) 2015−
#
# Checks f o r d o z e n s o f common b e s t −p r a c t i c e s around d e p l o y i n g Docker c o n t a i n e r s i n
production .
# I n s p i r e d by t h e CIS Docker Community E d i t i o n Benchmark v1 . 1 . 0 .
# −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
[...]
[ PASS ] 2 . 1 2 − Ensure c e n t r a l i z e d and remote l o g g i n g i s c o n f i g u r e d
[ PASS ] 5 . 5 − Ensure s e n s i t i v e h o s t system d i r e c t o r i e s a r e not mounted on
containers
[ PASS ] 5 . 1 7 − Ensure h o s t d e v i c e s a r e not d i r e c t l y e x p o s e d t o c o n t a i n e r s
[ PASS ] 5 . 1 9 − Ensure mount p r o p a g a t i o n mode i s not s e t t o s h a r e d
[ PASS ] 5 . 2 9 − Ensure Docker ’ s d e f a u l t b r i d g e d o c k e r 0 i s not used
syslog
[ PASS ] 2 . 8 − Enable u s e r namespace s u p p o r t
[ PASS ] 5 . 9 − Ensure t h e hos t ’ s network namespace i s not s h a r e d
[ PASS ] 5 . 1 5 − Ensure t h e hos t ’ s p r o c e s s namespace i s not s h a r e d
[ PASS ] 5 . 1 6 − Ensure t h e hos t ’ s IPC namespace i s not s h a r e d
[ PASS ] 5 . 2 0 − Ensure t h e hos t ’ s UTS namespace i s not s h a r e d
[ PASS ] 5 . 3 − Ensure Linux K e r n e l C a p a b i l i t i e s a r e r e s t r i c t e d w i t h i n c o n t a i n e r s
[ PASS ] 5 . 4 − Ensure p r i v i l e g e d c o n t a i n e r s a r e not used
[ PASS ] 5 . 1 0 − Ensure memory u s a g e f o r c o n t a i n e r i s l i m i t e d
[ PASS ] 5 . 1 2 − Ensure t h e c o n t a i n e r ’ s r o o t f i l e s y s t e m i s mounted a s r e a d o n l y
[ PASS ] 5 . 2 4 − Ensure c gro up u s a g e i s c o n f i r m e d
[ PASS ] 5 . 2 1 − Ensure t h e d e f a u l t seccomp p r o f i l e i s not D i s a b l e d

[ INFO ] Checks : 16
[ INFO ] S c o r e : 15

Figure 19 – Analyse de sécurité de l’architecture trois tiers

16 avril 2019 Version 1.0 31

 Logiciel libre de gestionnaire de conteneurs

7 Synthèse
7.1 Installation du produit
Docker Community Edition (CE)est constitué des services ou processus suivants :
– dockerd qui est exécuté avec l’utilisateur root (UID=0 ). Ce processus est fortement exposé,
car il permet d’administrer et configurer la TOE à partir de l’interface REST (REST API),
– containerd et containerd-shim qui permet à containerd d’interagir avec le conteneur qui
sont, tous les deux, exécutés avec l’utilisateur root (UID=0 ). Ces processus sont directement
ou indirectement exposés au conteneur. La CVE-2019-5736 a montré qu’une vulnérabilité
dans l’un de ces processus permet à un attaquant ayant compromis un conteneur de
compromettre l’hôte.
L’analyse de sécurité de ces processus est hors scope de l’évaluation mais un durcissement du
système et des services 52 Docker doit être réalisé pour réduire la surface d’attaque
de Docker et les risques de compromission de l’hôte.

7.2 Résistance des fonctions et mécanismes

La TOE permet de mettre en œuvre l’ensemble des fonctions métier et de sécurité définies du
document [R5] au chapitre 1.3. Dans certains cas, cette mise en œuvre nécessite une connaissance
avancée de l’application « conteneurisée » et de son environnement d’utilisation. Par conséquent,
pour garantir une approbation d’un plus grand nombre, certaines fonctions ne sont pas activées
par défaut ou le sont partiellement. Leur activation reste cependant possible :
– soit en modifiant la configuration du daemon Docker pour que la ou les fonctions soient
effectives par défaut lors de la création du conteneur avec le client Docker CLI ;
– soit en utilisant les commandes supplémentaires disponibles au client Docker CLI (docker
network, par exemple) ;
– soit en utilisant les options disponibles lors de la création du conteneur avec le client
Docker CLI.
Dans le temps imparti, l’évaluation de la fonction de sécurité « filtrage des accès système » n’a
pas pu être réalisée. Or, lors de la création d’un conteneur, la TOE associe un profil Seccomp par
défaut fourni par Docker qui désactive environ 44 appels système sur plus de 300 53 . Une analyse
de sécurité du filtrage des appels système par Seccomp doit être réalisée ainsi que le
profil Seccomp par défaut de Docker.
De plus, la TOE permet de définir une politique de contrôle d’accès obligatoire (Mandatory
Access Controls ou MAC ) aux éléments du système issus de l’image grâce notamment à un profil
AppArmor 54 .Une analyse de sécurité d’une politique de contrôle d’accès obligatoire
(MAC ) doit être réalisée.
Il est important de noter que ces fonctions de sécurité reposent essentiellement sur les
mécanismes de sécurité du noyau Linux empêchant, de ce fait, la mise en œuvre d’une défenseur
en profondeur. En effet, toute vulnérabilité d’un de ces mécanismes peut réduire la sécurité offerte
par les autres mécanismes de manière significative. Par exemple, une vulnérabilité sur un MNT
Namespace de type la CVE-2015-1328 55 permettrait à un attaquant de compromettre la TOE et
ce malgré la mise en œuvre de la restriction des privilèges.
D’autre part, certaines fonctions de sécurité dépendent de plusieurs mécanismes de sécurité,
et inversement, certains mécanismes de sécurité contribuent à plusieurs fonctions de sécurité. Par
conséquent, il est difficile de garantir l’efficacité d’une fonction de sécurité dans le cas où un ou
plusieurs mécanismes de sécurité ne sont pas activés ou le sont partiellement. Par exemple, il est
difficile d’évaluer la sécurité d’un conteneur démarré avec une ou plusieurs capabilities ou un
conteneur qui partage un des Namespaces avec l’hôte ou avec un ou plusieurs conteneurs.
52. par exemple, à l’aide d’un profil AppArmor [Link]
apparmor
53. [Link]
54. [Link]
55. [Link]

16 avril 2019 Version 1.0 32

 Logiciel libre de gestionnaire de conteneurs

7.3 Conformité
La section 4 montre que la couverture des menaces par les fonctions de sécurité définies
du document [R5] au chapitre 1.3 n’est pas conforme. Une nouvelle version, document [R6] au
chapitre 1.3, a été rédigée pour corriger les non-conformités.

7.4 Vulnérabilités
Docker Community Edition (CE) présente peu de vulnérabilités connues, et ces vulnérabilités
concernent, pour la plupart, la création du conteneur à partir d’une image malveillante. Par
contre, du fait que la sécurité de Docker Community Edition (CE) repose principalement sur les
mécanismes de sécurité du noyau et sur des composants externes dont la bibliothèque C GNU
standard (ou glibc) qui présente un grand nombre de vulnérabilités, une vulnérabilité d’un de
ces mécanismes ou d’un des ces composants peut être exploitée sur Docker Community Edition
(CE) , par exemple, la récente CVE-2019-5736 de la bibliothèque containerd.

7.5 Facilité d’emploi

La mise en œuvre de la sécurité de Docker Community Edition (CE) nécessite une connaissance
avancée de l’application « conteneurisée » (utilisation de fichiers temporaires, par exemple) et
de son environnement d’utilisation (charge CPU utile ou taille de l’espace disque nécessaire
par exemple) pour pouvoir paramétrer et ajuster la configuration de sécurité de Docker. La
modification du comportement par défaut de l’application est parfois nécessaire, mais seulement
si l’application le permet, par exemple, grâce à un fichier de configuration (modification du port
d’écoute lorsque le port est privilégié, par exemple). Ces modifications sont rendues possibles
grâce notamment au fichier de configuration des conteneurs, appelé Dockerfile 56 , dont le format
permet de réaliser des actions (commande shell, par exemple) avant la création du conteneur
(pour modifier la configuration, par exemple).
Plusieurs documents et outils sont disponibles pour « sécuriser » Docker Community Edition
(CE) dont le document de référence [2] publié par le Center for Internet Security 57 (CIS)
pour lequel il existe une image Docker 58 qui s’exécute dans l’environnement Docker et qui fournit
un rapport complet d’analyse.

56. [Link]
57. [Link]
58. [Link]

16 avril 2019 Version 1.0 33

 Logiciel libre de gestionnaire de conteneurs

Annexe A Fichiers de configuration Vagrant et Ansible

# −∗− mode : r u b y −∗−
# # v i : s e t f t =r u b y :

APPA_NAME = "AppA"
APPB_NAME = "AppB"
APPC_NAME = "AppC"
GUEST_PORT = " 80 "
HOST_PORT = " 8080 "
MYSQL_DATABASE = " my_wiki "
MYSQL_USER = " wikiuser "
MYSQL_PASSWORD = " example "
NETWORK1_NAME = " docker1 "
NETWORK2_NAME = " docker2 "

Vagrant . c o n f i g u r e ( " 2 " ) do | c o n f i g |

u n l e s s Vagrant . h a s _ p l u g i n ? ( " vagrant −r e l o a d " )
r a i s e ’ The Vagrant Reload P r o v i s i o n e r p l u g i n must be i n s t a l l p r i o r t o b u i l d i n g
t h i s VM ( v a g r a n t p l u g i n i n s t a l l vagrant −r e l o a d ) ’
end

c o n f i g . vm . box = " ubuntu / b i o n i c 6 4 "

c o n f i g . vm . network " f o r w a r d e d _ p o r t " , g u e s t : GUEST_PORT, h o s t : HOST_PORT

# I n s t a l l p y th o n f o r a n s i b l e
c o n f i g . vm . p r o v i s i o n " s h e l l " , i n l i n e : <<−SHELL
t e s t −e / u s r / b i n / python | | ( apt−g e t −qqy update && apt−g e t i n s t a l l −qqy python
−minimal > / dev / n u l l 2>&1)
SHELL

# Run A n s i b l e from t h e Vagrant Host

# I n s t a l l and c o n f i g u r e Docker
c o n f i g . vm . p r o v i s i o n " a n s i b l e " do | a n s i b l e |
a n s i b l e . compatibility_mode = " 2 . 0 "
a n s i b l e . playbook = " d o c k e r . yml "
end

c o n f i g . vm . p r o v i s i o n : r e l o a d

# Run A n s i b l e from t h e Vagrant Host

# Launch c o n t a i n e r s
# MySQL c o n t a i n e r (AppB)
c o n f i g . vm . p r o v i s i o n " a n s i b l e " do | a n s i b l e |
a n s i b l e . compatibility_mode = " 2 . 0 "
a n s i b l e . playbook = "AppB . yml "
a n s i b l e . extra_vars = {
container_name : APPA_NAME,
mysql_database : MYSQL_DATABASE,
mysql_user : MYSQL_USER,
mysql_password : MYSQL_PASSWORD,
network2_name : NETWORK2_NAME,
}
end

# MediaWiki c o n t a i n e r (AppA)
c o n f i g . vm . p r o v i s i o n " a n s i b l e " do | a n s i b l e |
a n s i b l e . compatibility_mode = " 2 . 0 "
a n s i b l e . playbook = "AppA . yml "
a n s i b l e . extra_vars = {
container_name : APPB_NAME,
network1_name : NETWORK1_NAME,
network2_name : NETWORK2_NAME,
med iawiki _port : GUEST_PORT,
mysql_name : APPA_NAME,
}
end

# Debian c o n t a i n e r (AppC)
c o n f i g . vm . p r o v i s i o n " a n s i b l e " do | a n s i b l e |

16 avril 2019 Version 1.0 34

 Logiciel libre de gestionnaire de conteneurs

a n s i b l e . compatibility_mode = " 2 . 0 "

a n s i b l e . playbook = "AppC . yml "
a n s i b l e . extra_vars = {
container_name : APPC_NAME,
}
end
end

Fichier 1 – Vagrantfile de Vagrant

− hosts : a l l
become : y e s
tasks :
# I n s t a l l Docker CE u s i n g t h e r e p o s i t o r y
− name : Add Docker ’ s o f f i c i a l GPG key
apt_key :
u r l : h t t p s : / / download . d o c k e r . com/ l i n u x / ubuntu / gpg
state : present

− name : S e t up t h e s t a b l e r e p o s i t o r y
apt_repository :
r e p o : " deb [ a r c h=amd64 ] h t t p s : / / download . d o c k e r . com/ l i n u x / ubuntu b i o n i c
stable "
state : present
filename : docker

− name : I n s t a l l t h e l a t e s t v e r s i o n o f Docker CE and python−d o c k e r ( t o u s e d o c k e r

modules )
apt :
name : [ ’ docker −c e ’ , ’ python−d o c k e r ’ ]
update_cache : y e s
when : v e r s i o n i s u n d e f i n e d

− name : I n s t a l l p r e v i o u s v e r s i o n o f Docker CE and python−d o c k e r ( t o u s e d o c k e r

modules )
apt :
name : [ ’ docker −c e ={{ v e r s i o n }}∗ ’ , ’ python−d o c k e r ’ ]
update_cache : y e s
when : v e r s i o n i s d e f i n e d

− name : Add t h e u s e r ’ v a g r a n t ’ t o t h e group ’ d o c k e r ’

user :
name : v a g r a n t
groups : docker
append : y e s

− name : C o n f i g u r e t h e Docker daemon

blockinfile :
path : / e t c / d o c k e r /daemon . j s o n
c r e a t e : yes
marker : " {mark} "
marker_begin : " { "
block : ’ " b r i d g e " : " none " , " u s e r n s −remap " : " d e f a u l t " , " l o g −d r i v e r " : " s y s l o g
" ’
marker_end : " } "

− name : R e s t a r t s e r v i c e d o c k e r
service :
name : d o c k e r
state : restarted

− name : Add c gr oup swap l i m i t c a p a b i l i t i e s

replace :
path : / e t c / d e f a u l t / grub
r e g e x p : ’ ^GRUB_CMDLINE_LINUX="" ’
r e p l a c e : ’GRUB_CMDLINE_LINUX=" c g r o u p _ e n a b l e=memory swapaccount =1" ’

− name : Update GRUB

s h e l l : / u s r / s b i n / update−grub

Fichier 2 – [Link] de Ansible

16 avril 2019 Version 1.0 35

 Logiciel libre de gestionnaire de conteneurs

− hosts : a l l
become : y e s
vars :
apache2_uid : 10
apache2_gid : 10
apache_port : 8080
cpu_period : " 100000 "
cpu_quota : " 40000 "
memory : " 300M"
memory_swap : " 300M"
tasks :
− name : C r e a t e a network
docker_network :
name : " {{ network1_name }} "

# Run AppA ( MediaWiki 1 . 3 2 . 0 ) i n c o n t a i n e r

− s h e l l : g r e p dockremap / e t c / s u b u i d | s e d ’ s / ^ . ∗ : \ ( [ 0 − 9 ] [ 0 − 9 ] ∗ \ ) : . ∗ / \ 1 / ’
r e g i s t e r : dockremap

− name : Ensure ’ apache2 ’ group e x i s t s

group :
name : apache2
g i d : " {{ apache2_gid + dockremap . s t d o u t | i n t }} "
state : present

− name : Add t h e u s e r ’ apache2 ’ with a s p e c i f i c u i d and a primary group o f ’

apache2 ’
user :
name : apache2
u i d : " {{ apache2_uid + dockremap . s t d o u t | i n t }} "
group : apache2
create_home : no

− name : C r e a t e D o c k e r f i l e f o r AppA
blockinfile :
path : /home/ v a g r a n t / D o c k e r f i l e . AppA
c r e a t e : yes
owner : v a g r a n t
group : v a g r a n t
block : |
FROM m e d i a w i k i : 1 . 3 2 . 0

RUN s e d − i \
−e ’ s / ^ \ ( : $ {APACHE_PID_FILE:=\) . ∗ \ ( \ / apache2 . p i d \ ) /\1\/tmp\2/ ’ \
−e ’ s / ^ \ ( : $ {APACHE_RUN_DIR:=\) . ∗ / \ 1 \ / tmp}/ ’ \
−e ’ s / ^ \ ( : $ {APACHE_LOCK_DIR:=\) . ∗ / \ 1 \ / tmp}/ ’ \
−e ’ s / ^ \ ( : $ {APACHE_LOG_DIR:=\) . ∗ / \ 1 \ / tmp}/ ’ \
/ e t c / apache2 / e n v v a r s

RUN s e d − i \
−e ’ s / ^ \ ( L i s t e n \ ) . ∗ / \ 1 { { apache_port }}/ ’ \
/ e t c / apache2 / p o r t s . c o n f

RUN s e d − i \
−e ’ s /^\(< V i r t u a l H o s t ∗ : \ ) . ∗ \ ( > \ ) /\1{{ apache_port }}\2/ ’ \
/ e t c / apache2 / s i t e s −e n a b l e d /000− d e f a u l t . c o n f

EXPOSE {{ apache_port }}

# d o c k e r b u i l d −f /home/ v a g r a n t / D o c k e r f i l e . AppA −t appa /home/ v a g r a n t

− name : B u i l d AppA image from D o c k e r f i l e
docker_image :
name : appa
path : /home/ v a g r a n t
d o c k e r f i l e : /home/ v a g r a n t / D o c k e r f i l e . AppA

# d o c k e r run −−u s e r 1 0 : 1 0 −−name AppA −−n e t w o r k =" d o c k e r 1 " −−p u b l i s h 8 0 : 8 0 8 0 −−

cap−drop=ALL −−read−o n l y −−t m p f s /tmp \
# −−cpu−p e r i o d =100000 −−cpu−q u o t a =40000 \
# −−memory="300M" −−memory−swap ="300M" \
# −−d e t a c h appa

16 avril 2019 Version 1.0 36

 Logiciel libre de gestionnaire de conteneurs

# A f t e r i n i t i a l s e t u p , download L o c a l S e t t i n g s . php t o t h e d i r e c t o r y ’AppA ’

# and c r e a t e compressed a r c h i v e ( sudo t a r −c v z f AppB . t g z AppB) o f ’AppB ’ MySQL
Database
# d o c k e r run −−u s e r 1 0 : 1 0 −−name AppA −−n e t w o r k =" d o c k e r 1 " −−p u b l i s h 8 0 : 8 0 8 0 −−
cap−drop=ALL −−read−o n l y −−t m p f s /tmp \
# −−volume / v a g r a n t /AppA/ L o c a l S e t t i n g s . php : / v a r /www/ html / L o c a l S e t t i n g s . php \
# −−cpu−p e r i o d =100000 −−cpu−q u o t a =40000 \
# −−memory="300M" −−memory−swap ="300M" \
# −−d e t a c h appa
− name : Run AppA c o n t a i n e r
docker_container :
name : " {{ container_name }} "
image : appa
u s e r : " {{ apache2_uid } } : { { apache2_gid }} "
ports :
− " {{ m ediawi ki_po rt } } : { { apache_port }} "
cpu_period : " {{ cpu_period }} "
cpu_quota : " {{ cpu_quota }} "
memory : " {{ memory }} "
memory_swap : " {{ memory_swap }} "
networks :
− name : " {{ network1_name }} "
cap_drop :
− all
read_only : y e s
tmpfs :
− " /tmp "
# uncomment t h e f o l l o w i n g l i n e s and r e s t a r t t h e m e d i a w i k i s e r v i c e
# volumes :
# − "/ v a g r a n t /AppA/ L o c a l S e t t i n g s . php : / v a r /www/ html / L o c a l S e t t i n g s . php "

# d o c k e r n e t w o r k c o n n e c t d o c k e r 2 AppA
− name : Add/Append AppA c o n t a i n e r t o d o c k e r 2 network
docker_network :
name : " {{ network2_name }} "
connected :
− " {{ mysql_name }} "
appends : y e s

Fichier 3 – [Link] de Ansible

− hosts : a l l
become : y e s
vars :
cpu_period : " 100000 "
cpu_quota : " 40000 "
memory : " 1G"
memory_swap : " 1G"
m y s q l _ d a t a b a s e _ s i z e : " 500M"
mysql_uid : 20
mysql_gid : 20
mysql_random_root_password : " y e s "
tasks :
− name : C r e a t e a network
docker_network :
name : " {{ network2_name }} "

# Run AppB (MySQL) i n c o n t a i n e r

− s h e l l : g r e p dockremap / e t c / s u b u i d | s e d ’ s / ^ . ∗ : \ ( [ 0 − 9 ] [ 0 − 9 ] ∗ \ ) : . ∗ / \ 1 / ’
r e g i s t e r : dockremap

− name : Ensure ’ mysql ’ group e x i s t s

group :
name : mysql
g i d : " {{ mysql_gid + dockremap . s t d o u t | i n t }} "
state : present

− name : Add t h e u s e r ’ mysql ’ with a s p e c i f i c u i d and a primary group o f ’ mysql ’

user :
name : mysql
u i d : " {{ mysql_uid + dockremap . s t d o u t | i n t }} "

16 avril 2019 Version 1.0 37

 Logiciel libre de gestionnaire de conteneurs

group : mysql
create_home : no

− name : Check i f MySQL Database path e x i s t s

stat :
path : /home/ v a g r a n t /MySQL_DB
register : p

− name : C r e a t e t h e s h a r e d d i r e c t o r y f o r MySQL Database

file :
path : /home/ v a g r a n t /MySQL_DB
owner : mysql
group : mysql
state : directory
mode : 0755
when : p . s t a t . e x i s t s == f a l s e

− name : C r e a t e D o c k e r f i l e f o r AppB
blockinfile :
path : /home/ v a g r a n t / D o c k e r f i l e . AppB
owner : v a g r a n t
group : v a g r a n t
c r e a t e : yes
block : |
FROM mysql : 8 . 0 . 1 4

RUN s e d − i \
−e ’ s / ^ \ ( pid− f i l e .∗=\) . ∗ \ ( mysqld . p i d \ ) /\1 \/tmp\/\2/ ’ \
−e ’ s / ^ \ ( s o c k e t .∗=\) . ∗ \ ( mysqld . s o c k \ ) /\1 \/tmp\/\2/ ’ \
/ e t c / mysql /my . c n f

# d o c k e r b u i l d −f /home/ v a g r a n t / D o c k e r f i l e . AppB −t appb /home/ v a g r a n t

− name : B u i l d AppB image from D o c k e r f i l e
docker_image :
name : appb
path : /home/ v a g r a n t
d o c k e r f i l e : /home/ v a g r a n t / D o c k e r f i l e . AppB

# d o c k e r run −−u s e r 2 0 : 2 0 −−name AppB −−n e t w o r k =" d o c k e r 2 " −−cap−drop=ALL −−read−

o n l y −−t m p f s /tmp \
# −−env MYSQL_DATABASE=my_wiki −−env MYSQL_USER=w i k i u s e r −−env MYSQL_PASSWORD=
example −−env MYSQL_RANDOM_ROOT_PASSWORD=y e s \
# −−volume /home/ v a g r a n t /MySQL_DB: / v a r / l i b / mysql \
# −−cpu−p e r i o d =100000 −−cpu−q u o t a =40000 \
# −−memory="1G" −−memory−swap="1G" \
# −−d e t a c h appb −−d e f a u l t −a u t h e n t i c a t i o n −p l u g i n=mysql_native_password
− name : Run AppB c o n t a i n e r
docker_container :
name : " {{ container_name }} "
image : appb
u s e r : " {{ mysql_uid } } : { { mysql_gid }} "
env :
MYSQL_DATABASE: ’ {{ mysql_database }} ’
MYSQL_USER: ’ {{ mysql_user }} ’
MYSQL_PASSWORD: ’ {{ mysql_password }} ’
MYSQL_RANDOM_ROOT_PASSWORD: ’ {{ mysql_random_root_password }} ’
cpu_period : " {{ cpu_period }} "
cpu_quota : " {{ cpu_quota }} "
memory : " {{ memory }} "
memory_swap : " {{ memory_swap }} "
networks :
− name : " {{ network2_name }} "
cap_drop :
− all
read_only : y e s
tmpfs :
− " /tmp "
volumes :
− " /home/ v a g r a n t /MySQL_DB: / v a r / l i b / mysql "
command : −−d e f a u l t −a u t h e n t i c a t i o n −p l u g i n=mysql_native_password

Fichier 4 – [Link] de Ansible

16 avril 2019 Version 1.0 38

 Logiciel libre de gestionnaire de conteneurs

− hosts : a l l
become : y e s
vars :
cpu_period : " 100000 "
cpu_quota : " 40000 "
memory : " 300M"
memory_swap : " 300M"
tasks :
# Run AppC ( Debian S t r e t c h ) i n c o n t a i n e r
# d o c k e r run −−name AppC −−cap−drop=ALL −−read−o n l y −−t m p f s /tmp \
# −−cpu−p e r i o d =100000 −−cpu−q u o t a =40000 \
# −−memory="300M" −−memory−swap ="300M" \
# −−d e t a c h − i t ppc
− name : Run AppC c o n t a i n e r
docker_container :
name : " {{ container_name }} "
image : d e b i a n : s t r e t c h −s l i m
tty : yes
cpu_period : " {{ cpu_period }} "
cpu_quota : " {{ cpu_quota }} "
memory : " {{ memory }} "
memory_swap : " {{ memory_swap }} "
cap_drop :
− all
read_only : y e s
tmpfs :
− " /tmp "

Fichier 5 – [Link] de Ansible

16 avril 2019 Version 1.0 39

 Logiciel libre de gestionnaire de conteneurs

Annexe B Debian Stretch

B.1 Introduction
La plupart des images officielles de Docker dont les images officielles Docker PHP et MySQL
sont des images basées sur le système d’exploitation (OS) Debian 59 dont les images officielles sont
disponibles en plusieurs versions sur le dockerhub 60 .

B.2 Image Docker

Ces images utilisent la version avec une faible empreinte mémoire (suppression de certains
fichiers qui ne sont normalement pas nécessaires au fonctionnement des conteneurs, comme les
pages de manuel et la documentation) qui est disponible à partir du tag <version>-slim.
Démarrer une instance Debian Stretch 61 « slim » :
$ d o c k e r run −−name d e b i a n −d d e b i a n : s t r e t c h −s l i m

59. [Link]
60. [Link]
61. [Link]

16 avril 2019 Version 1.0 40

 Logiciel libre de gestionnaire de conteneurs

Annexe C MediaWiki
C.1 Introduction
MediaWiki 62 est un moteur de wiki pour le Web, écrit en PHP, qui peut aussi bien fonctionner
avec le système de gestion de base de données MySQL que PostgreSQL.

C.2 Image Docker

Une image officielle Docker est disponible sur le dockerhub 63
Démarrer une instance mediawiki :
$ d o c k e r run −−name m e d i a w i k i −p 8 0 8 0 : 8 0 −d m e d i a w i k i

L’instance est accessible depuis l’hôte sans l’IP du conteneur à l’adresse [Link]
ou [Link] dans un navigateur.

C.3 Configuration
À l’issue de l’instanciation de l’image, il faut configurer l’application pour qu’elle puisse se
connecter à la base de données (adresse IP, mot de passe, nom de la base de données, etc.) et
pour définir les nom et mot de passe de l’administrateur de l’application.
Lors de la première connexion à l’application et en l’absence de fichier de configuration
([Link]), la page d’accueil représentée à la figure 20 est affichée.

Figure 20 – Page d’accueil pour la configuration de MediaWiki

Après le choix de la langue et la page de bienvenue, la page de configuration de la connexion

à la base de données représentée à la figure 21 est affichée. Les champs suivants correspondent :
– Nom d’hôte de la base de données : AppB, le nom du conteneur de la base de données
correspondant à la valeur de la variable APPB_NAME du fichier Vagrantfile ;
62. [Link]
63. [Link]

16 avril 2019 Version 1.0 41

 Logiciel libre de gestionnaire de conteneurs

– Nom de la base de données : my_wiki, le nom de la base de données correspondant à

la valeur de la variable MYSQL_DATABASE du fichier Vagrantfile ;
– Nom d’utilisateur de la base de données : wikiuser, l’utilisateur de la base de données
correspondant à la valeur de la variable MYSQL_USER du fichier Vagrantfile ;
– Mot de passe de la base de données : example, le mot de passe de l’utilisateur de la
base de données correspondant à la valeur de la variable MYSQL_PASSWORD du fichier
Vagrantfile.

Figure 21 – Page de la configuration de la connexion à la base de données

Après la page de paramètrage de la base de données qui nécessite aucune modification particulière,
la page de configuration de l’application représenteé à la figure 22 est affichée. Les champs suivants
correspondent :
– Nom du wiki : le nom du wiki qui apparaîtra dans la barre de titre du navigateur et en
divers autres endroits ;
– Votre nom d’utilisateur : le nom du compte administrateur de l’application MediaWiki ;
– Mot de passe : le mot de passe du compte administrateur de l’application MediaWiki à
saisir une seconde fois Saisir à nouveau le mot de passe.
Cocher la case J’en ai assez, installer simplement le wiki. pour ne pas poursuivre la configuration
plus que nécessaire.

16 avril 2019 Version 1.0 42

 Logiciel libre de gestionnaire de conteneurs

Figure 22 – Page de la configuration de MediaWiki

Après avoir passé (« Continuer ») la page d’installation à plusieurs reprises, le fichier de

configuration [Link] est généré et est prêt à être enregistré (figure 23) dans le sous-
répertoire AppA du répertoire qui contient le fichier de configuration Vagrant, Vagrantfile.

Figure 23 – Fichier de configuration [Link]

16 avril 2019 Version 1.0 43

 Logiciel libre de gestionnaire de conteneurs

Pour que l’application MediaWiki prenne en compte le fichier de configuration généré, la ligne
suivante du fichier de configuration Ansible [Link] doit être décommentée :

tmpfs :
− " /tmp "
# uncomment t h e f o l l o w i n g l i n e s and r e s t a r t t h e m e d i a w i k i s e r v i c e
volumes :
− " / v a g r a n t /AppA/ L o c a l S e t t i n g s . php : / v a r /www/ html / L o c a l S e t t i n g s . php "

Fichier 6 – Modification du fichier de configuration Vagrant

Le conteneur de l’application MediaWiki doit être redémarré en exécutant la commande

suivante :

$ vagrant p r o v i s i o n

À l’issue du conteneur, une nouvelle page d’accueil représentée à la figure 24 est affichée.

Figure 24 – Page d’accueil de MediaWiki

16 avril 2019 Version 1.0 44

 Logiciel libre de gestionnaire de conteneurs

Annexe D Preuve de concept CVE-2019-5736

# −∗− mode : r u b y −∗−
# # v i : s e t f t =r u b y :
Vagrant . c o n f i g u r e ( " 2 " ) do | c o n f i g |
c o n f i g . vm . box = " ubuntu / b i o n i c 6 4 "

# I n s t a l l p y th o n f o r a n s i b l e
c o n f i g . vm . p r o v i s i o n " s h e l l " , i n l i n e : <<−SHELL
t e s t −e / u s r / b i n / python | | ( apt−g e t −qqy update && apt−g e t i n s t a l l −qqy python
−minimal > / dev / n u l l 2>&1)
SHELL

# Run A n s i b l e from t h e Vagrant Host

# I n s t a l l and c o n f i g u r e Docker
c o n f i g . vm . p r o v i s i o n " a n s i b l e " do | a n s i b l e |
a n s i b l e . compatibility_mode = " 2 . 0 "
a n s i b l e . playbook = " d o c k e r . yml "
a n s i b l e . extra_vars = {
version : " 18.06.0 " ,
}
end

# h t t p s : / / g i t h u b . com/ t w i s t l o c k /RunC−CVE−2019−5736
c o n f i g . vm . p r o v i s i o n " a n s i b l e " do | a n s i b l e |
a n s i b l e . compatibility_mode = " 2 . 0 "
a n s i b l e . playbook = "CVE−2019 −5736. yml "
end
end

Fichier 7 – Vagrantfile de Vagrant

− hosts : a l l
become : y e s
tasks :
− name : Clone RunC−CVE−2019−5736 ( T w i s t l o c k )
git :
r e p o : h t t p s : / / g i t h u b . com/ t w i s t l o c k /RunC−CVE−2019 −5736. g i t
d e s t : /home/ v a g r a n t /RunC−CVE−2019−5736

− name : B u i l d t h e Docker image

docker_image :
name : cve −2019−5736
path : /home/ v a g r a n t /RunC−CVE−2019−5736/exec_POC
d o c k e r f i l e : /home/ v a g r a n t /RunC−CVE−2019−5736/exec_POC/ D o c k e r f i l e

− name : Run t h e Docker c o n t a i n e r

docker_container :
name : CVE−2019−5736
image : cve −2019−5736
detach : yes
cleanup : yes

− name : Run POC

command : d o c k e r e x e c CVE−2019−5736 / b i n / bash
ignore_errors : yes

− name : Execute / u s r / b i n / docker −runc

command : / u s r / b i n / docker −runc
r e g i s t e r : ou tp ut
− debug : v a r=o ut pu t . s t d o u t _ l i n e s

Fichier 8 – [Link] de Ansible

16 avril 2019 Version 1.0 45

 Logiciel libre de gestionnaire de conteneurs

Références
[1] Michael Crosby. Building a container supervisor, 2016. [Link]
crosbymichael/dockercon-2016/blob/master/Creating%[Link].
[2] Center for Internet Security. Cis docker community edition benchmarki v1.1.0, June 2017.
[Link]
[3] Alexander Holbreich. Docker components explained, Avril 2018. [Link]
[Link]/docker-components-explained/.
[4] Dan Walsh. Secure your containers with this one weird trick, October 2016. [Link]
[Link]/2016/10/17/secure-your-containers-with-this-one-weird-trick/.

16 avril 2019 Version 1.0 46