documentation/procédures/administration_vm_sans_root.md

Introduction

Comme beaucoup d'infrastructures d'hébergement, Libre en Communs à mis en pratique les politiques suivantes:

• Elle réduisent la surface d'attaque de l'hôte faisant tourner les machines virtuelles en faisant en sorte que le minimum d'applications ou de services y soient installés.

• Elle ne laisse pas l'accès root à tout le monde.

• Elles permettent à beaucoup de monde d'avoir accès à des machines virtuelles.

Le fait que ce soit pertinent ou pas dépend de la situation et des buts des projets qui utilisent l'infrastructure. Il y'a pas mal de manières différentes de faire et chacunes ont leurs avantages et désavantages.

Dans Libre en communs c'est fait pour diminuer les risques et l'impact de compromission de clées SSH. En effet plusieurs infrastructures critique de projets libres comme Fedora[1] ou Linux[2] ont été compromises par la copie de clef SSH. Debian[3] à aussi été compromis de façon similaire: par la compromission de la machine d'une personne qui avait accès à l'infrastructure.

Un des désavantages avec cette approche est qu'on ne peut pas facilement installer une distribution non supportée par l'infrastructure, ou installer une distribution existante d'une façon non supportée par l'infrastructure.

Par exemple si on à du code pour créer une image Trisquel avec debootstrap, ou une image Guix avec Guix, il va falloir le faire tourner dans une machine virtuelle.

Ce document va regarder différentes approches pour contourner ce problème.

Roles et permissions

L'infrastructure utilise libvirt, notamment libvirt QEMU. LXC est aussi présent mais pas utilisé.

Certaines personnes on un accès root aux machines physiques et peuvent tout faire.

D'autres ont un shell (sans accès root) et un accès direct à libvirt par SSH. Pour l'instant l'accès shell permet aussi d'utiliser virsh, mais ce ne sera plus le cas dans le futur.

D'autres personnes ont seulement un accès SSH dans une ou plusieurs machines virtuelles.

Outils disponibles

On à une machine virtuelle Trisquel generic_trisquel.a-lec.org qui peut facilement être clonée par une personne avec un accès libvirt. Une fois clonée et l'accès SSH activé, on à 50GiB d'espace dedans.

On a aussi le droit d'installer Guix sur les machines physiques à condition de faire en sorte que Guix se mette à jour automatiquement assez souvent.

Les personnes qui ont un accès libvirt peuvent créer des VM avec une carte graphique, mais une fois que les VM qui vont tournent en production c'est une bonne idée d'enlever la carte graphique car ça donne accès à la VM à n'importe quelle personne qui à un shell sur la machine physique[4]. Et donc en cas de compromission de clef SSH ça limite la casse.

Vu que l'accès shell ne va plus impliquer l'accès à libvirt dans le futur, et que ne pas avoir de carte graphique virtuelle protège aussi de l'accès par du code qui tourne sur d'autres comptes n'ayant pas accès à libvirt, il vaux mieux utiliser le port série.

Utiliser la VM generic_trisquel.a-lec.org

Si on à un accès à libvirt on peut se loguer dedans avec l'utilisateurice admin666 et 'sudo su' marche sans mot de passe. Pour ça faut utiliser le port série. A noter que c'est aussi disponible (et bien plus fiable) si on passe par SSH et un shell sur la machine avec la commande suivante:

virsh -c qemu:///system console generic_trisquel.a-lec.org

Commandes virsh intéressantes

Si on à un accès à libvirt on peut cloner une machine virtuelle avec virt-manager, ou cloner des disques virtuels en ligne de commande avec la command vol-clone de virsh. Par contre j'ai pas trouvé comment renomer un disque virtuel. Il faut donc le copier et le déléter après. A noter que les copies peuvent mettre un certain temps (~ 10 minutes pour 50 GiB).

On peut aussi augmenter la taille du disque virtuel d'une VM éteinte avec la commande vol-resize de virsh et d'une VM allumée avec la commande blockresize de virsh.

Utiliser un iso netinstall avec un port série.

Pas mal de medias d'installeurs n'activent pas le port série par défaut, sinon ça risquerait de casser certaines tablettes brailles très chères (ça l'a fait par le passé).

Et taper des commandes à l'aveugle dans virt-manager ne marche pas quand la carte graphique virtuelle est désactivée, du coup on doit utiliser un script à la place.

Voici un script qui active le port série pour trisquel-netinst_11.0_amd64.iso:

#!/bin/sh
# Copyright (C) 2023 Denis 'GNUtoo' Carikli
# SPDX-License-Identifier: GPL-3.0-or-later
virsh -c qemu:///system send-key trisquel-installer 15 # TAB
virsh -c qemu:///system send-key trisquel-installer 46 # C
virsh -c qemu:///system send-key trisquel-installer 24 # O
virsh -c qemu:///system send-key trisquel-installer 49 # N
virsh -c qemu:///system send-key trisquel-installer 31 # S
virsh -c qemu:///system send-key trisquel-installer 24 # O
virsh -c qemu:///system send-key trisquel-installer 38 # L
virsh -c qemu:///system send-key trisquel-installer 18 # E
virsh -c qemu:///system send-key trisquel-installer 13 # =
virsh -c qemu:///system send-key trisquel-installer 20 # T
virsh -c qemu:///system send-key trisquel-installer 20 # T
virsh -c qemu:///system send-key trisquel-installer 21 # Y
virsh -c qemu:///system send-key trisquel-installer 58 # CAPSLOCK
virsh -c qemu:///system send-key trisquel-installer 31 # S
virsh -c qemu:///system send-key trisquel-installer 11 # 0
virsh -c qemu:///system send-key trisquel-installer 28 # ENTER

Il faut attendre à peu près une seconde et lancer le script. Trisquel-installer est le nom de la VM dans libvirt sur mes machines, donc il faut ajuster ça.

Autres distributions

Trisquel à des paquets pour debootstrap et guix. L'article CrossDistroBootstrap[5] permet de savoir quelles distributions peuvent être installées avec ça. Pour que ça marche il faut aussi attacher un second disque virtuel à la machine virtuelle car dans generic_trisquel.a-lec.org la partition principale prend tout l'espace du disque.

Références

[1]https://lwn.net/Articles/326170/ "[...] the intruder took a copy of a SSH private key which was not secured with a passphrase from a system outside the Fedora infrastructure. The intruder then used that key, which belonged to a Fedora administrator, to access Fedora systems." [2]https://lwn.net/Articles/609463/ "The [kernel.org] compromise almost certainly started with the acquisition of SSH keys from one or more developer laptops" [3]https://lwn.net/Articles/62517/ "[The attacker] developed a crack that exploited that now famous kernel flaw and found his way into a Debian developer's machine. [...] this PC presented a means to accessing the Debian servers. [The attacker] installed the requisite tools that took over the machine and sniffed out the passwords. The attacker then obtained the password that enabled him to compromise a Debian project server. In quick succession, he penetrated a number of machines which spanned North-America and Europe." [4]https://github.com/virt-manager/virt-manager/issues/343 [5]https://libreplanet.org/wiki/Group:Software/FSDG_distributions/CrossDistroBootstrap