Le logiciel libre ownCloud est une solution de partage et de stockage des fichiers en mode web. Avec la profusion des plateformes commerciales de ce type (Google Drive, iCloud, Dropbox, etc.), l’accès web aux fichiers est devenu le nouveau standard. Dans cet article, nous allons explorer une méthode pour interfacer cette méthode d’accès aux fichiers avec un serveur NFS (Network File System) existant.
Introduction
L’accès aux fichiers par le Web est devenu le nouveau standard. Adossés à de massives plateformes de Cloud, ces services peuvent croître en fonction de l’usage. Il suffit aux utilisateurs de souscrire à l'abonnement correspondant à leurs besoins en termes d’espace de stockage. Ces systèmes s’appuient sur la propriété d’élasticité des environnements Cloud. Certains moteurs de gestion de fichiers en mode Cloud sont disponibles on-premise, c'est-à-dire avec une instance locale. Les deux principaux sont NextCloud et ownCloud. Cet article va se focaliser sur le second. Pour bien placer un logiciel comme ownCloud dans la galaxie des systèmes de fichiers, il convient de dessiner les catégories à gros traits. La première catégorie, la plus simple en termes de compréhension, mais pas forcément d’implémentation, recouvre les systèmes de fichiers strictement locaux. Ces systèmes sont instanciés directement sur les partitions. Chacun de ces systèmes de fichiers a des caractéristiques qui lui sont propres comme la présence ou l’absence de contrôle d’accès, la journalisation ou non, etc. On retrouve VFAT, NTFS, ext[2,3,4], XFS, etc. Au-dessus de ces systèmes de fichiers, on peut trouver des systèmes de distribution chargés de partager les données stockées sur ces systèmes locaux sur le réseau. On retrouve CIFS, DFS, NFSv[3,4], etc. Enfin, il existe des systèmes de fichiers plus complexes gérant nativement la réplication des données sur des volumes distribués, les snapshots et parfois même les écritures en parallèle sur fichiers. Il s’agit de Btrfs, Lustre, ZFS, etc. Dans cet article, le scénario est d’intégrer les répertoires personnels des utilisateurs partagés en NFS dans un partage Cloud ownCloud on-premise. Nous allons commencer en présentant les spécificités de NFS pertinentes pour notre méthode. Ensuite, nous discuterons de l’installation basique d’ownCloud. Dans la section suivante, nous présenterons la passerelle entre ownCloud et le service NFS. Enfin, nous paramétrons ownCloud pour tirer avantage de cette passerelle dans l’objectif de mettre à disposition de l’utilisateur ses fichiers personnels du NFS dans son espace ownCloud.
1. Usage de NFS
Pour bien comprendre la problématique, il est nécessaire de présenter le cadre de l’utilisation du partage NFS. Ce partage est utilisé pour un centre de calcul. Basiquement, un centre de calcul est un ensemble de machines (ou nœuds) sur lesquelles on exécute des codes de calcul parallèles distribués (ou non). Distribué signifie que plusieurs machines peuvent travailler de concert à l'exécution du code. Ce code est situé dans le répertoire de l’utilisateur. En conséquence, ce répertoire doit être partagé entre tous les nœuds du centre de calcul. L’installation d’un serveur NFS est très simple et documentée partout sur Internet. Nous nous focaliserons sur les aspects de configuration qui nous concernent. Tout d’abord, il faut comprendre comment c’est fait côté serveur de fichiers mettant ces répertoires utilisateurs à disposition. Nous avons un serveur nommé « filer » qui fait tourner le serveur NFS nfsd. Cette machine a un volume de stockage. Regardons quelle partition est disponible.
Les données sont situées sur un volume logique LVM (Logical Volume Manager). Pour faire simple, c'est un système de gestion des partitions permettant de les retailler à chaud et de créer des snapshots. Cet article fait un point complet sur la sécurisation des données via le couple LVM / RAID [1]. Nous avons instancié un système de fichier XFS (Extended File System) dessus. Ce volume est monté dans le répertoire /nfsvol du serveur de fichiers :
Vérifions le système de fichiers instancié sur ce volume :
Il s’agit de XFS. Entre toutes les propriétés de ce système de fichiers, celle qui va nous intéresser pour l’explication est que ce système de fichiers supporte le contrôle d’accès discrétionnaire ou DAC (Discretionary Access Control). Ce contrôle d’accès est simple, il se base essentiellement sur l’UID (User IDentifier) de l’utilisateur qui est l’identifiant numérique qu’il acquiert suite à son authentification. C’est cet identifiant qui est utilisé par le noyau au moment du contrôle d’accès à un fichier. C’est important pour la suite de l’article. Le point de montage /nfsvol de ce volume est partagé sur le réseau via NFS. Ça se passe dans le fichier /etc/exports :
On définit un répertoire parent de partage /nfsvol et un sous-répertoire homes correspondant aux répertoires utilisateurs. Ce partage NFS est accessible sur le réseau 172.16.0.0/19 qui est privé, dédié au calcul et coupé du réseau interne de l’université (l’accès aux nœuds se fait via un frontal). L’authentification des machines clientes habilitées à monter le partage NFS se fait donc sur leur IP. C’est valide pour un réseau fermé, mais il faut le tenir loin d’un réseau ouvert tel qu’Internet. De plus, une fois le partage monté sur le client, le contrôle d’accès au partage se fait par l’UID. Le problème est que NFS fait confiance à un UID positionné par le client. Si un client est compromis et que le pirate arrive à obtenir les droits administrateur suite à une élévation de privilèges, alors il a accès à tous les fichiers. En effet, il peut créer des utilisateurs bidons recouvrant les UID des propriétaires des fichiers partagés. Ce risque est d'autant plus élevé si l’option no_root_squash est activée. Par défaut, si cette option est absente, NFS convertit l’UID 0 (root) en 65534 (nobody). Si l’option est activée, root conserve son UID 0 lors de l’accès au partage. L’idée est de créer une passerelle pour pouvoir mettre à disposition les fichiers du partage NFS à la machine ownCloud. Nous allons maintenant passer à la configuration de la passerelle.
2. Configuration d’une passerelle
Cette passerelle va se positionner entre mon serveur ownCloud, frontal d’accès pour les utilisateurs au service de partage de fichiers sur Internet, et le partage NFS. Cette passerelle va d’une part monter le partage NFS des répertoires utilisateurs et d’autre part les repartager en SFTP (SSH File Transfer Protocol). SFTP est une extension du protocole SSH gérant l’accès aux fichiers. On profite donc des nombreux mécanismes de sécurité concernant l'authentification et l’autorisation proposés par SSH. Nous utiliserons l’implémentation OpenSSH du protocole SFTP.
2.1 Montage NFS
Commençons par le plus simple, monter le partage NFS sur la passerelle (que nous avons nommée sftp). Nous allons installer les outils clients NFS :
Puis nous allons créer deux scripts de démarrage. Le premier n’est pas obligatoire selon votre installation, mais peut s’avérer utile dans certaines configurations de démarrage. En effet, selon les services démarrés par votre machine, il peut arriver que le montage NFS se lance avant que la résolution de nom soit valide (true story). Ce premier script va donc attendre que le serveur NFS soit solvable en DNS :
Ce script de démarrage fait des résolutions en boucle du FQDN filer.calcul.univ-paris13.fr. Chaque résolution infructueuse est suivie d’une attente de deux secondes. Une fois la résolution réussie, on sort de la boucle et le script s’arrête. Le second script réalise le montage NFS des répertoires utilisateurs :
Ce script démarre après le précédent (Wants, After wait-for-nfs-server.service) et monte le partage homes de filer.calcul.univ-paris13.fr dans le répertoire /nfs/homes. Les utilisateurs sont définis dans un annuaire LDAP [2]. Leur répertoire utilisateur est /nfs/homes/<identifiant>. Nous prendrons comme postulat que la partie LDAP est configurée et donc que les utilisateurs sont connus sur la passerelle. Nous allons activer ces deux scripts au démarrage et les lancer :
2.2 Accès SFTP
Configurons maintenant l’accès en SFTP aux fichiers. La sécurité de l’accès va s’appuyer sur deux mécanismes : authentification par clés SSH et le confinement de l’utilisateur dans l'emplacement des répertoires personnels pour l’autorisation. L’authentification par clés repose sur la cryptographie asymétrique. L’utilisateur génère une bi-clé privée et publique. La clé privée reste dans la poche de l’utilisateur tandis que la clé publique est amenée à être distribuée au monde entier. Vous trouverez ici [3] un guide complet du client OpenSSH, notamment l’utilisation des clés. Pour faire simple, l’utilisateur installe sa clé publique sur le compte distant qu’il souhaite connecter en SSH. Par la suite, en présentant sa clé privée au serveur, il pourra s’authentifier sur son compte distant localisé sur cette machine. Nous reviendrons ensuite sur l’installation de la clé publique dans le compte utilisateur dans la section dédiée à ownCloud. Passons au confinement de l’utilisateur lors de l’utilisation de son partage.
L’idée est de s’appuyer sur la capacité d’OpenSSH à confiner les connexions des utilisateurs dans un répertoire (ici la racine des répertoires personnels). Le problème de confinement de processus est traité ici [4]. Nous ne rappellerons que les notions clés. Ce confinement s’appuie sur l’utilisation de l’appel système chroot(). Cet appel système change l’attribut de racine (au niveau système de fichiers) du processus invocateur. En conséquence, le processus ne verra pas les répertoires au-dessus de sa nouvelle racine. Pour que ce confinement soit efficace d’un point de vue sécurité, il est essentiel qu’en complément le processus s'exécute avec une identité non privilégiée. Ça tombe bien, c’est exactement ce que fait le serveur OpenSSH. Lorsqu’un utilisateur se connecte, le processus qui l'accueille transite vers son identité. La configuration d’un tel accès se passe dans le fichier /etc/ssh/sshd_config :
Nous pouvons voir qu’une directive Subsystem est commentée au profit d’une autre. Nous faisons donc le choix d’utiliser le serveur SFTP interne de OpenSSH plutôt que le programme externe sftp-server. La différence entre les deux est que le serveur interne est intégré à l'exécutable sshd. En conséquence, il n’a aucune dépendance ce qui rend son confinement très simple, car il n’y a pas de problématique de librairies ou fichiers externes à gérer. A contrario, le serveur externe propose plus d’options, mais c’est un programme indépendant invoqué par sshd lorsque l’utilisateur se connecte en SFTP. La gestion de ses dépendances pour le confinement est plus compliquée.
La section « Match » qui suit s’applique à tous les utilisateurs qui se connectent excepté root (*,!root). Pour ces utilisateurs, nous excluons la redirection X11 permettant d'exécuter des programmes distants avec un rendu graphique local (X11Forwarding no). Nous excluons également les possibilités de tunnel (AllowTcpForwarding no). Enfin, on confine la connexion à la racine des répertoires personnels (ChrootDirectory /nfs/homes) en forçant l'exécution du serveur SFTP interne à l’ouverture de session (ForceCommand internal-sftp). Le lecteur attentif pourra se demander pourquoi on confine dans la racine des répertoires utilisateurs et pas dans le répertoire utilisateur lui-même. La raison est que sshd refuse de confiner une session dans un répertoire offrant un droit d’écriture à un utilisateur non privilégié ce qui est la raison d’être d’un répertoire utilisateur. C’est un compromis avec l’usage, ce qui est l’essence de la sécurité informatique.
3. Notes sur l’installation d’ownCloud
Nous n’allons pas entrer dans les détails de la configuration d’ownCloud. Nous n’avons fait que suivre la documentation officielle. La seule difficulté est de séquencer correctement les actions. Tout d’abord, il va vous falloir un serveur MariaDB opérationnel. Vous pourrez l’installer avec les prérequis d’ownCloud en suivant cette documentation [5]. Ensuite, il faut un serveur web. Idem, la documentation officielle donne tous les éléments [6]. Cependant, les directives à mettre dans le fichier sont un peu éparses dans la documentation. Pour faciliter le travail du lecteur, nous donnons le fichier du site in-extenso (évidemment à adapter à votre configuration).
Notamment la partie SSL n’est pas très bien détaillée dans la documentation. Si vous souhaitez plus de détails sur les directives SSL du fichier, vous pouvez vous référer à cette documentation [6]. Une fois la base de données et le serveur web déployés, il ne reste plus que l’archive d’ownCloud à décompresser [7]. Le seul complément à cette documentation est que lorsque le répertoire owncloud a été déplacé dans /var/www, il faut bien penser à donner les droits à l’utilisateur du serveur web :
Normalement, une fois ces actions effectuées, lorsque vous allez avec votre navigateur sur l’URL de votre instance d’ownCloud vous devriez tomber sur l’interface de configuration initiale [8]. Cette étape consiste essentiellement à renseigner les détails de connexion à la base de données ainsi que le répertoire où seront stockés les fichiers des utilisateurs. Attention, ici on ne parle pas du répertoire utilisateur au sens du répertoire personnel porté par le partage NFS, mais d’un répertoire dédié à l’utilisateur par ownCloud. C’est depuis ce répertoire ownCloud que nous allons faire un lien vers le répertoire utilisateur partagé par NFS. Pour les utilisateurs, nous partons du principe que vous avez un LDAP fonctionnel [2] et que vous allez y connecter votre instance d’ownCloud [9]. Cependant, dans la section suivante, nous allons amender la configuration du LDAP.
4. Gestion des utilisateurs ownCloud
Nous ne souhaitons pas donner un accès ownCloud à tous les utilisateurs du LDAP. Nous allons utiliser l’overlay « memberOf ». Lorsque l’on utilise cet overlay, on crée des objets « groupOfNames » qui possèdent un attribut multi-instancible « member ». Cet attribut prend comme valeur le DN d’un utilisateur. Lorsque l’utilisateur est ajouté, il se voit ajouter dynamiquement un attribut « memberOf ». Commençons par regarder si le module est défini dans la configuration de l’annuaire :
Il ne l’est pas, ajoutons-le via un fichier memberof-enable.ldif :
Modifions la configuration des modules de l’annuaire :
Vérifions que le module est chargé :
Nous pouvons maintenant ajouter le groupe « drivegroup » dédié à l’utilisation de notre instance d’ownCloud. Créons un fichier LDIF contenant ce nouveau groupe :
Ajoutons le groupe dans la base de données de l’annuaire :
Vérifions que l’utilisateur est bien dans le groupe :
Enfin, nous allons connecter notre ownCloud au partage NFS.
5. Connexion d’ownCloud à la passerelle SFTP
Avant tout, il faut se connecter en administrateur sur la plateforme ownCloud. Pour vérifier que ce module est installé, allez en haut à gauche sur votre identifiant puis Paramètres. Dans la figure 1, on voit à gauche le menu Applications et une fois dans ce menu on active External Storage Support.
Une fois cette extension installée, vous pouvez aller dans Stockage sur la gauche de l’interface comme illustré dans la figure 2. Puis activer Autoriser les utilisateurs à monter des espaces de stockage externes et plus spécifiquement SFTP. La dernière option à activer est optionnelle dans notre méthode. Elle permet de faire des partages de fichiers depuis un stockage externe via des liens ou par groupes. Nous l’avons activée, car c’est pratique pour les chercheurs afin de partager leurs expérimentations avec leurs collègues.
Connectons-nous en simple utilisateur pour créer le montage externe connecté au répertoire utilisateur partagé en NFS. Allons en haut à gauche sur votre identifiant puis sur Paramètres. À gauche, un item Stockage est apparu qui ouvre sur le menu en figure 3.
La première colonne renseigne le nom du partage externe pointant sur le dossier personnel partagé par NFS et repartagé en SFTP par la passerelle. La colonne suivante renseigne sur le protocole utilisé par le stockage externe. Ici, il s’agit de SFTP. Pour l’authentification, on choisit Clé publique RSA (mais mot de passe fonctionne également, il faudra seulement s’authentifier interactivement à chaque accès) qui est basiquement une authentification SSH par clé. Enfin, on a le quadruplé Configuration avec respectivement le nom de la machine à connecter (sftp.calcul.univ-paris13.fr), le répertoire à monter dans le stockage externe (attention, ce répertoire est relatif au chroot(), donc /nicolas.greneche pour /nfs/homes/nicolas.greneche), l’identifiant (nicolas.greneche) et enfin la partie publique d’une clé SSH générée par ownCloud. Cette clé devra être installée dans le répertoire utilisateur partagé en NFS conformément à la documentation [3].
Une fois la configuration terminée, la loupiotte à gauche passe au vert et retournant sur votre écran d'accueil, vous devriez retrouver le dossier correspondant au montage externe comme dans la figure 4.
Quand vous cliquez dessus, vous devriez retrouver le contenu de votre répertoire personnel partagé en NFS et profiter pour celui-ci des facilitées offertes par ownCloud.
Conclusion
Dans cet article, nous avons proposé une méthode pour partager un répertoire utilisateur distribué en NFS via le stockage cloud en mode on-premise ownCloud. Nous nous sommes appuyés sur les capacités d’OpenSSH pour renforcer l’authentification en passant d’un accès discriminant sur l’IP à une clé SSH. Au niveau autorisation, l’utilisateur ne peut pas déborder sur le système de base, car sa connexion est confinée dans le répertoire des utilisateurs. Enfin, le préambule à toute manipulation du stockage externe est une authentification sur le portail ownCloud. Au niveau non-répudiation, nous sommes un niveau au-dessus de la discrimination sur l’IP offerte par NFS (sans Kerberos). Un concurrent d’ownCloud est nextCloud. Personnellement, je n’ai pas expérimenté cette solution très loin, car j’avais des déconnexions fréquentes avec l’annuaire LDAP. J’ai donc basculé sur ownCloud, car je n’avais que des besoins fichiers.
Références
[1] https://connect.ed-diamond.com/GNU-Linux-Magazine/glmf-210/securisez-vos-donnees-par-lvm-et-raid
[6] https://connect.ed-diamond.com/Linux-Pratique/lp-123/les-certificats-de-l-emission-a-la-revocation
[8] https://doc.owncloud.com/server/next/admin_manual/installation/installation_wizard.html
[9] https://doc.owncloud.com/server/next/admin_manual/configuration/user/user_auth_ldap.html
