L'entreprise a soumis le problème à la discussion sur la liste de diffusion des développeurs du noyau. Linux Le module LSM implémente le mécanisme IPE (Application de la politique d'intégrité), étendant ainsi les systèmes de contrôle d'accès obligatoires existants. Au lieu de s'appuyer sur des étiquettes et des chemins, IPE permet d'autoriser ou de refuser des opérations en fonction des propriétés constantes du composant système concerné. Le module permet de définir une politique d'intégrité générale pour l'ensemble du système, en spécifiant les opérations autorisées et la méthode de vérification de 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 d'amorçage et le noyau jusqu'aux exécutables finaux, à la configuration et aux fichiers chargeables. Par exemple, IPE peut servir à spécifier quels exécutables sont autorisés à s'exécuter, en fonction de leur conformité à la version de référence grâce aux hachages cryptographiques fournis par le système dm-verity. Si un fichier est modifié ou altéré, IPE peut bloquer l'opération ou consigner la violation d'intégrité.
Le mécanisme proposé peut être utilisé dans le micrologiciel des systèmes embarqués, où tous les logiciels et paramètres sont compilés et fournis spécifiquement par le propriétaire. Par exemple, dans les centres de données Microsoft, IPE est utilisé dans les pare-feu. Contrairement à d'autres systèmes de vérification d'intégrité, tels que IMA, IPE est indépendant des métadonnées du système de fichiers : toutes les propriétés déterminant la permission des opérations sont stockées directement dans le noyau.
Les règles sont définies sous forme textuelle à l'aide d'ensembles 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 déclenchera une tentative d'exécution), et « action », qui définit l'action (par exemple, « action=DENY » pour bloquer). Les règles sont liées à des 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 autoriseront uniquement le démarrage à partir d'une partition vérifiée, interdiront l'exécution de fichiers à partir de partitions qui ne possèdent pas de signatures dans dm-verity, et interdiront également de manière sélective l'exécution d'un fichier avec le hachage « 401fce…0dec146938 ».
L'ensemble initial de règles de démarrage est défini à l'aide du paramètre SECURITY_IPE_BOOT_POLICY et inclus dans la compilation du noyau. D'autres règles sont ajoutées au besoin via le fichier /sys/kernel/security/ipe/new_policy. Les règles validées sont chiffrées à l'aide du certificat spécifié dans SYSTEM_TRUSTED_KEYRING.
Pour les systèmes d'usage général, il est recommandé d'utiliser IPE conjointement avec le mécanisme DIGLIM développé par Huawei. DIGLIM, implémenté à l'aide d'eBPF, permet une mise en œuvre aisée du contrôle d'intégrité au niveau des fichiers dans les distributions standard, sans nécessiter de modifications (il se présente comme une variante de démarrage sécurisé fonctionnant au niveau de la couche application). DIGLIM gère un pool de hachages de vérification pour les fichiers et les métadonnées, et n'autorise l'accès aux fichiers exécutables que si leur hachage est présent dans ce pool. La liste des hachages peut être obtenue auprès du gestionnaire de paquets RPM ou générée manuellement par l'utilisateur.
Source: opennet.ru
