Monter un container LXC

[supersnail]

Bonjour à tous et bonne année !

Depuis quelques temps je fais joujou avec la virtualisation sur notre gnou/manchot préféré, et je profite de cette section "Administration système" flambant neuve pour faire un petit guide de la galaxie LXC pour les débutants.

I - LXC, kézako et à quoi ça va me servir ?

Tout d'abord, LXC est un projet (heureusement bien avancé) permettant de faire de la "virtualisation légère", c'est-à-dire de créer des machines virtuelles GNU/Linux qui utilisent le noyau de l'hôte. De plus, la virtualisation repose sur les fonctionnalité d'un noyau Linux récent "standard", ainsi contrairement à OpenVZ, pas besoin d'un noyau patché pour s'adonner au plaisirs de la virtualisation ! . LXC s'apparente donc aux "jails" de FreeBSD ou encore aux "zones" de Solaris.

Venons-en à la deuxième question qui est "à quoi ça va me servir ?" (je supposerai ici que vous n'êtes pas un un sysadmin vétéran, cc Snorky :þ). Je pourrais répondre que cela peut permettre de tester de nouveaux logiciels sans craindre de péter sa distribution principale, isoler des programmes privateurs (qui a dit Oracle ?) ou qui essaient d'espionner l'utilisateur (qui a dit Skype ? >:]), ou tout simplement séparer environnement de dev/machine de tous les jours (la mise en place/migration d'une VM de production peut même se faire assez facilement grâce à Docker, qui s'appuie justement sur LXC, bien que Docker semble supporter d'autres technos). Cependant je ne recommande pas LXC pour faire des VM de CTF ou pour débugguer des malwares/rootkits, justement à cause du fait que le container et l'hôte partagent le même noyau (un exploit kernel et PAF le système :'))

II - Comment ça s'installe / comment on s'en sert ?

Tout d'abord il va falloir nous munir d'un compte root (étant donné que nous aurons plusieurs commandes à taper, je recommande un "su" et un "sudo -s" pour les ubunteros). Il nous faudra installer le paquet "lxc" de la distribution (via apt-get sur debian/ubuntu/mint, yum pour fedora et pacman pour archlinux).
Pour ceux qui ont une partition "/" assez petite, étant donner que les machines virtuelles vont se placer dans /var/lib/lxc, je vous recommande de symlinker ce répertoire vers une partition plus grande (de toute façon, seul root pourra accéder aux VM ).

Vient ensuite le grand moment de notre vie, l'installation de notre container \o/. Il suffit de taper la commande magique:

Code :

# lxc-create -n <nom_de_votre_vm> -t download

Ici, le "-t download" indique qu'on utilise le template "download", qui comme son nom l'indique va télécharger une image système depuis linuxcontainers.org afin de permettre un déploiment rapide (si vous êtes paranos, vous pouvez toujours installer les outils nécessaires pour construire une image vous-même et utiliser un template listé dans /usr/share/lxc/templates).
Vous devrez ensuite sélectionner la distribution, sa version ainsi que l'architecture (i386 pour du 32 bits et amd64 pour du 64bits), puis après un temps plus ou moins long, le temps de télécharger l'image du système, vous vous retrouvez face à votre container lxc tout brillant .

Cependant, avant de lancer la VM, il vous faudra définir un mot de passe root, celui-ci n'ayant pas été défini dans les images de VM téléchargées. Vous pouvez pour le faire soit chrooter directement dans le dossier du container, soit la méthode plus "classe" qui est de démarrer le container (via un

Code :

lxc-start -n <le_nom_du_template>

) puis dans un autre terminal, obtenir un shell via un

Code :

lxc-attach -n <le_nom_du_template>

, puis lancer un "passwd".

Normalement, vous devriez avoir un container fonctionnel, mais sans accès au réseau cependant, ce que nous allons corriger dans la section suivante.

III - Configuration du réseau

Nous allons ici créer un réseau de type "veth" pour LXC (que l'on pourra aussi réutiliser pour des VM Qemu/KVM et ainsi avoir un joli LAN de machines virtuelles ) à l'aide d'un bridge.

Pour les ubunteros, le bridge est déjà préconfiguré (l'installation de lxc a créé un périphérique "lxcbr0" directement disponible). Sinon, je vous laisse vous référer à la documentation de votre distribution pour la création d'un bridge car je suis flemmard et j'ai pas envie de traiter la configuration du bridge pour chaque distribution existante. Dans ce tutoriel, on ne se limite qu'à la création d'un réseau privé virtuel, que vous pourrez éventuellement NATer. Dans la suite du tutoriel, je considèrerai que tout le monde a défini l'adresse IP de br0 (ou lxcbr0) à 10.0.1.1/24 (sans passerelle par défaut).

Une fois votre bridge créé, il suffit de modifier la configuration de la VM (dans /var/lib/lxc/<nom_de_la_vm>/config) et y rajouter/remplacer ceci:

Code :

lxc.network.type = veth
lxc.network.link = br0 # à remplacer par lxcbr0 pour les ubunteros ;)
lxc.network.ipv4 = 10.0.1.xx/24
lxc.network.ipv4.gateway = 10.0.1.1

Du côté de l'hyperviseur, un petit

Code :

iptables -t nat -F POSTROUTING -s 10.0.1.0/24 -j MASQUERADE

vous permettera de NATer en toute tranquilité
Vous pouvez arrêtez le container, si vous l'avez déjà lancé via un petit "lxc-stop -n <nom_de_la_VM>". Au prochain démarrage vous devriez avoir un réseau fonctionnel ! (modulo le DNS à rajouter dans /etc/resolv.conf).

Ce sera tout ici, si vous avez des questions/difficultés de configuration n'hésitez pas à les poser

[Atlas]

Bonsoir,
merci beaucoup pour ce guide !
J'aurais une question (probablement idiote) : quels sont les avantages de lxc par rapport à une machine virtuelle "classique" comme virtualbox ?
La différence si j'ai bien compris est lxc utilise le noyau Linux de notre OS , mais quels en sont les avantage?

Merci

[supersnail]

Ben les avantages c'est déjà que ça bouffe beaucoup moins de mémoire; et les performances sont meilleures que du virtualisé: déjà on s'épargne de charger un noyau supplémentaire, puis on a pas d'émulation/virtualisation d'instructions, les processus s'exécutent réellement sur le processeur hôte.

[otherflow]

Ben les avantages c'est déjà que ça bouffe beaucoup moins de mémoire; et les performances sont meilleures que du virtualisé: déjà on s'épargne de charger un noyau supplémentaire, puis on a pas d'émulation/virtualisation d'instructions, les processus s'exécutent réellement sur le processeur hôte.

Si vous voulez des informations supplémentaires au sujet de ce type de virtualisation, il y a un article dessus sur Wikipedia : Operating-system-level virtualization

otherflow

---

Le tutoriel lu je peux me permettre de remercier supersnail.

Merci joli tutoriel !

otherflow

PS pour les modo et admin : Je n'ai pas trouvé de moyen éditer mon message précédant.

[0pc0deFR]

Petite question: d'un point de vu sécu ça donne quoi, est-ce qu'il y a un risque, en attaquant lxc d'atteindre le machine hôte ou de corrompre le noyau puisque c'est le même pour les deux machines?

[supersnail]

Oui, un sploit kernel peut affecter la machine hôte d'où ma mise en garde .

Par contre un shutdown de lxc n'éteindra que le container et non l'hôte (de ce que j'ai compris, shutdown ne fait qu'envoyer un signal à init qui va se charger d'éteindre proprement le système, corrigez-moi si je me suis planté comme une grosse buse )

[T1loc]

Salut, \o

Tu as raison pour ce qui est du shutdown.
Ce que je trouve dommage c'est que certain outils ne sont pas portés sur des distrib grand public (et quand je dis grand public je parle pas d'ubuntu )

J'utilise depuis quelques moi lxc étant donné que je suis dans la virtualisation sur Gnu/Linux.

Je vous partage un petit code qui me donne quelques info utiles.
Uniquement testé sur CentOS mais devrait être compatabile à 90% je pense :-)

Code :

#!/bin/bash
# Description : Script d'info des conteneur lxc
# Auteur : T1loc
# Date : 24.10.2014

# On recupere le nom des CT
declare -A CT_name

# Compteur d'indice du tableau
cpt=0

i=''; for i in $(lxc-ls); do
  # On recupere l'etat de la machine
  j=$(lxc-info -s -n $i|awk '{print $NF}')
  # On recupere les ip
  k=$(lxc-info -i -n $i|awk '{print $NF}'|paste -sd '+' -)
  # Info supplementaire avec l'option -a
  if [ "$1" == "-a" ]; then
    # On recupere l'interface de l'hote physique
    l=$(lxc-info -S -n $i|grep Link | awk '{print $NF}')
    # On recupere si l'autostart est active
    m=$(awk '/lxc.start.auto/{print $NF}' /var/lib/lxc/$i/config)
    # On recupere la memoire utilise
    n=$(lxc-info -n $i -S|grep Memory|awk '{print $(NF-1) $NF}')
  fi
  # On fout tous dans un tableau
  CT_name+=([$cpt]="$i;$j;$k;$l;$m;$n;")
  # On incremente (pour le fun ? :p)
  ((cpt++))
done

# Variable pour la couleur et les colonnes
RESETCOLOR="$(tput sgr0)"
VERT="$(tput bold ; tput setaf 2)"
BLEU="$(tput bold ; tput setaf 4)"

clear #Obligatoire..
COLUMNS=`tput cols`
column=`expr \( $COLUMNS - 20 \) / 2`
tput cup 0 $column
tput rev
# On affiche les entetes de colonne
echo -e "${BLEU}Info globale sur les CT"
tput sgr0
tput rc

tput cup 0 0
echo "${VERT}"
echo  "Conteneur"

tput cup 1 30
echo "Etat"

tput cup 1 42
echo "IP ${RESETCOLOR}"
# On affiche plus avec -a
if [ "$1" == "-a" ]; then
  tput cup 1 51
  echo "${VERT}Interface"

  tput cup 1 63
  echo "AutoStart"

  tput cup 1 74
  echo "Mémoire utilisé ${RESETCOLOR}"
fi

line=2
# On parse notre tableau pour le joli rendu :)
x=''; for x in ${CT_name[@]}; do
  # On affiche le conteneur
  awk -F';' '{print $1}' <<< "$x"
  tput cup $line 30
  # On affiche l'etat
  awk -F';' '{print $2}' <<< "$x"
  tput cup $line 39
  # On affiche l'ip principal (eth0)
  awk -F';' '{print $3}' <<< "$x" | awk -F'+' '{print $1}'
  tput cup $line 51
  # On affiche l'interface
  awk -F';' '{print $4}' <<< "$x"
  tput cup $line 66
  # On affiche l'autostart 1 = enable alors on affiche oui
  awk -F';' ' $5 == "1" {print "Oui"}' <<< "$x"
  tput cup $line 75
  # On affiche la memoire
  awk -F';' '{print $6}' <<< "$x"
  ((line++))
done

# Tchao
exit 0

[Xpl0ze]

Salut à tous,

juste pour apporter ma petite pierre à l'édifice pour parler de la sécu dans LXC.

Je pense qu'LXC ne répond pas à tout les cas d'utilisations, notamment dans le cas d'une infra critique, et je vais expliquer pourquoi.

Quand on parle de conteneurisation , à la base il faut savoir qu'il y a plusieurs technos qui lead le game : Docker, LXC et Rocket.
Tout le monde a déjà entendu parlé de Docker, et on le compare souvent à LXC, oui mais voilà : si se sont bien tout deux des solutions de conteneurisations, ces deux solutions fonctionnent de manière bien différente. je vais pas m'étaler sur les différences de rootfs, montage, namespaces etc.
Le fait est que Docker nécessite un Daemon exécuté exclusivement avec les droits superuser (soit en root) tandis que LXC permet d’exécuter des conteneurs en root ou non.
L’Intérêt d’exécuter un conteneur en non root est que dans le cas ou un vilain arrive à se connecter sur un conteneur, et s’échapper de celui-ci pour toucher l'host, il ne sera "que" user , et non pas superuser. Oui mais voilà : le problème principal de LXC est aussi ce qui fait sa force : un seul et meme kernel est utilisé par tout les conteneurs.
La plus part des vulnérabilités qui permettront d'échapper le conteneur viendront du kernel. Il y a de très très très grandes chances qu'une vulnérabilité dans le kernel qui permette de s’échapper d'un conteneur permette également de devenir root.

On met donc en avant le fait que cela utilise moins de ram, que cela permet d’exécuter un seul noyau etc etc. C'est vrai, mais il faut prendre en compte le fait que tout ces points forts sont aussi des points faibles dans une infrastructure sécurisée.
Je m'explique : dans un environnement sécurisé là ou il y a 10 VM, on pourrait penser qu'il y aura 10 conteneurs sur une vm (ou même un poste lourd) . Le problème c'est qu'en fonction des middleware qui tournent sur les différents conteneur, on aura besoin d'activer des modules du kernel (ip_vs_rr par exemple...) . Si le premier conteneur a besoin de ce module , et que le deuxième conteneur n'en a pas besoin, tant pis pour vous ce module sera accessible depuis les 2 conteneurs; ce qui -1- ne sera pas le cas avec des VM correctement paramétrés et -2- accroit le nombre de vulnérabilités possible sur les deux machines.
Dans le cas d'un exploit lié à une vulnérabilité du kernel , tout les containers sont automatiquement touchés . Admettons que sur cette même VM , en tant qu'attaquant, vous n'ayez les logins que d'un conteneur. Cela mets quand même en péril les 9 autres.
Exemple avec un kernel panic, l'host et les 10 conteneurs seront freeze même si ceux-la ne font pas partie du même réseau logique, ou ne sont même pas connectés à internet (testé et approuvé sur ubuntu 14.04 j'ai plus la CVE en tête).

LXC supporte aussi le système de capabilities . Pour rappel (ou pas) les capa sont des groupes de droits qui visent à remplacer le suid. Par exemple, Un binaire a uniquement le droit d'utiliser le module du kernel qui permet de créer des sockets (CAP_RAW_IO) mais ne peux pas utiliser les fonctions nécessaire à un mount. on gere les capabilities soit en les attribuant à tout un conteneur via les fichiers de conf (uniquement si c'est un conteneur privilégié = lancé en root) ou directement sur les binaires depuis l'host (si c'est un conteneur non privilégié = lancé en non root) via les outils getcap et setcap
Ce système est censé permettre de gérer au mieux quels fichiers on accès à quels fonctions du kernel. Oui , mais un grand nombre de capabilities permettent à elles seules d'abuser du kernel (CAP_SETUID etc) . Les capa peuvent même rendre un binaire plus vulnérable . Un programme SUID appartient à root, un programme non SUID appartient à l'utilisateur. à partir de là, tout les fichiers générés par ce binaires changent d'owner et il devient possible d'en abuser (cf le POC sur le binaire passwd dispo sur internet).

Bref je trouve qu'LXC est tres bien pour de la préprod ou de la petite prod non critique, mais que ça devient vraiment tricky lorsqu'il s'agit d'intégrer ça dans un système critique. Je ne dis pas qu'il ne faut pas l'utiliser, mais c'est comme une vrai archi réseau , la distribution des conteneurs entre VM doit être très réfléchi si elle est vouée à être mise en prod ( un minimum de sécu dans les reseaux de prod est selon moi indispensable).

Encore une fois je ne critique pas la techno, j'essaie juste de mettre en perspective les bons et mauvais cotés car on trouve encore peu voir pas de doc sur le sujet.

PS : depuis un conteneur non privilégié, on peut retrouver la vrai racine du conteneur sur l'host et le nom de l'utilisateur qui a lancé le container ...c'est un début d'information disclosure, même si ça vaut ce que ça vaut =).

A+ o/

[supersnail]

Bonjour,
En plus les containers non privilégié c'est tout buggué , les features du noyau nécessaires pour les containers non privilégiés sont tellement bourrés de failles que les devs d'ArchLinux ont carrément décidé de zigouiller la feature dans le kernel "officiel"

Sinon c'est clair que pour une infra critique c'est pas top (je l'ai jamais nié :þ) du fait justement que ça partage le même kernel (et donc les 0day liées au kernel justement). Néanmoins ça me semble être une meilleure alternative qu'OpenVZ qui est à peu près la même chose sauf que c'est des patchs appliqué sur un kernel vieillissant (2.6.32 de mémoire) et maintenu par les développeurs d'OpenVZ exit donc systemd et les distributions l'utilisant :').

Bref ce type de VM sert surtout pour le "cloud" et la facilité de déploiment (ton image de l'OS est la même partout donc pas de risques de mauvaises surprises avec la libmachin qui dépend de la libtruc mais à une version supérieure que celle fournie par la distrib, etc...) j'ai l'impression, ou de labo pour tester un truc à l'arrache sur une distribution.

Après si on tient vraiment à faire un système critique avec du container léger, faut réduire au minimum les modules kernel chargés, voire même inclure les modules directement dans le noyau et virer les modules chargeables du kernel.

Edit: j'en profite pour rappeler une règle élémentaire: toujours faire les mises à jour très régulièrement pour être l'abri des failles découvertes et patchées