TL; DR: ¡siéntase libre de saltar directamente a la conclusión en la parte inferior si lo desea :)!

El objetivo de SELinux es evitar la escalada de privilegios mediante la aplicación de una política obligatoria que restringe las posibles acciones de usuarios privilegiados y no privilegiados.

El término "usuarios" aquí también incluye cualquier proceso que se ejecuta en el dispositivo, sin importar si está directamente relacionado con las acciones físicas del usuario (el humano, usted;)), ya que cada 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 derechos de acceso a los recursos que poseen: esto les permite decidir si un recurso en particular debe ser privado (solo el propietario puede acceder a él) o si debe compartirse con otros usuarios.
• Además de esto, tiene el superusuario (llamado rooten 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 ser humano (generalmente un administrador del sistema) para mantener o reparar el dispositivo, pero por lo general esta cuenta será utilizada principalmente por servicios en segundo plano o de bajo nivel que requieren dicho nivel de privilegio: controladores de dispositivos, servicios de configuración de red, servicios la necesidad de acceder a los archivos de todos los usuarios o el manejo de la comunicación interna entre usuarios.

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

1. ¿Qué sucedería si rootse encuentra un error en un servicio que se ejecuta como tal, lo que permitiría 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, dicho error podría desencadenarse al enviar información de configuración de red ( DHCP ) especialmente diseñada 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, tal vez incluso modificados o eliminados) por otros usuarios sin privilegios. Por lo general, esto es lo que tiene cuando se ejecuta una aplicación maliciosa en su teléfono (sin importar si lo engañaron para que la instale o si llegó aquí por sí mismo al usar un error en otra aplicación sin privilegios, un navegador o cliente de correo para ejemplo), y esta aplicación maliciosa intenta acceder directamente a los datos de otras aplicaciones o ubicaciones de almacenamiento (puede hacerlo para acceder a datos normalmente inalcanzables o instalarse en varios lugares para dificultar 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 de todo el sistema (proporcionada con el sistema operativo) tanto para los usuarios privilegiados como para los no privilegiados.

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

1. Como dije, esta política también se aplica a los usuarios privilegiados. Esto significa que, con una política diseñada correctamente, un servicio diseñado para manejar la configuración de red del dispositivo no podrá hacer nada más: no tendrá acceso a SMS, por ejemplo, y un servicio que maneje 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 ejecutan con la cuenta de superusuario.
2. Android incluyó recientemente una función multiusuario que SELinux implementa, lo que evita 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 protegidos adecuadamente con el sistema DAC, SELinux vendrá al rescate y aún evitará que la aplicación maliciosa acceda directamente a ellos.

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

Lo complicado es que dicha política puede ser muy compleja de escribir: de hecho, debe cubrir los componentes de cada dispositivo para cada uso posible en cada situación. De hecho, no importa si alguna acción puede ser legítima en tu situación: si no está en la póliza, está prohibida . Por lo tanto, las políticas mal diseñadas pueden tener consecuencias aleatorias, como bloqueos de aplicaciones, funcionalidad inutilizable, etc.

Es por eso que las primeras versiones de Android que enviaron SELinux lo incluían en modo "Permisivo" por defecto. En este modo, SELinux registrará las infracciones 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 infracción restante de la política son comportamientos maliciosos o no deseados. En este punto, SELinux puede cambiarse al modo "Cumplimiento": ahora no solo registrará sino que también bloqueará cada acción infractora.

Conclusión

SELinux es una técnica de mitigación. No evita que los atacantes ingresen a su teléfono, pero asegura que una vez allí puedan hacer la menor cantidad 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 errores de seguridad que abrirían 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 proporciona con SELinux en modo "Permisivo" de manera predeterminada, esto probablemente significa que la política que contiene no es lo suficientemente confiable como para cambiarse de manera segura al modo "Aplicar".

Si eres lo suficientemente aficionado a la tecnología y tienes acceso al registro del teléfono ( dmesgal menos, pero por lo general también se copian logcat: hay aplicaciones que permiten ver este último, pero dependiendo de tu versión de Android pueden requerir acceso de root), puedes verificar si encuentra entradas "avc": estos son mensajes que le indican que SELinux acaba de detectar una acción que va en contra de la política.

Aquí hay un ejemplo de tal entrada tomada del 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, solo unos pocos o por alguna razón cree que no le impedirán usar el teléfono, puede intentar cambiar SELinux al modo "Aplicar". En las ROM de CyanogenMod más antiguas, esto era fácil y posible simplemente usando una opción oculta en la GUI (no es necesario rootear el teléfono ni instalar ninguna aplicación específica), no sé si otras ROM ofrecían la misma función, pero como usaste el CyanogenMod etiqueta Supongo que puedes tener suerte ;).