Monter un container LXC

Atlas · 04-01-2015, 22h41

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*** · 04-01-2015, 23h01

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 · (Modification du message : 07-01-2015, 01h27 par otherflow.)

(04-01-2015, 23h01)supersnail a écrit : 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.

08-01-2015, 20h13

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*** · 08-01-2015, 20h21

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

.

Par contre un shutdown de lxc n'éteindra que le container et non l'hôte Wink

(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 Tongue

)

T1loc · 28-01-2015, 18h06

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 Smile

)

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 · 03-09-2015, 18h45

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 · (Modification du message : 03-09-2015, 19h09 par supersnail.)

Bonjour,
En plus les containers non privilégié c'est tout buggué Big Grin

, 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" Big Grin

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 Wink

(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

~~Galenml~~ · 13-03-2018, 22h22

Fed up of typing who can write my essay in the search bar? EssayErudite.com will come as an excellent solution to this problem.
Write my essay https://essayerudite.com/write-my-essay/

~~Galenml~~ · 13-03-2018, 22h52

We value excellent academic writing and strive to provide outstanding essay writing service each and every time you place an order. We write essays, research papers, term papers, course works, reviews, theses and more, so our primary mission is to help you succeed academically.
essay writing service https://essayerudite.com

Identifiant Mot de passe
S’enregistrer \| Mot de passe oublié ? Se rappeler