SELinux dépend des étiquettes pour faire correspondre les actions et les politiques. Les étiquettes déterminent ce qui est autorisé. Les sockets, les fichiers et les processus ont tous des étiquettes dans SELinux. Les décisions de SELinux sont basées fondamentalement sur les étiquettes attribuées à ces objets et sur la politique définissant la manière dont ils peuvent interagir. Dans SELinux, une étiquette prend la forme : user:role:type:mls_level, où le type est le composant principal des décisions d'accès, qui peut être modifié par les autres sections qui composent l'étiquette. Les objets sont mis en correspondance avec des classes et les différents types d'accès pour chaque classe sont représentés par des permissions.
Les règles de politique se présentent sous la forme : allow domains types:classes permissions ;, où :
Domaine - Une étiquette pour le processus ou l'ensemble des processus. Également appelé type de domaine, car il s'agit simplement d'un type pour un processus. Type - Une étiquette pour l'objet (par exemple, fichier, socket) ou un ensemble d'objets. Classe - Le type d'objet (par exemple, fichier, socket) auquel on accède. Permission - L'opération (par exemple, lecture, écriture) effectuée. Ainsi, un exemple d'utilisation suivrait la structure suivante :
allow appdomain app_data_file:file rw_file_perms ;
Cela signifie que tous les domaines d'application sont autorisés à lire et à écrire les fichiers étiquetés app_data_file. Notez que cette règle repose sur les macros définies dans le fichier global_macros, et que d'autres macros utiles se trouvent également dans le fichier te_macros, qui se trouvent tous deux dans le répertoire external/sepolicy de l'arborescence des sources de l'AOSP. Les macros sont fournies pour des regroupements communs de classes, de permissions et de règles, et devraient être utilisées autant que possible pour aider à réduire la probabilité d'échecs dus à des refus sur des permissions liées.
En plus d'énumérer individuellement les domaines ou les types dans une règle, on peut également se référer à un ensemble de domaines ou de types via un attribut. Un attribut est simplement un nom pour un ensemble de domaines ou de types. Chaque domaine ou type peut être associé à un nombre quelconque d'attributs. Lorsqu'une règle spécifiant un nom d'attribut est écrite, ce nom est automatiquement étendu à la liste des domaines ou des types associés à l'attribut. Par exemple, l'attribut domain est associé à tous les domaines de processus, et l'attribut file_type est associé à tous les types de fichiers.
Utilisez la syntaxe ci-dessus pour créer des règles avc qui constituent l'essence d'une politique SELinux. Une règle prend la forme :
<rule variant> <source_types> <target_types> : <classes> <permissions>
La règle indique ce qui doit se passer lorsqu'un sujet étiqueté avec l'un des types_source tente une action correspondant à l'une des permissions sur un objet avec l'une des classes de classe qui a l'une des étiquettes des types_cible. L'exemple le plus courant d'une de ces règles est une règle d'autorisation, par ex :
autoriser domaine null_device:chr_file { open } ;
Cette règle permet à un processus, quel que soit le domaine associé à l'attribut "domain", de réaliser l'action décrite par la permission "open" sur un objet de la classe "chr_file" (fichier de périphérique de caractères) dont l'étiquette target_type est "null_device". Dans la pratique, cette règle peut être étendue pour inclure d'autres permissions :
allow domain null_device:chr_file { getattr open read ioctl lock append write} ;
Si l'on tient compte du fait que 'domain' est un attribut attribué à tous les domaines de processus et que null_device est l'étiquette du périphérique de caractères /dev/null, cette règle permet essentiellement de lire et d'écrire sur /dev/null.
Un domaine correspond généralement à un processus et aura un label qui lui sera associé.
Par exemple, une application Android typique est exécutée dans son propre processus et porte le label untrusted_app qui lui accorde certaines autorisations restreintes.
Les applications de la plate-forme intégrées au système fonctionnent sous une étiquette distincte et bénéficient d'un ensemble distinct de permissions. Les applications UID système qui font partie du système central d'Android sont exécutées sous le label system_app et bénéficient d'un autre ensemble de privilèges.
L'accès aux étiquettes génériques suivantes ne doit jamais être autorisé directement aux domaines ; au lieu de cela, un type plus spécifique doit être créé pour l'objet ou les objets :
périphérique de prise périphérique dispositif_bloc service par défaut fichier_données_système tmpfs
Source : Concepts SELinux
Pour plus de détails, voir : Sécurité renforcée de Linux dans Android
Mise en œuvre de SELinux
