TL;DR: Si lo desea, puede ir directamente a la conclusión en la parte inferior :) ¡!

El objetivo de SELinux es prevenir la escalada de privilegios mediante la aplicación de una política obligatoria que restringe las posibles acciones tanto de los usuarios sin privilegios como de los privilegiados.

El término "usuarios" aquí también incluye cualquier proceso que se ejecute en el dispositivo, sin importar si está directamente relacionado con las acciones del usuario físico (el humano, tú ;) ), ya que todo proceso se ejecuta utilizando alguna cuenta de "usuario" del sistema.

Históricamente, los permisos en los sistemas basados en Unix se manejan usando lo que se llama un sistema de Control de Acceso Discrecional (DAC). En este modelo:

• Los recursos, como los archivos, tienen propietarios que pueden definir los derechos de acceso a los recursos que poseen: esto les permite decidir si un determinado recurso debe ser privado (sólo el propietario puede acceder a él) o si debe ser compartido con algunos otros usuarios.
• Además, tiene el superusuario (llamado root en sistemas basados en Unix) que es el usuario administrativo y tiene acceso a todo en el sistema. Esta cuenta puede ser utilizada de forma interactiva por un humano (normalmente un administrador del sistema) para mantener o reparar el dispositivo, pero normalmente esta cuenta será utilizada sobre todo por servicios de fondo o de bajo nivel que requieran dicho nivel de privilegios: controladores de dispositivos, servicios de configuración de red, servicios que necesiten acceder a archivos de todos los usuarios o que manejen la comunicación interna entre usuarios.

Esto es muy bonito y ya proporciona una buena seguridad. Sin embargo, qué pasa con circunstancias como estas:

1. ¿Qué pasaría si un error en un servicio que se ejecuta como root que permita a un atacante engañar a dicho servicio para que ejecute algún código arbitrario? Dicho atacante obtendría un acceso completo al dispositivo. Para dar algunos ejemplos concretos, este fallo podría activarse mediante el envío de información de configuración de red especialmente diseñada ( DHCP ) o un MMS al teléfono.
2. ¿Qué pasaría si algún usuario no protege correctamente los recursos privados? Entonces estos recursos podrían ser accedidos maliciosamente (leídos, incluso modificados o borrados) por otros usuarios sin privilegios. Esto es lo que suele ocurrir cuando una aplicación maliciosa se ejecuta en el teléfono (no importa si te han engañado para que la instales, o si llegó aquí por sí misma utilizando un error en otra aplicación sin privilegios, un navegador o un cliente de correo, por ejemplo), y esta aplicación maliciosa intenta acceder directamente a los datos o a las ubicaciones de almacenamiento de otras aplicaciones (puede hacerlo para acceder a datos normalmente inalcanzables o para instalarse en varios lugares con el fin de hacer más difícil su eliminación).

Aquí viene SELinux.

SELinux es un sistema de Control de Acceso Obligatorio (MAC). Mientras que en el sistema DAC descrito anteriormente los usuarios eran responsables de establecer los derechos apropiados sobre sus propios recursos, con un sistema MAC se aplica una política para todo el sistema (proporcionada con el sistema operativo) tanto a los usuarios con privilegios como a los que no los tienen.

Esto resuelve los dos problemas mencionados anteriormente de las siguientes maneras:

1. Como he dicho, esta política también se aplica a los usuarios privilegiados. Esto significa que, con una política bien diseñada, un servicio destinado a gestionar la configuración de red del dispositivo no podrá hacer nada más: no tendrá acceso a los SMS, por ejemplo, y un servicio que gestione los SMS no tendrá acceso a la configuración de red, y ninguno de ellos tendrá acceso a los datos del usuario, a pesar de que ambos se ejecuten utilizando la cuenta de superusuario.
2. Recientemente, Android ha incluido una función multiusuario que se refuerza con SELinux, impidiendo que cualquier usuario acceda a los datos de otros usuarios. Pero más allá de eso, la política de SELinux también es responsable de describir el comportamiento de las aplicaciones permitidas, y lo más probable es que incluso si algunos recursos no están debidamente protegidos utilizando el sistema DAC, SELinux venga al rescate y siga impidiendo que la aplicación maliciosa acceda directamente a ellos.

Los sistemas DAC y MAC no son mutuamente excluyentes, al contrario, el sistema MAC (SELinux) actúa como una segunda capa de defensa detrás del sistema DAC (los permisos tradicionales tipo Unix). El trabajo de SELinux es bloquear cualquier actividad contraria a la política que, dado sólo el sistema DAC, sería aceptada de otra manera.

Lo difícil es que la redacción de una póliza de este tipo puede ser muy compleja: en efecto, debe cubrir todos los componentes del dispositivo para cada uso posible en cada situación. De hecho, no importa si alguna acción puede ser legítima en su situación: si no está en la política, está prohibido . Por lo tanto, las políticas mal diseñadas pueden tener consecuencias aleatorias, como caídas de la aplicación, funcionalidad inutilizable, etc.

Por eso, las primeras versiones de Android que incluían SELinux lo hacían en modo "Permisivo" por defecto. En este modo, SELinux Registro violaciones de la política, pero no intentará bloquear la actividad asociada. Al analizar los archivos de registro resultantes, es posible corregir y mejorar la política hasta el punto en que la única violación de la política que queda es realmente un comportamiento malicioso o no deseado. En este punto, SELinux puede ponerse en modo "Enforcing": ahora no sólo registrará, sino que también bloqueará cada acción infractora.

Conclusión:

SELinux es una técnica de mitigación. No impide que los atacantes entren en el teléfono, pero se asegura de que una vez allí puedan hacer el menor número de cosas posible, idealmente nada útil, eliminando así cualquier interés de atacar el teléfono en primer lugar.

Cuanto más antigua sea la ROM, mayor será el número de fallos de seguridad que permitan dicho acceso. SELinux sería una forma eficiente de mantener un mínimo de seguridad a pesar de estas vulnerabilidades conocidas, sin embargo para funcionar correctamente SELinux se basa en una política compleja.

Si su ROM se suministra con SELinux en modo "Permisivo" por defecto, esto probablemente significa que la política que contiene no es lo suficientemente fiable como para ser cambiada de forma segura al modo "Enforcing".

Si eres lo suficientemente técnico y tienes acceso al registro telefónico ( dmesg al menos, pero normalmente también se copian en logcat (hay aplicaciones que permiten ver esta última pero dependiendo de tu versión de Android pueden requerir acceso Root), puedes comprobar si encuentras entradas "avc": son mensajes que te indican que SELinux acaba de detectar una acción que va en contra de la política.

Este es un ejemplo de una entrada de este tipo tomada de Sitio 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

Si no hay ninguno, sólo unos pocos o por cualquier razón crees que no pueden impedirte usar el teléfono, puedes intentar cambiar SELinux al modo "Enforcing". En las ROMs más antiguas de CyanogenMod, esto era fácil y posible simplemente usando una opción oculta en la interfaz gráfica de usuario (no hace falta rootear el teléfono ni instalar ninguna aplicación específica), no sé si otras ROMs ofrecían la misma función pero como has usado la etiqueta CyanogenMod supongo que puedes tener suerte ;).