L'entreprise a soumis à discussion sur la liste de diffusion des développeurs du noyau Linux le code d'un module LSM implémentant le mécanisme IPE (Integrity Policy Enforcement), qui étend les systèmes de contrôle d'accès obligatoire existants. Au lieu d'être lié aux labels et aux chemins, dans IPE, la décision de permettre ou d'interdire une opération est prise sur la base des propriétés permanentes du composant système avec lequel l'opération est effectuée. Le module permet de définir une politique générale de protection de l'intégrité pour l'ensemble du système, spécifiant quelles opérations sont autorisées et comment vérifier l'authenticité des composants.
IPE vise à créer des systèmes entièrement vérifiables, dont l'intégrité est confirmée depuis le chargeur initial et le noyau jusqu'aux fichiers exécutables finaux, à la configuration et aux fichiers chargés. Par exemple, avec IPE, il est possible de spécifier quels fichiers exécutables peuvent être lancés, en vérifiant leur conformité avec une version de référence à l'aide de hachages cryptographiques fournis par le système dm-verity. En cas de modification ou de substitution d'un fichier, IPE peut bloquer l'opération ou consigner le fait de la violation d'intégrité.
Le mécanisme proposé peut être appliqué dans les firmwares pour les appareils embarqués, où tout le logiciel et les paramètres sont spécifiquement rassemblés et fournis par le propriétaire, par exemple, dans les centres de données Microsoft, IPE est utilisé dans le matériel des pare-feu. Contrairement à d'autres systèmes de vérification d'intégrité, tels que l'IMA, IPE se distingue par son indépendance vis-à-vis des métadonnées dans le système de fichiers — toutes les propriétés déterminant la validité des opérations sont stockées directement dans le noyau.
Les règles sont définies sous forme textuelle à l'aide de jeux de paires clé-valeur. Les clés de base sont « op », qui définit l'opération à laquelle la règle s'applique (par exemple, op=EXECUTE se déclenchera lors d'une tentative d'exécution), et « action », qui détermine l'action (par exemple, « action=DENY » pour bloquer). Les règles sont liées aux propriétés fournies par des sous-systèmes externes, tels que dm-verity et fs-verity.
Par exemple, les règles op=EXECUTE boot_verified=TRUE action=ALLOW op=EXECUTE dmverity_signature=FALSE action=DENY op=EXECUTE fsverity_digest=sha256:401fce…0dec146938 action=DENY permettront uniquement le démarrage à partir d'une partition vérifiée, interdiront l'exécution de fichiers à partir de partitions sans signatures dans dm-verity, et interdiront sélectivement l'exécution du fichier avec le hachage «401fce…0dec146938».
L'ensemble initial des règles de démarrage est défini à l'aide de la configuration SECURITY_IPE_BOOT_POLICY et est inclus dans la compilation du noyau, tandis que les autres règles sont ajoutées au besoin via le fichier /sys/kernel/security/ipe/new_policy. Les règles transmises sont chiffrées à l'aide du certificat défini dans SYSTEM_TRUSTED_KEYRING.
Sur les systèmes à usage général, il est recommandé d'appliquer IPE en conjonction avec le mécanisme DIGLIM, développé par Huawei. DIGLIM est mis en œuvre via eBPF et permet de réaliser facilement un contrôle d'intégrité au niveau des fichiers individuels dans des distributions ordinaires, sans nécessiter leur retravail (présenté comme une variante de Secure Boot fonctionnant au niveau de l'application). L'idée de DIGLIM est de maintenir un pool de hachages de vérification pour les fichiers et les métadonnées, et de fournir l'accès aux fichiers exécutables uniquement si son hachage est présent dans le pool. La liste des hachages peut être obtenue du gestionnaire de paquets RPM ou générée manuellement par l'utilisateur.
Source : opennet.ru
