TL;DR : N'hésitez pas à passer directement à la conclusion en bas de page si vous le souhaitez :) !

L'objectif de SELinux est d'empêcher l'escalade des privilèges en appliquant une politique obligatoire qui restreint les actions possibles des utilisateurs privilégiés et non privilégiés.

Le terme "utilisateurs" inclut également tout processus exécuté sur l'appareil, qu'il soit ou non directement lié aux actions physiques de l'utilisateur (l'humain, vous ;) ), puisque chaque processus est exécuté en utilisant un compte "utilisateur" du système.

Historiquement, les permissions sur les systèmes basés sur Unix sont gérées à l'aide de ce que l'on appelle un système de contrôle d'accès discrétionnaire (DAC). Dans ce modèle :

• Les ressources comme les fichiers ont des propriétaires qui peuvent définir des droits d'accès sur les ressources qu'ils possèdent : cela leur permet de décider si une ressource particulière doit être privée (seul le propriétaire peut y accéder) ou si elle doit être partagée avec d'autres utilisateurs.
• En plus de cela, vous avez le super-utilisateur (appelé root sur les systèmes basés sur Unix) qui est l'utilisateur administratif et qui a accès à tout sur le système. Ce compte peut être utilisé de manière interactive par un humain (généralement un administrateur système) pour entretenir ou réparer le dispositif, mais en général, ce compte sera surtout utilisé par des services d'arrière-plan ou de bas niveau qui nécessitent un tel niveau de privilège : pilotes de dispositifs, services de configuration réseau, services devant accéder aux fichiers de tous les utilisateurs ou gérant la communication interne entre utilisateurs.

C'est très bien et cela offre déjà une bonne sécurité. Cependant, qu'en est-il de circonstances telles que celles-ci :

1. Que se passerait-il si un bug dans un service fonctionnant en tant que root est trouvé qui permettrait à un attaquant de tromper ce service en exécutant un code arbitraire ? Cet attaquant obtiendrait un accès complet à l'appareil. Pour donner quelques exemples concrets, un tel bogue pourrait être déclenché par l'envoi d'informations de configuration réseau spécialement conçues ( DHCP ) ou un MMS au téléphone.
2. Que se passe-t-il si un utilisateur ne protège pas correctement ses ressources privées ? Ces ressources pourraient alors faire l'objet d'un accès malveillant (lecture, voire modification ou suppression) par d'autres utilisateurs non privilégiés. C'est typiquement ce qui se passe lorsqu'une application malveillante est exécutée sur votre téléphone (peu importe que vous l'ayez installée par ruse ou qu'elle soit arrivée ici toute seule en utilisant un bogue dans une autre application non privilégiée, un navigateur ou un client de messagerie par exemple), et que cette application malveillante essaie d'accéder directement aux données ou aux emplacements de stockage d'autres applications (elle peut le faire pour accéder à des données normalement inaccessibles ou pour s'installer à plusieurs endroits afin de rendre sa suppression plus difficile).

Voilà SELinux.

SELinux est un système de contrôle d'accès obligatoire (MAC). Alors que dans le système DAC décrit précédemment, les utilisateurs étaient responsables de l'établissement de droits appropriés sur leurs propres ressources, avec un système MAC, une politique à l'échelle du système (fournie avec le système d'exploitation) est appliquée à la fois aux utilisateurs privilégiés et non privilégiés.

Cela permet de résoudre les deux problèmes mentionnés ci-dessus de la manière suivante :

1. Comme je l'ai dit, cette politique s'applique également aux utilisateurs privilégiés. Cela signifie qu'avec une politique correctement conçue, un service conçu pour gérer la configuration du réseau de l'appareil ne pourra rien faire d'autre : il n'aura pas accès aux SMS par exemple, et un service gérant les SMS n'aura pas accès à la configuration du réseau, et aucun d'entre eux n'aura accès aux données de l'utilisateur, malgré le fait que tous deux s'exécutent en utilisant le compte super-utilisateur.
2. Android a récemment inclus une fonction multi-utilisateurs qui est mise en œuvre par SELinux, empêchant tout utilisateur d'accéder aux données d'un autre utilisateur. Mais au-delà de cela, la politique SELinux est également responsable de la description du comportement des applications autorisées, et très probablement, même si certaines ressources ne sont pas correctement protégées à l'aide du système DAC, SELinux viendra à la rescousse et empêchera toujours l'application malveillante d'y accéder directement.

Les systèmes DAC et MAC ne s'excluent pas mutuellement, au contraire, le système MAC (SELinux) agit comme une deuxième couche de défense derrière le système DAC (les permissions traditionnelles de type Unix). Le rôle de SELinux est de bloquer toute activité contraire à la politique qui, avec le seul système DAC, serait autrement acceptée.

Le problème est qu'une telle politique peut être très complexe à rédiger : elle doit en effet couvrir tous les composants de l'appareil pour chaque utilisation possible dans chaque situation. En fait, peu importe si une action peut être légitime dans votre situation : si ce n'est pas dans la politique, c'est interdit . Des politiques mal conçues peuvent donc avoir des conséquences aléatoires, comme des plantages d'applications, des fonctionnalités inutilisables, etc.

C'est pourquoi les premières versions d'Android embarquant SELinux l'incluaient en mode "Permissif" par défaut. Dans ce mode, SELinux journal mais il ne tentera pas de bloquer l'activité associée. En analysant les fichiers journaux résultants, il devient possible de corriger et d'améliorer la politique jusqu'au point où les seules violations de la politique restantes sont effectivement des comportements malveillants ou indésirables. À ce stade, SELinux peut passer en mode "application" : il ne se contentera plus de consigner, mais bloquera également toute action fautive.

Conclusion

SELinux est une technique d'atténuation. Elle n'empêche pas les attaquants de pénétrer dans votre téléphone, mais elle garantit qu'une fois sur place, ils peuvent faire le moins de choses possible, idéalement rien d'utile, ce qui supprime tout intérêt à attaquer le téléphone en premier lieu.

Plus la ROM est ancienne, plus le nombre de bogues de sécurité permettant un tel accès est important. SELinux serait un moyen efficace de garder un minimum de sécurité malgré ces vulnérabilités connues, cependant pour fonctionner correctement SELinux s'appuie sur une politique complexe.

Si votre ROM est fournie avec SELinux en mode "Permissif" par défaut, cela signifie probablement que la politique qu'elle contient n'est pas suffisamment fiable pour être passée en toute sécurité en mode "Enforcing".

Si vous êtes assez technophile et que vous avez accès au journal du téléphone ( dmesg au moins, mais en général, ils sont également copiés dans le fichier logcat : il existe des applications permettant de voir ce dernier mais selon votre version d'Android, elles peuvent nécessiter un accès Root), vous pouvez vérifier si vous trouvez des entrées "avc" : ce sont des messages vous indiquant que SELinux vient de détecter une action allant à l'encontre de la politique.

Voici un exemple d'une telle entrée tirée de Site web de CyanogenMod :

type=AVC msg=audit(1363289005.532:184): avc: denied { read } for pid=29199 comm="Trace" 
name="online" dev="sysfs" ino=30 scontext=staff_u:staff_r:googletalk_plugin_t 
tcontext=system_u:object_r:sysfs_t tclass=file

S'il n'y en a aucun, seulement quelques-uns ou pour toute autre raison, vous pensez qu'ils ne vous empêcheront pas d'utiliser le téléphone, vous pouvez essayer de faire passer SELinux en mode "Enforcing". Dans les anciennes ROMs CyanogenMod, cela était facile et possible en utilisant simplement une option cachée dans le GUI (pas besoin de Rooter le téléphone ou d'installer une application spécifique), je ne sais pas si d'autres ROMs offrent la même fonctionnalité mais puisque vous avez utilisé le tag CyanogenMod je suppose que vous avez peut-être de la chance ;).