Concepts SELinux

Consultez cette page pour vous familiariser avec les concepts de SELinux.

Contrôle des accès obligatoire

Security Enhanced Linux (SELinux) est un système de contrôle des accès (MAC) obligatoire pour le système d'exploitation Linux. En tant que système MAC, il diffère de celui de Linux système familier de contrôle des accès discrétionnaire (DAC). Dans un système DAC, un concept de propriété, où le propriétaire d'une ressource donnée contrôle l'accès les autorisations qui lui sont associées. La précision n'est généralement pas très précise. à une élévation involontaire des privilèges. Un système MAC, cependant, consulte un système central autorité pour prendre une décision concernant toutes les tentatives d'accès.

SELinux a été implémenté dans le module de sécurité Linux (LSM) qui reconnaît divers objets du noyau et les actions sensibles les a effectuées. Au moment où chacune de ces actions une fonction de hook LSM est appelée pour déterminer doit être autorisée sur la base des informations la concernant, stockées dans un espace d'un objet Security. SELinux fournit une implémentation pour ces hooks et la gestion de ces objets de sécurité, qui sont associés à sa propre stratégie, pour déterminer les décisions d'accès.

En plus d'autres mesures de sécurité Android, le contrôle des accès limite considérablement les dommages potentiels des machines compromises et Google Cloud. Utiliser des outils comme l'accès discrétionnaire et obligatoire d'Android vous offre une structure permettant de garantir que votre logiciel s'exécute au minimum niveau de privilège. Cela atténue les effets des attaques et réduit la probabilité que des processus errants écrasent ou même transmettent des données.

Dans Android 4.3 et versions ultérieures, SELinux fournit un contrôle des accès (MAC) obligatoire par rapport aux environnements traditionnels de contrôle des accès discrétionnaire (DAC). Pour les logiciels doivent généralement s'exécuter en tant que compte utilisateur racine les appareils de stockage en mode bloc. Dans un environnement Linux traditionnel basé sur DAC, si l'utilisateur racine est compromis afin que l’utilisateur puisse écrire sur chaque périphérique en mode bloc brut. Toutefois, SELinux peut être utilisé pour étiqueter ces périphériques afin que le processus ne peut écrire que pour ceux spécifiés dans la stratégie associée. Dans ce le processus ne peut pas écraser les données et les paramètres système un appareil en mode bloc brut spécifique.

Consultez la section Cas d'utilisation. pour découvrir d'autres exemples de menaces et comment les gérer avec SELinux.

Niveaux d'application

SELinux peut être implémenté dans différents modes:

  • Permissif : la règle de sécurité SELinux n'est pas appliquée. Elle est seulement consignée.
  • Enforcing (Application) : la règle de sécurité est appliquée et consignée. Échecs apparaissent comme des erreurs EPERM.

Ce choix est binaire et détermine si votre stratégie prend des mesures ou simplement vous permet de recenser les défaillances potentielles. Permissive est particulièrement utile pendant la mise en œuvre.

Types, attributs et règles

Android s'appuie sur le composant TE (Type Enforcement) de SELinux . Cela signifie que tous les objets (tels que les fichiers, les processus ou les sockets) ont un type qui leur est associé. Par exemple, une application sera de type untrusted_app. Pour un processus, son type est également appelé domaine. Il est possible d'annoter un type avec un ou de nombreux attributs. Les attributs sont utiles pour faire référence à plusieurs types en même temps.

Les objets sont mappés à des classes. (par exemple, un fichier, un répertoire, un lien symbolique, un socket) et les différents types d'accès sont représentés par des autorisations pour chaque classe. Par exemple, l'autorisation open existe pour la classe file Bien que les types et les attributs soient régulièrement mis à jour la règle Android SELinux, les autorisations et les classes sont définies de manière statique et rarement mis à jour dans le cadre d’une nouvelle version de Linux.

Une règle de stratégie se présente sous la forme suivante: allow source target:class permissions; où:

  • Source : type (ou attribut) de l'objet de la règle. Qui demande l'accès ?
  • Cible : type (ou attribut) de l'objet. À quoi l'accès est-il demandé ?
  • Class (Classe) : type d'objet (par exemple, fichier ou socket) auquel on accède.
  • Autorisations : opération (ou ensemble d'opérations) en cours (par exemple, lecture ou écriture).

Voici un exemple de règle:

allow untrusted_app app_data_file:file { read write };

Cela signifie que les applications sont autorisées à lire et à écrire des fichiers étiquetés app_data_file Il existe d'autres types d'applications. Pour instances, isolated_app est utilisé pour les services applicatifs avec isolatedProcess=true dans leur fichier manifeste. Au lieu de répéter pour les deux types, Android utilise un attribut nommé appdomain pour tous les types qui couvrent les applications:

# Associate the attribute appdomain with the type untrusted_app.
typeattribute untrusted_app, appdomain;

# Associate the attribute appdomain with the type isolated_app.
typeattribute isolated_app, appdomain;

allow appdomain app_data_file:file { read write };

Lorsqu'une règle spécifiant un nom d'attribut est rédigée, ce nom est se développe automatiquement pour afficher la liste des domaines ou types associés . Voici quelques caractéristiques notables:

  • domain : attribut associé à tous les types de processus
  • file_type : attribut associé à tous les types de fichiers

Macros

Pour l'accès aux fichiers en particulier, il existe de nombreux types d'autorisations pour tenir compte. Par exemple, l'autorisation read ne suffit pas pour ouvrir fichier ou appelez stat dessus. Pour simplifier la définition des règles, Android fournit un ensemble de macros pour gérer les cas les plus courants. Par exemple, dans l’ordre pour inclure les autorisations manquantes telles que open, la règle ci-dessus peut être réécrit comme suit:

allow appdomain app_data_file:file rw_file_perms;

Consultez le global_macros et te_macros pour obtenir d'autres exemples de macros utiles. Dans la mesure du possible, utilisez les macros pour réduire le risque de défaillance dues à des refus sur des autorisations.

Une fois qu'un type est défini, il doit être associé au fichier ou au processus qu'il représente. Consultez la section Implémenter SELinux. pour en savoir plus sur la façon dont cette association est effectuée. Pour en savoir plus sur des règles de pare-feu, consultez la Notebook SELinux

Contexte et catégories de sécurité

Lors du débogage des règles SELinux ou de l'étiquetage de fichiers (via file_contexts ou lorsque vous exécutez ls -Z), vous pouvez dans un contexte de sécurité (également appelé étiquette). Pour Exemple: u:r:untrusted_app:s0:c15,c256,c513,c768 Un contexte de sécurité se présente comme suit: user:role:type:sensitivity[:categories] Vous pouvez généralement ignorer Champs user, role et sensitivity d'un (voir Spécificité). type est expliqué dans la section précédente. categories font partie de la sécurité multiniveau (MLS) de Google Cloud dans SELinux. Depuis Android S, les catégories sont utilisées pour:

  • isoler les données de l'application pour empêcher qu'une autre application y accède ;
  • Isolez les données de l'application d'un utilisateur physique à un autre.

Spécificité

Android n'utilise pas toutes les fonctionnalités fournies par SELinux. Pendant la lecture documentation externe, gardez à l’esprit les points suivants:

  • La majorité des stratégies d'AOSP sont définies à l'aide du langage de stratégie de noyau. L'utilisation du langage CIL (Common Intermediate Language) présente certaines exceptions.
  • Les utilisateurs SELinux ne sont pas utilisés. Le seul paramètre défini par l'utilisateur u Si nécessaire, les utilisateurs physiques sont représentés à l'aide du champ de catégories d'un contexte de sécurité.
  • Les rôles SELinux et le contrôle des accès basé sur les rôles (RBAC) ne sont pas utilisés. Deux rôles par défaut sont définis et utilisés: r pour les sujets et object_r pour les objets.
  • Les sensibilités SELinux ne sont pas utilisées. La sensibilité par défaut de s0 est toujours définie.
  • Les valeurs booléennes SELinux ne sont pas utilisées. Une fois la règle créée pour un appareil, ne dépend pas de l'état de l'appareil. Cela simplifie le processus l'audit et le débogage des stratégies.