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.

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