CageFS au quotidien dans l'hébergement : isolation des systèmes de fichiers entre les comptes clients

Pourquoi les comptes d'hébergement ont besoin d'isolation

Dans le cadre de l'hébergement mutualisé, plusieurs clients hébergent leurs sites web sur le même serveur. Si un script du compte A est compromis, il peut tenter de collecter des informations sur l'environnement et d'accéder aux fichiers d'autres comptes. Il peut s'agir notamment de fichiers de configuration contenant des identifiants ou des données personnelles. La séparation des comptes vise à compliquer ce type d'accès, même si l'infrastructure est partagée.

Il s'agit notamment de Visibilité et droits d'accès différentes questions. Un nom de répertoire peut être visible, même si l'accès à son contenu est refusé en raison des droits d'accès aux fichiers. À l'inverse, une vue restreinte ne suffit pas à elle seule à remplacer des droits soigneusement définis : ce qui est accessible au sein de l'environnement doit continuer à être protégé de manière appropriée.

CageFS ajoute aux autorisations un environnement de système de fichiers spécifique à l'utilisateur. Un processus s'exécutant dans le contexte prévu ne bénéficie pas simplement de la même vue sur l'hôte qu'un administrateur. Cela vise à empêcher qu'un script exécuté à partir du compte A puisse explorer sans autre les répertoires d'autres comptes. Les zones effectivement visibles dépendent de la configuration.

Pour les exploitants, cela représente une couche de séparation, aucune garantie quant à l'absence de répercussions sur d'autres clients. Des erreurs dans les services partagés, des autorisations trop larges ou une intégration incomplète des services peuvent affecter l'efficacité de la protection. C'est pourquoi l'isolation doit être vérifiée là où les programmes des clients sont effectivement exécutés, et non pas uniquement sur la base d'un paramètre dans l'interface d'administration.

Pour les clients de l'hébergement, cette distinction est également importante : le fait qu'une application ne puisse pas accéder à un répertoire tiers ne décrit, dans un premier temps, que son contexte d'exécution spécifique. Cela ne garantit ni la configuration de tous les services, ni la protection de tous les autres comptes. Le fournisseur reste responsable de la mise en place et du contrôle globaux.

Comment CageFS organise la vue du système de fichiers

CageFS offre aux utilisateurs une vue personnalisée du système de fichiers. Il repose sur le Squelette: un modèle contenant des fichiers et des répertoires mis à disposition pour l'environnement concerné. Les éléments nécessaires sont intégrés ; le répertoire personnel de l'utilisateur est également intégré à son environnement. L'arborescence visible n'est donc pas simplement une copie inchangée de la vue de l'hôte.

On peut illustrer cette intégration à l'aide d'un exemple concret : un administrateur installe un programme sur l'hôte, mais un processus client ne le trouve pas dans son environnement. Il ne s'agit pas nécessairement d'une erreur d'installation. Le programme peut être présent sur l'hôte sans pour autant être accessible au client via le squelette ou les intégrations prévues à cet effet.

À l'inverse, chaque fichier supplémentaire mis à disposition élargit l'environnement accessible à un processus. Il en va de même pour un répertoire monté. Les administrateurs doivent donc mettre en balance les besoins fonctionnels et la visibilité supplémentaire : une application peut avoir besoin d’un outil spécifique et de ses dépendances, mais pas nécessairement de tout un répertoire de l’hôte.

Le Configuration du montage Elle détermine quelles parties du système de fichiers apparaissent dans l'environnement. Elle ne décide toutefois pas à elle seule si un processus est autorisé à lire, modifier ou exécuter un fichier visible. La propriété et les droits d'accès, entre autres, restent déterminants à cet égard. Un chemin d'accès visible n'est donc pas synonyme d'un droit d'écriture autorisé.

Le répertoire personnel reste particulièrement important pour l'utilisation quotidienne de l'hébergement : c'est généralement là que se trouvent les fichiers du compte concerné. Cette intégration permet d'y accéder dans le contexte prévu, tandis que le reste de l'affichage est restreint. Cependant, la capacité d'une application donnée à accéder à tous les fichiers nécessaires dépend de sa configuration et des chemins d'accès effectivement disponibles.

CageFS, LVE et risques communs

CageFS et LVE répondent à des besoins différents. CageFS organise la vue du système de fichiers et le contexte d'exécution d'un utilisateur ; LVE sert à recenser et à limiter les ressources telles que le processeur, la mémoire et les opérations d'entrée-sortie. Un processus dont la visibilité sur le système de fichiers est restreinte peut néanmoins continuer à consommer des ressources. À l'inverse, une limite de ressources n'empêche pas en soi l'accès à des fichiers partagés de manière inappropriée.

Un panneau de contrôle d'hébergement remplit une autre fonction : il gère notamment les comptes et peut intégrer des composants CloudLinux. Cependant, la simple installation d'un panneau ne garantit pas que chaque processus Web, chaque shell et chaque tâche planifiée s'exécute dans le contexte CageFS prévu. Les opérateurs doivent vérifier que l'intégration est adaptée à leur plateforme spécifique.

CageFS ne consiste pas en une machine virtuelle distincte pour chaque compte. Les comptes continuent d'utiliser un noyau commun et peuvent dépendre de services exploités en commun. Une vulnérabilité ou une mauvaise configuration au sein de ces composants communs continue donc de faire partie du modèle de menace. L'isolation du système de fichiers réduit une partie de l'environnement visible, mais ne remplace pas la sécurisation et la maintenance de l'hôte.

Même au sein d'un compte correctement isolé, des risques subsistent. Une application vulnérable peut, par exemple, divulguer ses propres données ; des identifiants volés peuvent permettre à un pirate d'accéder au compte concerné. CageFS ne corrige ni le code d'application non sécurisé, ni les droits trop généreux sur les fichiers accessibles au sein de ce compte.

Pour mettre en place une stratégie de sécurité solide, il faut donc que les différentes couches s'articulent correctement : intégrer correctement les comptes et les services, contrôler les droits d'accès aux fichiers, choisir des limites de ressources adaptées et maintenir les applications à jour. L'efficacité de la protection qui en résulte dépend de la configuration réelle et des services exploités. Le nom d'un composant isolé ne remplace pas cette vérification.

Considérer les comptes et les sites web séparément

Deux comptes clients sur le même serveur ne constituent pas le même cas que deux sites web au sein d'un même compte. CageFS fournit un environnement spécifique à chaque utilisateur et limite ainsi la visibilité d'un compte sur le système de fichiers. Cela ne signifie toutefois pas que chaque site web au sein de ce compte dispose de ses propres limites au niveau du système de fichiers.

Si une agence gère plusieurs projets sous le même compte d'hébergement, ses applications peuvent, en fonction du contexte d'exécution et des autorisations, accéder aux fichiers d'autres projets. Si un pirate parvient à s'introduire dans un site web via un plugin vulnérable, il convient donc de vérifier quels fichiers de configuration et quelles données d'accès sont accessibles sous ce compte. La séparation par rapport à un deuxième compte client ne répond pas à cette question.

Pour une texture plus fine Séparation des sites web CloudLinux propose, avec CloudLinux Isolates, une isolation supplémentaire du système de fichiers au niveau du domaine. Sa disponibilité dépend de la disponibilité concrète du produit, de sa version et de son intégration au panneau de configuration. Vérifiez ces conditions préalables pour votre propre pile d'hébergement, plutôt que de conclure à une séparation des domaines uniquement sur la base de l'activation de CageFS.

Les limites LVE spécifiques à chaque domaine constituent également une fonctionnalité distincte, soumise à ses propres conditions. Une limite supplémentaire au niveau du système de fichiers ne signifie donc pas automatiquement que le CPU ou la mémoire sont limités séparément pour chaque domaine. L'article sur Isolation des sites CloudLinux accentue la distinction entre le niveau du compte et celui du site web ; les conditions requises par la variante de produit utilisée restent déterminantes pour la configuration.

Pour la planification, il est utile de commencer par dresser un état des lieux : quels sites partagent un même compte, quels fichiers doivent-ils partager et quelles données d'accès doivent rester distinctes ? Cela permet de déterminer si des comptes distincts ou une isolation par domaine sont adaptés au modèle d'exploitation. Ces deux variantes nécessitent une analyse des chemins d'accès réels aux applications.

Vérifier le statut de Pilot et de CageFS

Avant de lancer un projet pilote, vous devez, en tant qu'opérateur, vérifier si la version du système d'exploitation utilisée est prise en charge, si les paquets nécessaires et la licence sont disponibles, et si le panneau de configuration est correctement intégré. Le fait qu'un panneau soit officiellement pris en charge ne signifie pas que toutes ses fonctionnalités fonctionnent de la même manière dans toutes les combinaisons possibles. Note également quelles applications et quels outils sont requis par les comptes de test sélectionnés.

Commencez par des comptes de test expressément autorisés et une sélection restreinte d'applications typiques. Vérifiez leurs répertoires racine, les programmes requis et les chemins d'exécution pertinents avant de créer d'autres comptes. Pour la mise en place, tu peux utiliser le mode dans lequel CageFS est désactivé par défaut et où les comptes sont activés individuellement ; il existe également un mode où CageFS est activé par défaut, avec des exceptions.

Les commandes de lecture suivantes sont destinées aux administrateurs autorisés sur un système sur lequel CageFS est installé. TESTBENUTZER Remplacez par un compte existant autorisé pour le test. Les droits requis et le résultat concret dépendent du système ; les commandes ne modifient aucune configuration.

/usr/sbin/cagefsctl --cagefs-status
/usr/sbin/cagefsctl --display-user-mode
/usr/sbin/cagefsctl --user-status TESTBENUTZER

La première commande affiche l'état global de CageFS, la seconde celui de Mode de fonctionnement. Le troisième interroge le statut du compte sélectionné. Le mode et le statut du compte doivent être considérés conjointement : un mode activé par défaut peut comporter des exceptions, tandis que dans l'autre mode, certains comptes sont expressément inclus.

Un résultat positif ne prouve pas pour autant que chaque service fonctionne effectivement dans le contexte prévu. Il convient donc de documenter séparément les informations fournies par l'administration et les chemins d'exécution vérifiés avec le compte de test. Ce n’est qu’ensuite qu’il sera possible de décider si le projet pilote peut être étendu à d’autres comptes et quelles exceptions sont nécessaires sur le plan opérationnel.

Comparaison des approches en matière de protection

Ces approches se distinguent principalement par la limite qu'elles fixent et par l'entité qui les gère. Le tableau classe leurs objectifs de protection ; les informations relatives aux coûts d'exploitation constituent des indications qualitatives de planification et non des valeurs mesurées. Les exigences concrètes dépendent de la plateforme concernée et de sa configuration.

Les droits d'accès aux fichiers et une visibilité restreinte ne sont pas des concepts interchangeables : même un chemin d'accès visible n'est pas nécessairement lisible, et un chemin d'accès mis à disposition doit être sécurisé de manière appropriée. CageFS complète ces droits par un environnement structuré. LVE, quant à lui, traite la question de la consommation des ressources ; pour une utilisation conjointe, les deux couches doivent être configurées de manière appropriée.

A sa propre machine virtuelle déplace la limite administrative par rapport à un environnement spécifique à l'utilisateur : le système invité doit être géré par l'utilisateur lui-même et reste dépendant de la plateforme de virtualisation. Un serveur distinct modifie encore davantage l'infrastructure partagée. Le choix de la variante appropriée dépend du modèle de menace, des droits requis et des ressources opérationnelles disponibles.

Un classement général des niveaux de sécurité serait donc trompeur. Pour comparer d'autres mécanismes et leurs domaines d'application respectifs, l'aperçu suivant est utile : Isolation des processus dans l'hébergement. L'examen concret est ensuite déterminant : quelle limite doit empêcher quel type d'accès, quels services la franchissent et qui supervise la configuration ?

Tester les chemins d'exécution de manière contrôlée

Le fait qu'un compte soit activé ne signifie pas pour autant que chaque processus associé démarre effectivement dans CageFS. Ce qui est déterminant, c'est le chemin d'exécution: La connexion SSH, le serveur web et les tâches planifiées peuvent utiliser différentes intégrations. Les administrateurs doivent donc vérifier, pour chaque service concerné, comment celui-ci associe les processus au compte et à son environnement.

Pour effectuer un test contrôlé, l'opérateur crée un compte de test autorisé et utilise exclusivement ses propres fichiers de test expressément validés. Un fichier situé dans l'environnement prévu permet de vérifier si l'accès attendu fonctionne ; un fichier préparé séparément, en dehors de la vue prévue, sert à vérifier la délimitation. Les répertoires clients tiers ne constituent pas un support de test approprié à cet effet.

Commence par vérifier via SSH quel environnement est effectivement attribué au compte de test et si les fichiers de test prévus sont accessibles comme prévu. Répète cette vérification à l'aide d'une application web configurée à cet effet et d'une tâche planifiée. Les résultats peuvent varier si les services sont intégrés différemment ou s'ils s'exécutent sous un autre contexte utilisateur.

Pour chaque tentative, notez le service, le compte, le chemin d'accès et le résultat. Un accès refusé ne fait que confirmer la limite observée dans ce contexte précis ; il ne prouve ni l'isolation correcte de tous les services, ni la sécurité de l'hôte dans son ensemble. À l'inverse, un accès inattendu qui aboutit doit faire l'objet d'une analyse avant que d'autres comptes ne soient mis en service.

En tant que client d'hébergement, tu peux vérifier ton propre contexte d'exécution et les fichiers partagés. En règle générale, tu ne peux pas vérifier de manière indépendante les paramètres globaux de CageFS, les autres comptes ni l'intégration de l'ensemble des services. Ces questions relèvent de la responsabilité de l'hébergeur ; en cas d'anomalies, décris-lui le service concerné et le chemin d'accès précis.

Absence d'outils et maintenance du squelette

Si un outil est installé sur l'hôte mais n'apparaît pas dans le compte client, vérifie d'abord le contexte d'exécution. Un appel via SSH n'utilise pas nécessairement le même environnement qu'une application web ou une tâche planifiée. Vérifie ensuite le chemin de recherche et le message d'erreur précis avant de conclure à l'absence d'un paquet.

L'exploitant examine ensuite le Squelette et la configuration du montage. Le « skeleton » détermine en partie quels fichiers et répertoires sont mis à disposition dans CageFS. Un programme peut donc être présent sur l'hôte tout en étant absent de l'environnement spécifique à l'utilisateur ; les bibliothèques nécessaires et autres dépendances doivent également être prises en compte lors de la mise à disposition.

La solution pratique ne consiste pas à monter, par mesure de précaution, des répertoires hôtes volumineux. Cela risquerait de rendre visibles davantage de fichiers que nécessaire pour la tâche à accomplir. L'administrateur devrait plutôt sélectionner les fichiers programme et les dépendances requis à l'aide de la documentation du fabricant, puis vérifier, dans le contexte de service prévu, si l'outil fonctionne.

À l'adresse suivante : Entretien du Skeleton Il faut également tenir compte des modifications apportées aux paquets système et au panneau de configuration. CloudLinux mentionne une mise à jour périodique ; après certaines modifications, une mise à jour forcée peut s'avérer nécessaire. Elle peut également s'avérer nécessaire après une reconstruction d'Apache. Cela ne signifie pas pour autant qu'il faille exécuter la même commande manuelle après chaque mise à jour.

Planifiez la mise à jour en fonction de la plateforme utilisée, puis vérifiez les applications et outils concernés. Si une application fonctionnait auparavant et ne fonctionne plus après une modification, la date de la modification du paquet, le service concerné et le message d'erreur précis vous aideront à cerner le problème. Cela permet de faire la distinction entre un problème de déploiement et une erreur de l'application.

Fonctionner en toute sécurité et prendre des décisions en toute connaissance de cause

Pour prendre une décision opérationnelle, il ne suffit pas de savoir si CageFS est disponible en principe. L'opérateur doit savoir quels comptes et services doivent être protégés, quels programmes sont nécessaires à cet effet et qui est responsable de l'intégration et de la maintenance. La visibilité limitée sur le système de fichiers vient compléter d'autres mesures de sécurité ; elle ne remplace ni les applications sécurisées ni la protection des identifiants d'accès.

Les éléments suivants méritent une attention particulière espaces communs et des montages supplémentaires. CloudLinux décrit pour /dev/shm une intégration commune et une possibilité d'isolation par utilisateur. Il convient de vérifier, en fonction de la configuration concrète, quelle variante s'applique réellement. Les montages supplémentaires ne doivent fournir que ce dont les applications ont besoin, car ils peuvent étendre l'environnement visible.

Une erreur lors de l'entrée dans CageFS a également des implications en matière de sécurité. À partir de la version 7.2.0-1 de CageFS, CloudLinux documente une option permettant d'empêcher l'exécution de processus en cas d'une telle erreur. Vérifie la version installée et le paramétrage effectif, plutôt que de déduire, à partir de l'existence de cette option, quel serait son comportement dans le cadre d'une offre d'hébergement concrète.

Les modifications apportées à Skeleton, aux montures ou à l'attribution des comptes doivent être intégrées dans un Procédures de maintenance. Tenez compte des éventuels remontages, des applications concernées et d'une fenêtre de maintenance ; documentez également la manière dont la modification peut être annulée en cas de problèmes. Ensuite, les chemins d'exécution pertinents et les outils nécessaires doivent être vérifiés à nouveau à l'aide des comptes de test prévus à cet effet.

Pour les clients, la question cruciale est de savoir quelle séparation le fournisseur met réellement en œuvre et comment il la vérifie. Les opérateurs doivent quant à eux prendre en compte à la fois les besoins en matière de protection et la charge de travail que cela implique : un environnement trop généreux peut affaiblir la séparation, tandis qu'un environnement trop restreint peut nuire aux applications nécessaires. Ces deux cas exigent une configuration réfléchie et des contrôles réguliers.