Programme cfs_adduser : Permettre à un utilisateur déjà présent d'ajouter un utilisateur externe au FS

Pour le moment, un seul utilisateur est ajouté au coffre à clés (lors du formatage).

Or, le système de fichiers peut gérer beaucoup d'utilisateurs avec son "double système" de clés symétriques (pour le chiffrement du système de fichiers) et asymétriques (pour le chiffrement de l'unique clé symétrique par plusieurs utilisateurs).

Paramètre du programme

Créer un programme qui prend en paramètre :

• La clé privée de l'utilisateur déjà présent dans le le coffre à clés.
• La clé publique de l'utilisateur à ajouter.

Ce que doit faire le programme

Le programme cfs_adduser doit (en gros) :

1. Trouver la clé publique dans le keys storage du FS, qui correspond à la clé privée rentrée en paramètre

Vous devez utiliser la fonction find_rsa_matching_key().

2. Déchiffrer, avec clé privée entrée en paramètre, la clé AES stockée dans le champ aes_key_ciphered de la structure du coffre de clés (à l'index trouvé à l'étape 1).
3. Trouver un emplacement libre dans le coffre de clés.
4. Si tous les emplacements sont occupés, renvoyer une erreur signifiant qu'il n'y a plus de place pour un utilisateur supplémentaire.
5. Chiffrer la clé AES (déchiffrée à l'étape 2) avec la clé publique passée en paramètre et la stocker dans l'emplacement libre (étape 3) et placer la clé publique passée en paramètre dans cet emplacement.

Bien évidemment...

Je ne décris ici que les grandes lignes du programmes, vous devez bien sûr vérifier que toutes les données que vous recevez sont cohérentes, qu'elles existent, ...

• Vérification de l'existence, de la validité et de la compatibilité avec l'image à monter.
• Implémenter le déchiffrement "par phrase de passe" de la clé privée RSA.

Utiliser la fonction rsa_private_is_encrypted()

• Choisir une manière de passer la clé en paramètre

Le chemin ? La clé directement ?

• Vérifier si le périphérique existe, est formaté en CryptFS, ...
• Vérifier si le point de montage existe.

Objectif

Permettre à terme d'accéder à un hash stocké en mémoire de l'image, ce qui permettrait de vérifier la validité d'une clé de déchiffrement.

Pistes

Regarder ce qu'on peut faire depuis une structure super_block, entre l'appel de la fonction mount_nodev (init) et l'appel de la fonction fs_fill_sb (post init)

Possibilité de se connecter via telnet en local sur QEMU pour transmettre des commandes à la VM Ubuntu.

Objectif

Montrer qu'il est possible de surcharger les appels systèmes read(), write(), open() et close().

Proof of Concept

Le but du PoC est tout simplement d'afficher un log système avec marqué coucou à chaque appel de read(), write(), open() et close().

Difficulté

Il faut s'assurer que le wrapper assure, en plus du service que nous créons, sa fonction initiale.

Ainsi, les logiciels tels que vim ou echo doivent fonctionner à l'identique après la mise en place du PoC.

Naturellement, cela ne sera plus exactement le cas quand nous y aurons intégré des fonctions de chiffrement/déchiffrement.

Problème

Comme vous pouvez le remarquer, j'ai utiliser la mnémonique include dans mes Makefiles (cf le commit e71eb40).

Cela est pratique, car je peux stocker des paramètres dans le fichier global.mk.

Or quand je fais une inclusion dans module/Makefile et que je lance make modules, il est impossible de compiler.

Précaution

Pour le moment, j'ai enlevé l'inclusion et ai rentré les valeurs à la main comme avant.

Objectif

Remettre include ../global.mk dans module/Makefile ET faire compiler le module correctement.

Objectif

Nous avons jusqu'ici réalisé un environnement de test assez complet.

Afin qu'il soit utilisable par un utilisateur quelconque ou modifiable par un développeur externe au projet, nous devons documenter l'intégralité de cet environnement.

Le but de la documentation en question est donc :

• De permettre à n'importe qui de lancer l'environnement de test.
• De permettre à n'importe quelle personne un peu technique de comprendre comment l'environnement est construit.

Wiki GitHub

La documentation se fera dans une page appropriée dans la section Wiki de GitHub.

Points à documenter

Tâches des Makefile's

L'objectif est de détailler chaque tâche présente dans les Makefiles :

• vm/Makefile,
• module/Makefile,
• vm/system/Makeifle,
• Makefile.

Si, pendant la phase de documentation, vous vous rendez compte qu'une tâche n'est pas nécessaire ou qu'elle n'est pas bien configurée, n'hésitez pas à la corriger ou à la supprimer.

Afin de créer votre documentation plus aisément, vous pouvez vous aider de la pré-documentation issue de la PR #24.

Description technique de l'environnement de test

• À quoi sert chaque dépendance ?
• Comment l'architecture des Makefile's est-elle faite et pourquoi ?
• Pourquoi et comment le noyau linux est-il compilé par nos soins ?
• Pourquoi et comment une image système minimale est-elle créée ?
• Pourquoi et comment le module est-il compilé avec le noyau compilé précédemment ?
• Comment la machine virtuelle est-elle lancée ?
• Comment le kernel object est il envoyé sur la machine virtuelle ?
• Comment les fichiers de la dropzone sont-ils envoyés ?
• Où sont placés les différents éléments dans le système de fichiers de la machine virtuelle de test ?

Originally posted by @nathan-rabet in #18 (review)

https://github.com/nathan-rabet/linux-cryptFS-module/blob/fips/code/formater.c#L34

Cela devrait être ./formater <file> [password]

Pivotage de projet

Depuis l'issue #19, nous nous sommes rendus compte que l'interception des appels systèmes (sans recompilation du noyau linux) était impossible. L'interface KPROBE étant très limitée, elle ne nous permet que de faire des actions de debug et non des interceptions en environnement de production.

Nouveau projet : chiffrement de périphérique

Afin de rester en lien avec le précédent projet, nous avons décidé de garder notre idée de chiffrement, mais en nous limitant à ce qu'un module noyau gère mieux : à savoir un périphérique.

L'idée est donc de définir un/des périphérique(s) physiques ou virtuels et de chiffrer leur contenu. Un déchiffrement automatique et transparent pour l'utilisateur devra être effectué pendant l’exécution du système.

Bien évidement, si l'on regarde l’intérieur du périphérique en dehors du système qui procède au chiffrement/déchiffrement, le contenu devra être inintelligible.

Documentation : Simple, Basique ♪♪

Le but de cette seconde première étape est de se documenter sur :

• Comment il est possible de monter un périphérique physique (clé USB, disque externe, ...) ou un périphérique virtuel (dossier ~/home, ...),
• Comment modifier l’interfaçage avec ces périphériques (typiquement, comment déchiffrer la liste des fichiers du périphérique lorsque l'utilisateur effectue un ls ou comment modifier l'affichage d'un contenu d'un fichier du périphérique quand l’utilisateur effectue un cat),
• Les fonctions Linux permettant de faire du chiffrement/déchiffrement.

Documentation++

Si vous trouvez d'autres informations intéressantes que je n'ai pas mentionné dans la section précédente, n'hésitez pas à en faire part dans l'espace commentaire.

Projet cryptFS (+ driver Linux)

Le but du projet est à présent de créer un système de fichiers chiffré qui sera déchiffré à l’exécution si l'utilisateur est autorisé (s'il fournit le bon mot de passe ou s'il possède la bonne clé publique) par un module kernel.

Partie 1 : Système de fichiers chiffré cryptFS

L'idée est donc de réfléchir à un système de fichier (comme FAT32, NTFS ou AFS) permettant de stocker des informations de types "fichiers" et "dossiers", de la même façon que sur les systèmes de fichiers usuels, à la seule différence que ces fichiers seront chiffrés à l'écriture et déchiffrés à la lecture (par notre module kernel).

Il faut donc réfléchir à une structure de données permettant d'assurer cela.

Idée 1 : système à clés symétriques

Une première idée serait de réfléchir à un système à clés symétriques, l'utilisateur pourrait donc rentrer un mot de passe via un programme tier, qui, si le mot de passe est correct, va monter notre système de fichier pour qu'il soit accessible à l'utilisateur.

Idée 2 : système à clés asymétriques

Dans cette seconde idée, on pourrait imaginer un système RSA-like où des clés publiques stockées dans le système de fichiers seraient liés à l'authentification d'un ou plusieurs utilisateurs, ce qui permettrait à un utilisateur de déchiffrer le système de fichier avec sa clé privée (le mot de passe de la session pourrait par exemple servir de clé privée).

WARNING : REGARDER ce que propose Linux en terme de chiffrement

Cela parait évident... mais cela serait bête de penser à tout un système symétrique (ou asymétrique) si Linux n'offre que des fonctions de chiffrement asymétrique (ou symétrique)

ANTI-WARNING : re-développer un système de chiffrement

C'est un peu overkill mais j'en parle quand même, car si les fonctions de Linux ne nous permettent pas de faire ce que nous voulons, nous devrons de toute façon refaire des fonctions de chiffrement (ce que je ne souhaite pas).

Partie 2 : Module kernel de liaison cryptFS <=> Linux Filesystem

Notre module lui devra être capable de gérer l'écriture (chiffrer) et la lecture (déchiffrer) quand notre système de fichiers sera monté.

Partie 3 : Programme tier permettant de monter notre système de fichiers

Ce programme serait un équivalent du programme mount et devra demander à l'utilisateur les informations nécessaire pour monter le système de fichier.

Ce programme pourrait ne pas exister si l'on décide d'utiliser un système de chiffrement asymétrique (avec les clés liées aux authentifications des utilisateurs).

Objectif

Après avoir réalisé un PoC prouvant la possibilité d'intercepter un appel système (cf issue #13), nous savons qu'il est possible d'y exécuter des tâches avant et après. Nous savons aussi qu'il est possible d'arrêter la pré-tâche en renvoyant une erreur (code de retour différent de 0), ce qui engendre la non-exécution de l'appel système en question.

Les questions qui se posent maintenant sont :

• Est-il possible d'envoyer une valeur de retour (qui n'est pas une erreur et créée par nos soins) avant que l'appel système ne s'exécute ?
• Est-il possible d’interagir avec les variables passées en paramètre de l'appel système ?

PoC : modification du syscall read(2)

La manuel n°2 défini read() comme ceci :

ssize_t read(int fd, void *buf, size_t count);

Dans ce PoC nous allons tester 2 choses :

1. La modification de la valeur renvoyée (ici nous allons altérer la valeur du ssize_t)
2. L'accès aux variables passées en paramètre (ici nous allons écrire dans le tampon buf)

TODO

Il est attendu la chose suivante :

Lors d'un appel à read(), si fd $=-42$ et buf $\ne NULL$

Alors on doit écrire dans le buffer buf la chaîne de caractère "coucou".

Bien évidement, buf doit être de taille $7$ au minimum (strlen("coucou") + sizeof(\0))

La valeur ssize_t renvoyée par read() doit être $6$

Attention au collisions

La valeur de test fd $=-42$ a été choisi aléatoirement pour éviter les collisions avec les applications qui utilisent read(2) lors de l’exécution du PoC (je pars du principe qu'aucune application utilise $-42$ comme valeur pour fd)

Cependant, si la valeur $-42$ rentre en collision avec d'autres applications et engendre le crash du système hôte (42 c'est un magic number connu tout de même), merci de la changer par -69 par un autre nombre.

Lors du demarrage de la VM, systemctl nous renvoie cette information

You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.
Press Enter for maintenance
(or press Control-D to continue):

Voici les logs du systeme Debian.

Welcome to Debian GNU/Linux 10 (buster)!

[   17.045313] systemd[1]: Set hostname to <reflexion>.
[   17.218255] random: crng init done
[   17.284656] selinuxenabled (83) used greatest stack depth: 26840 bytes left
[   17.623384] grep (85) used greatest stack depth: 26000 bytes left
[   17.954871] systemd[1]: File /lib/systemd/system/systemd-journald.service:12 c.
[   17.977618] systemd[1]: Proceeding WITHOUT firewalling in effect! (This warnin)
[   18.562443] systemd[1]: Listening on Journal Socket (/dev/log).
[  OK  ] Listening on Journal Socket (/dev/log).
[   18.597001] systemd[1]: Created slice system-getty.slice.
[  OK  ] Created slice system-getty.slice.
[   18.604710] systemd[1]: Reached target Swap.
[  OK  ] Reached target Swap.
[   18.613858] systemd[1]: Listening on Syslog Socket.
[  OK  ] Listening on Syslog Socket.
[  OK  ] Listening on udev Control Socket.
[  OK  ] Created slice system-serial\x2dgetty.slice.
[  OK  ] Listening on Journal Socket.
         Mounting /sys/kernel/debug...
         Mounting /sys/kernel/config...
         Mounting Huge Pages File System...
         Starting Remount Root and Kernel File Systems...
[  OK  ] Reached target Slices.
[  OK  ] Listening on initctl Compatibility Named Pipe.
[  OK  ] Listening on udev Kernel Socket.
         Starting udev Coldplug all Devices...
         Starting Load Kernel Modules...
[  OK  ] Started Dispatch Password …ts to Console Directory Watch.
         Mounting POSIX Message Queue File System...
[  OK  ] Reached target Remote File Systems.
[  OK  ] Started Forward Password R…uests to Wall Directory Watch.
[  OK  ] Reached target Local Encrypted Volumes.
[   19.126528] EXT4-fs (sda): re-mounted. Opts: (null). Quota mode: none.
[  OK  ] Reached target Paths.
[   19.167875] audit: type=1400 audit(1653522479.168:3): avc:  denied  { audit_re1
[  OK  ] Listening on Journal Audit Socket.
[  OK  ] Reached target Sockets.
         Starting Journal Service...
[  OK  ] Set up automount Arbitrary…s File System Automount Point.
         Mounting /proc/sys/fs/binfmt_misc...
[  OK  ] Mounted /sys/kernel/debug.
[FAILED] Failed to mount /sys/kernel/config.
See 'systemctl status sys-kernel-config.mount' for details.
[DEPEND] Dependency failed for Local File Systems.
[DEPEND] Dependency failed for Mark… need to relabel after reboot.
[  OK  ] Mounted Huge Pages File System.
[FAILED] Failed to start Remount Root and Kernel File Systems.
See 'systemctl status systemd-remount-fs.service' for details.
[  OK  ] Started Load Kernel Modules.
[  OK  ] Mounted POSIX Message Queue File System.
[  OK  ] Mounted /proc/sys/fs/binfmt_misc.
[  OK  ] Stopped Dispatch Password …ts to Console Directory Watch.
[  OK  ] Reached target Timers.
[  OK  ] Closed Syslog Socket.
[  OK  ] Reached target Login Prompts.
[  OK  ] Stopped Forward Password R…uests to Wall Directory Watch.
[  OK  ] Started Emergency Shell.
[  OK  ] Reached target Emergency Mode.
         Starting Create System Users...
         Starting Apply Kernel Variables...
         Starting Load/Save Random Seed...
[  OK  ] Started Apply Kernel Variables.
[  OK  ] Started Create System Users.
         Starting Create Static Device Nodes in /dev...
[  OK  ] Started Load/Save Random Seed.
[  OK  ] Started Create Static Device Nodes in /dev.
         Starting udev Kernel Device Manager...
[  OK  ] Reached target Local File Systems (Pre).
[  OK  ] Started Journal Service.
         Starting Flush Journal to Persistent Storage...
[   20.768892] audit: type=1107 audit(1653522480.778:4): pid=1 uid=0 auid=42949671
[   20.768892]  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal'
[   20.822238] systemd-journald[103]: Received request to flush runtime journal f1
[  OK  ] Started Flush Journal to Persistent Storage.
         Starting Create Volatile Files and Directories...
[  OK  ] Started udev Kernel Device Manager.
[  OK  ] Started Create Volatile Files and Directories.
         Starting Update UTMP about System Boot/Shutdown...
         Starting Network Time Synchronization...
[  OK  ] Started Update UTMP about System Boot/Shutdown.
         Starting Update UTMP about System Runlevel Changes...
[  OK  ] Started udev Coldplug all Devices.
[  OK  ] Started Network Time Synchronization.
[   23.943405] audit: type=1107 audit(1653522483.952:5): pid=1 uid=0 auid=42949671
[   23.943405]  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal'
[  OK  ] Started Update UTMP about System Runlevel Changes.

C'est les vacances la SUMMER SCHOOL

Les gars on va à l'étranger pendant 1 mois... donc svp profitez de votre séjour et on reprendra ce projet après.

Il est donc interdit de faire des commits et ce jusqu'à début août !

Autorisation exceptionnelle pour faire des commits

Vous êtes autorisé à faire des commits uniquement si :

• Vous n'avez pas de soirée de prévue
• Vous n'avez rien de prévu
• Vraiment vraiment RIEN d'autre à faire !

Chaque commit ne respectant pas ses 3 règles sera sévèrement sanctionné.

Cordialement la direction.

Objectif

Rajouter les attributs de configuration réseau et de connexion ssh dans la fonction de création de la VM qemu

Aujourd'hui, make dependencies installe les paquets de dépendances via le gestionnaire de paquets APT.
Le but de cette issue est d'améliorer le Makefile afin de permettre d’exécuter make dependencies sur d'autres systèmes (qui possèdent un autre gestionnaire de paquets, comme pacman)

Un exemple de système à rendre compatible est Arch Linux

https://github.com/nathan-rabet/linux-cryptFS-module/blob/fips/code/core/security/crypto_disk.c#L13-L14

• regarder comment stocker ses variables dans des fichiers NON accessibles en userland

C'est pas que je veux flex le fait de faire un kernel module de qualité mais si un peu quand même
En plus va y avoir de l'asm dedans donc voilà voilà

pls open or else

Problème

/home/runner/work/linux-cryptFS-module/linux-cryptFS-module/tests/criterion/crypto_disk_test.c:25:18: error: implicit declaration of function ‘EVP_PKEY_eq’; did you mean ‘EVP_PKEY_new’? [-Werror=implicit-function-declaration]
   25 |     cr_assert_eq(EVP_PKEY_eq(rsa_keypair, rsa_keypair_loaded), 1);
      |                  ^~~~~~~~~~~

Comme vous pouvez le voir dans cette sortie de journal de la CI, la machine virtuelle n'arrive pas à compiler le projet, plus précisement la partie OpenSSL.

Malgré le fait que les paquets openssl et libssl-dev soient installés..

Stocker les données globales du FS en RAM

Mettre en place des structures/fonctions pouvant permettre au processus FUSE de lire les données importantes du FS depuis n'importe quelle fonction (readdir(), mkdir(), ...).

Assurer la sécurité/segmentation de ces données

Exemple de données sensibles à mettre en RAM (variables globales)

• La clé AES
• Le chemin/la donnée de la clé RSA

A noter que les données sensibles ne devront JAMAIS être écrites dans des journaux ou être partagés avec d'autres processus

Par exemple : si un char * est renvoyé par un appel système, s'assurer qu'il n'y a aucune donnée sensible derrière le buffer

Exemple de données non-sensibles à mettre en RAM (variables globales)

• La taille d'un bloc
• ...

struct fuse_operations {
	int (*getattr) (const char *, struct stat *);
	int (*readlink) (const char *, char *, size_t);
	int (*getdir) (const char *, fuse_dirh_t, fuse_dirfil_t);
	int (*mknod) (const char *, mode_t, dev_t);
	int (*mkdir) (const char *, mode_t);
	int (*unlink) (const char *);
	int (*rmdir) (const char *);
	int (*symlink) (const char *, const char *);
	int (*rename) (const char *, const char *);
	int (*link) (const char *, const char *);
	int (*chmod) (const char *, mode_t);
	int (*chown) (const char *, uid_t, gid_t);
	int (*truncate) (const char *, off_t);
	int (*utime) (const char *, struct utimbuf *);
	int (*open) (const char *, struct fuse_file_info *);
	int (*read) (const char *, char *, size_t, off_t,
		     struct fuse_file_info *);
	int (*write) (const char *, const char *, size_t, off_t,
		      struct fuse_file_info *);
	int (*statfs) (const char *, struct statvfs *);
	int (*flush) (const char *, struct fuse_file_info *);
	int (*release) (const char *, struct fuse_file_info *);
	int (*fsync) (const char *, int, struct fuse_file_info *);
	int (*setxattr) (const char *, const char *, const char *, size_t, int);
	int (*getxattr) (const char *, const char *, char *, size_t);
	int (*listxattr) (const char *, char *, size_t);
	int (*removexattr) (const char *, const char *);
	int (*opendir) (const char *, struct fuse_file_info *);
	int (*readdir) (const char *, void *, fuse_fill_dir_t, off_t,
			struct fuse_file_info *);
	int (*releasedir) (const char *, struct fuse_file_info *);
	int (*fsyncdir) (const char *, int, struct fuse_file_info *);
	void *(*init) (struct fuse_conn_info *conn);
	void (*destroy) (void *);
	int (*access) (const char *, int);
	int (*create) (const char *, mode_t, struct fuse_file_info *);
	int (*ftruncate) (const char *, off_t, struct fuse_file_info *);
	int (*fgetattr) (const char *, struct stat *, struct fuse_file_info *);
	int (*lock) (const char *, struct fuse_file_info *, int cmd,
		     struct flock *);
	int (*utimens) (const char *, const struct timespec tv[2]);
	int (*bmap) (const char *, size_t blocksize, uint64_t *idx);
	int (*ioctl) (const char *, int cmd, void *arg,
		      struct fuse_file_info *, unsigned int flags, void *data);
	int (*poll) (const char *, struct fuse_file_info *,
		     struct fuse_pollhandle *ph, unsigned *reventsp);
	int (*write_buf) (const char *, struct fuse_bufvec *buf, off_t off,
			  struct fuse_file_info *);
	int (*read_buf) (const char *, struct fuse_bufvec **bufp,
			 size_t size, off_t off, struct fuse_file_info *);
	int (*flock) (const char *, struct fuse_file_info *, int op);
	int (*fallocate) (const char *, int, off_t, off_t,
			  struct fuse_file_info *);
};

All the FUSE operations are not mandatory.

https://github.com/nathan-rabet/linux-cryptFS-module/blob/75496cb4b528ba7dcabd4efe31413b696f999ae7/include/fat.h#L21

Objectif

Permettre de stocker des données (et métadonnées) du module dans le système et interdire toute action de lecture, écriture et exécution à tous les processus et services en dehors de ceux du module.

Problème

Lors du formatage, les clés dans ~/.cryptfs/ sont réécrites systématiquement.

TODO

Demander à l'utilisateur lors du formatage s'il souhaite réécrire les clés déjà présentes ou s'il veut réutiliser les anciennes ?

L'option par défaut devra être réutiliser les anciennes.

Amélioration (facultatif)

Permettre de stocker (et donc de charger) plusieurs clés dans ~/.cryptfs/

Objectif

Créer de la journalisation et permettre de l'exporter afin de pouvoir l'analyser pour un potentiel débogage.

Mise en place d'un système de journalisation pour le module

Cela ne devrait pas être trop compliqué. Je conseille d'utiliser le système de journalisation du kernel linux (définitions des fonctions disponibles dans le fichier d'en-têtelinux/printk.h)

c.f. la journalisation des modules de Jules

Mise en place de KASAN

Mettre en place un KASAN (Kernel Address Sanitizer) pour permettre de détecter les fuites de mémoire, ainsi que les erreurs de segmentation du module.

KASAN est comme ASAN mais au niveau du kernel

Exportation des logs

Regarder comment exporter les logs de journalisation et les logs de KASAN hors de notre VM de test.

Le but de cette opération est de pouvoir analyser les logs sur notre système hôte afin de détecter et corriger des anomalies.