Si votre nom d’utilisateur n’apparaît pas dans la ligne renvoyée, cela signifie que vous n’êtes pas dans le groupe, et vous devez vous ajouter au groupe kvm :

Ensuite, déconnectez-vous puis reconnectez-vous pour que le changement prenne effet.

Construire depuis l’hôte

Si vous construisez directement depuis votre machine avec build.sh, vous devrez installer debos :

Ensuite, utilisez le script build.sh pour construire une image VM directement sur votre machine.

Construire depuis un conteneur

Si vous préférez construire depuis un conteneur, vous devrez installer et configurer docker ou podman sur votre machine. Ensuite, utilisez le script build-in-container.sh pour construire une image.

build-in-container.sh est simplement un wrapper autour de build.sh. Il détecte quel moteur de conteneur conforme à l’OCI utiliser, se charge de créer l’image conteneur si elle est absente, puis lance enfin le conteneur pour effectuer la construction depuis celui-ci.

docker nécessite que l’utilisateur soit ajouté au groupe Docker, comme ci-dessus avec KVM, ou d’utiliser le compte root (par ex. $ sudo ./build-in-container.sh). podman a été testé à la fois en mode rootful (par ex. $ sudo ./build-in-container.sh) et en mode rootless (par ex. $ ./build-in-container.sh).

Construire une image

Utilisez build.sh ou build-in-container.sh, selon votre préférence. À partir de maintenant, nous utiliserons build.sh par souci de concision.

Exemples

Le meilleur point de départ, comme toujours, est le message d’utilisation :

Les options par défaut permettent de construire une image Kali rolling, avec le bureau par défaut et la sélection d’outils par défaut pour l’architecture AMD64.

Il s’agit d’une image disque brute, c’est-à-dire une image binaire simple du disque (qui peut être démarrée avec QEMU).

Exemple :

Pour construire une image Kali Linux adaptée à VMware. Cela signifie qu’elle est livrée avec les Open VM Tools préinstallés, et l’image produite est prête à être importée « telle quelle » dans VMware.

Nous allons également la construire à partir de la dernière version stable de Kali, et nous utiliserons GNOME comme environnement de bureau, plutôt que le Xfce habituel par défaut :

Pour construire une image Kali Linux conçue pour VirtualBox. Elle est livrée avec les utilitaires invités VirtualBox préinstallés, et l’image peut être importée « telle quelle » dans VirtualBox.

De plus, nous voulons un disque virtuel de 150 Go, et nous installerons la sélection d’outils « everything » :

Pour construire une image Kali légère, sans environnement de bureau ni sélection d’outils par défaut. C’est une image générique, elle prend en charge la plupart des moteurs de VM existants. Nous l’exporterons au format OVA, adapté à la fois à VMware et à VirtualBox.

Vous pouvez installer des paquets supplémentaires avec l’option -P. Vous pouvez utiliser l’option plusieurs fois (par ex. -P pkg1 -P pkg2 ...), ou fournir une valeur séparée par des virgules/espaces (par ex. -P "pkg1,pkg2, pkg3 pkg4"), ou un mélange des deux. Installons également le paquet metasploit-framework :

Lors de la construction d’une série d’images, il peut être plus pratique (et plus rapide) de diviser la construction en deux parties : d’abord, construire une rootfs, puis construire les images en réutilisant cette rootfs comme point de départ.

Dans l’exemple ci-dessous, nous construisons d’abord une rootfs kali-rolling, puis nous construisons une série d’images Vagrant :

Pour définir les paramètres du clavier, utilisez l’option -K. Le paramètre est de la forme <layouts>/<models>/<variants>/<options>. Chaque paramètre peut être omis (dans ce cas, la valeur par défaut est utilisée) ou peut avoir plusieurs valeurs séparées par des virgules. Dans le cas le plus simple, vous pouvez simplement vouloir changer la disposition du clavier : vous définiriez alors us pour une disposition de clavier américaine, de pour une disposition de clavier allemande, etc. Des explications plus détaillées et des exemples se trouvent dans la page de manuel keyboard(5).

Pour la liste des valeurs prises en charge, vous pouvez vous référer au fichier /usr/share/X11/xkb/rules/xorg.lst (fourni par le paquet xkb-data sur Debian et les systèmes de type Debian). Ce fichier comporte différentes sections (! layout, ! model, !variant et !option) qui listent les valeurs possibles pour chaque paramètre. Vous pouvez également vérifier ce qui est configuré sur votre système avec cat /etc/default/keyboard. Il existe aussi un raccourci -K same pour correspondre au système hôte (c’est-à-dire ce qui est défini dans le fichier /etc/default/keyboard).

Pour définir la locale, utilisez l’option -L. Choisissez une valeur dans la première colonne de /usr/share/i18n/SUPPORTED, ou vérifiez ce qui est configuré sur votre système avec grep -v ^# /etc/locale.gen, ou simplement echo $LANG. Il existe aussi un raccourci -L same pour correspondre au système hôte.

Pour définir le fuseau horaire, utilisez l’option -Z. Regardez dans /usr/share/zoneinfo et choisissez un répertoire et un sous-répertoire. En cas de doute, exécutez tzselect pour vous guider, ou regardez ce qui est configuré sur votre système avec realpath /etc/localtime. Il existe aussi un raccourci -Z same pour correspondre au système hôte.

Pour définir le nom et le mot de passe de l’utilisateur non privilégié, utilisez l’option -U. La valeur est une chaîne unique et le caractère : est utilisé pour séparer le nom d’utilisateur du mot de passe.

Ici, nous allons construire une image Kali et la configurer pour imiter le système hôte : même locale, même fuseau horaire et même nom d’utilisateur (avec le mot de passe password) :

Variantes et formats

Différentes variantes d’image peuvent être construites, selon le moteur de VM dans lequel vous souhaitez exécuter l’image Kali. La VARIANTE définit principalement quel paquet supplémentaire est installé dans l’image pour ajouter la prise en charge d’un moteur de VM particulier. Ensuite, le FORMAT définit le format du disque virtuel et les fichiers de métadonnées supplémentaires à produire.

S’il n’est pas défini, le format (option -f) est automatiquement défini en fonction de la variante (option -v). Toutes les combinaisons de variante et de format n’ont pas de sens, c’est pourquoi le tableau ci-dessous tente de résumer les combinaisons les plus courantes.

Les images generic sont livrées avec les paquets de prise en charge de la virtualisation préinstallés pour QEMU, VirtualBox et VMware, d’où le nom « generic ». En revanche, les autres images, qui ciblent un moteur de VM spécifique, ne sont livrées qu’avec la prise en charge de ce moteur de virtualisation particulier.

Seul le format ova définit un conteneur : le résultat de la construction est un fichier .ova, qui est simplement une archive tar. Pour les autres formats, la construction produit des fichiers séparés. Ils peuvent être regroupés dans une archive 7z avec l’option -z.

Il existe aussi un type rootfs : ce n’est pas une image. C’est simplement une arborescence de système de fichiers racine Kali Linux, sans le noyau ni le chargeur d’amorçage, empaquetée dans une archive .tar.gz. Le cas d’utilisation principal est de la réutiliser comme entrée pour construire une image système, et elle n’est pas destinée à être utilisée en dehors du système de construction.

Configuration du proxy de cache

Lors de la construction d’images système, il est utile de disposer d’un mécanisme de cache afin d’éviter de télécharger tous les paquets depuis Internet, encore et encore. À cette fin, le script de construction tente de détecter les proxies de cache connus qui seraient en cours d’exécution sur l’hôte local. Il se réfère d’abord à la configuration APT locale Acquire::http::Proxy. S’il n’est pas défini, il tente ensuite de détecter apt-cacher-ng et squid-deb-proxy en vérifiant si un service écoute sur leur port par défaut. Ce mécanisme ne fonctionne pas pour approx (un proxy de cache APT bien connu), car il est démarré automatiquement à la demande.

Pour remplacer cette détection, vous pouvez exporter vous-même la variable d’environnement http_proxy. Cependant, rappelez-vous que la construction se déroule dans une machine virtuelle QEMU ; par conséquent, localhost dans l’environnement de construction fait référence à la VM, et non à l’hôte. Si vous souhaitez joindre l’hôte depuis la VM, vous voudrez probablement utiliser http://10.0.2.2.

Par exemple, si vous souhaitez utiliser un proxy qui s’exécute sur votre machine sur le port 9876, utilisez : export http_proxy=http://10.0.2.2:9876. Si vous voulez vous assurer qu’aucun proxy n’est utilisé, utilisez : export http_proxy=.

Reportez-vous également à https://github.com/go-debos/debos#environment-variables pour plus de détails.

Vous pouvez également configurer un miroir local.

Construire et réutiliser une rootfs

Il est possible de diviser la construction en deux étapes. Vous pouvez d’abord construire une rootfs avec ./build.sh -v rootfs, puis construire une image basée sur cette rootfs avec ./build.sh -r ROOTFS_NAME.tar.gz. C’est utile si vous prévoyez de construire plusieurs types d’images, par exemple.

Dépannage de la construction

Mémoire insuffisante

Lorsque la zone de travail temporaire est pleine (c’est-à-dire que la valeur de --scratchsize est trop faible), la construction peut échouer avec ce type de messages d’erreur :

Solution : augmentez la valeur de --scratchsize. Vous pouvez passer des arguments à debos après le caractère spécial --. Par exemple, si vous avez besoin de 50G, vous pouvez faire ./build.sh [...] -- --scratchsize=50G.

Obtenir un shell dans la VM lorsque la construction échoue

Lors du débogage d’échecs de construction, il est pratique d’être placé dans un shell à l’intérieur de la VM où la construction a lieu. C’est possible en donnant l’option --debug-shell à debos : ./build.sh [...] -- --debug-shell.

Dépannage à l’exécution

ovf incompatible avec VMware ESXI

C’est un problème connu ; reportez-vous à https://gitlab.com/kalilinux/build-scripts/kali-vm/-/work_items/25#note_1301070132 pour une solution de contournement.