Une image RealmFS contient un système de fichiers racine pour une ou plusieurs instances de realm. Comme les images de ressources, les images RealmFS sont signées et montées avec dm-verity afin d’empêcher toute altération des données du système de fichiers racine, telle que l’installation de logiciels malveillants ou de portes dérobées. Les clés utilisées pour signer les images RealmFS sont contrôlées par l’utilisateur, ce qui permet de mettre à jour les logiciels et d’installer de nouveaux paquets sur l’image.
Les images RealmFS sont toujours montées en lecture seule et cette propriété est garantie par dm-verity. Comme les images RealmFS sont immuables, une même image peut être partagée entre plusieurs instances de realm en cours d’exécution. Par défaut, lorsqu’un realm est lancé, un overlay temporaire est ajouté au système de fichiers racine afin que des modifications puissent être effectuées ; elles ne dureront que jusqu’à l’arrêt ou au redémarrage du realm. Cela permet d’expérimenter avec la configuration du système ou d’installer temporairement de nouveaux logiciels. Le système de fichiers racine peut ensuite être ramené à son état d’origine en redémarrant simplement le realm.
Mises à jour
Le système de fichiers racine des realms étant stocké sur des images disque en lecture seule, les paquets ne peuvent pas être installés ou mis à jour de façon permanente de la manière habituelle. Les modifications du système de fichiers racine réussissent à l’intérieur d’un realm, mais elles sont perdues dès que le realm est arrêté ou redémarré.
Pour apporter des modifications permanentes à une image RealmFS, l’image est d’abord copiée, puis les modifications sont appliquées à la copie. Après application des modifications, un nouvel arbre de hachage dm-verity est généré pour l’image, et l’en-tête de l’image RealmFS est mis à jour et signé.
Note : Le processus consistant à générer une signature et un arbre de hachage dm-verity pour une image RealmFS après y avoir apporté des modifications, par exemple une mise à jour de paquets, est appelé scellage (Sealing) de l’image.
Realm Apt-Cacher NG
Au démarrage, un realm utilitaire système est lancé ; il exécute une instance d’Apt-Cacher NG. Chaque realm est configuré pour utiliser ce realm comme proxy pour l’installation des paquets.
/etc/apt/apt.conf.d/000apt-cacher-ng-proxy
Acquire::http::Proxy "http://172.17.0.213:3142/";
Les lignes de sources apt utilisent la syntaxe spéciale d’Apt-Cacher NG.
/etc/apt/sources.list
deb http://HTTPS///deb.debian.org/debian bullseye main contrib non-free
L’utilisation d’un cache de paquets évite de télécharger et de stocker plusieurs fois les mêmes paquets lors de la mise à jour de plusieurs images RealmFS. Cela permet aussi de télécharger et de mettre en cache des paquets pendant qu’on est connecté à un réseau, avant de redémarrer le système en mode sécurisé sans activer le réseau, afin d’effectuer les mises à jour des paquets des realms.
Mises à jour (méthode par conteneur)
L’image RealmFS est d’abord copiée vers un fichier temporaire. Sur un système de fichiers tel que btrfs, le fichier image sera cloné en reflink plutôt que copié. La copie du RealmFS est ensuite montée en mode inscriptible afin que des modifications puissent être apportées. Un conteneur systemd-nspawn est lancé et un shell root est ouvert, permettant à l’utilisateur de mettre à jour les paquets, d’installer de nouveaux logiciels ou d’effectuer toute autre modification du système de fichiers racine.
À la fermeture du shell, une invite demande à l’utilisateur s’il souhaite enregistrer les modifications actuelles ou les abandonner. Si l’utilisateur choisit de les enregistrer, la copie de l’image est ensuite scellée en générant un arbre de hachage dm-verity, et l’en-tête de l’image est signé avec la clé de scellage RealmFS de l’utilisateur.
Mises à jour avec l’hyperviseur pH
Lorsqu’un realm est lancé avec pH, l’overlay est géré par le périphérique disque émulé de l’hyperviseur, qui suit les modifications des blocs du disque et stocke les blocs modifiés en mémoire. Comme l’hyperviseur suit toutes les modifications du disque, il peut aussi appliquer les modifications de façon transparente, générer une nouvelle image RealmFS scellée, puis abandonner les blocs modifiés et passer directement à l’utilisation de la nouvelle image.
Ce processus est initié par l’utilisateur lorsqu’il décide de rendre permanentes, dans l’image RealmFS sous-jacente, les modifications qu’il a apportées au système de fichiers racine du realm en cours d’exécution.
- L’utilisateur apporte des modifications au système de fichiers racine du realm et pH suit les blocs qui ont changé.
- L’utilisateur demande à pH d’appliquer les modifications à l’image RealmFS.
- pH ouvre une invite sur le bureau pour demander à l’utilisateur de confirmer qu’il est bien à l’origine de cette demande.
- Une copie (ou reflink) du RealmFS actuel est effectuée, et pH applique les blocs modifiés à cette copie.
- La copie est ensuite scellée avec la clé RealmFS de l’utilisateur.
- pH peut alors remplacer discrètement la nouvelle version de l’image RealmFS et abandonner toutes les modifications de blocs qui étaient suivies.
Signature des images RealmFS
Une clé secrète destinée à la signature des images RealmFS est générée lors de l’installation et stockée sur le disque dans un fichier chiffré appelé User Keyring (porte-clés utilisateur). Pendant le démarrage, lorsque l’utilisateur saisit une phrase secrète pour déchiffrer le disque, cette même phrase sert également à déchiffrer le fichier du porte-clés, et la paire de clés publique/secrète est chargée dans le stockage de clés du noyau.
Il existe un risque qu’un attaquant parvenant à compromettre le noyau récupère cette clé secrète. Cela lui permettrait de modifier des images RealmFS scellées et d’installer des portes dérobées ou d’autres logiciels malveillants dans les systèmes de fichiers racine des realms. Même sans obtenir la clé de signature, un attaquant ayant compromis Citadel pourrait attendre que l’utilisateur effectue une mise à jour et effectuer des modifications malveillantes en même temps, que l’utilisateur signerait ensuite.
Pour ces raisons, il est également possible de configurer le système de sorte que seule la clé publique soit conservée dans le noyau au démarrage, l’utilisateur devant alors démarrer dans un mode spécial pour que la clé privée soit disponible afin d’effectuer les mises à jour.
Mode sécurisé
Si les mises à niveau sont effectuées en mode de fonctionnement normal, un attaquant ayant compromis citadel peut installer une porte dérobée permanente dans les images realmfs mises à niveau. Le mode sécurisé est une façon de démarrer citadel sans lancer aucun realm ni activer le périphérique réseau. Comme l’intégrité du système de fichiers racine de Citadel est garantie par dm-verity et qu’aucun realm n’est en cours d’exécution, même si le système avait été compromis à un moment donné dans le passé, on considère qu’il se trouve alors dans un état sûr pour effectuer des mises à jour et les signer avec les clés de scellage de l’utilisateur.
Le réseau n’étant pas disponible en mode sécurisé, les paquets à installer ou à mettre à niveau doivent être stockés quelque part. En effectuant les mises à jour de paquets avec l’option --download-only, ou en les installant sur l’overlay temporaire d’un realm, l’utilisateur fera en sorte qu’ils soient stockés sur le realm de service Apt-Cache NG, afin qu’ils soient disponibles pour l’installation en mode sécurisé.
Image RealmFS de base
Citadel est livré avec une image RealmFS nommée base-realmfs.img. Cette image n’a rien de particulier, si ce n’est qu’elle est initialement signée par Subgraph jusqu’à ce que l’utilisateur la modifie ou la mette à jour. Lors de l’installation, une copie de ce RealmFS est créée sous le nom main-realmfs.img et scellée avec les clés utilisateur nouvellement générées.