He instalado una cierta ROM que viene con SELinux en modo "Permisivo". Esta es la única (buena) ROM que se ajusta correctamente a mi dispositivo y no hay forma de cambiar el estado de SELinux.

Ahora no estoy realmente seguro de cuáles son las consecuencias de tal decisión y sería feliz si alguien me lo pudiera explicar (lo busqué en Google y sé qué es teóricamente ... pero no en la práctica). Dicha ROM tiene su raíz en "deshabilitado", por lo que supuestamente el dispositivo está desrooteado, pero no estoy seguro de cómo encaja eso con el SELinux.

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 los usuarios privilegiados y no 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 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 en 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 interactivamente por un humano (generalmente un administrador del sistema) para mantener o reparar el dispositivo, pero generalmente esta cuenta será utilizada principalmente por servicios de fondo o de bajo nivel que requieren dicho nivel de privilegio: controladores de dispositivo, servicios de configuración de red, servicios necesidad de acceder a los archivos de todos los usuarios o manejar 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é pasaría si se encuentra un error en un servicio que se ejecuta como rootque 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 activarse enviando 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 los recursos privados correctamente? Luego, otros usuarios no privilegiados podrían acceder a estos recursos de forma malintencionada (leerlos, incluso modificarlos o eliminarlos). Esto suele ser lo que tiene cuando una aplicación maliciosa se está ejecutando en su teléfono (no importa si ha sido engañado para instalarla, o si llegó aquí por sí sola al usar un error en otra aplicación no privilegiada, un navegador o cliente de correo para instancia), 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 inaccesibles o para 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) a los usuarios privilegiados y no privilegiados.

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

1. Como dije, esta política también se aplica a usuarios privilegiados. Esto significa que, con una política diseñada adecuadamente, 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 de manejo de 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 recientemente incluyó una función multiusuario que es implementada por SELinux, evitando que cualquier usuario acceda a los datos de otro usuario. 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 utilizando el sistema DAC, SELinux vendrá al rescate y 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 otra manera 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 su situación: si no está en la política, 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 envío de Android SELinux lo incluyeron en modo "Permisivo" por defecto. En este modo, SELinux registrará violaciones de políticas, 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 restante son comportamientos maliciosos o no deseados. En este punto, SELinux puede convertirse en modo "obligatorio": ahora no solo registrará sino que también bloqueará todas las acciones ofensivas.

Conclusión

SELinux es una técnica de mitigación. No evita que los atacantes entren en su teléfono, pero asegura que una vez allí puedan hacer la menor cantidad de cosas posible, idealmente nada útil, lo que elimina el interés de atacar el teléfono en primer lugar.

Cuanto más antigua es la ROM, mayor es 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 forma predeterminada, esto probablemente significa que la política que contiene no es lo suficientemente confiable como para cambiar de manera segura al modo "Cumplimiento".

Si eres lo suficientemente técnico y tienes acceso al registro del teléfono ( dmesgal menos, pero generalmente también se copian en él logcat: hay aplicaciones que permiten ver el último, pero dependiendo de tu versión de Android pueden requerir acceso de root), puedes verificar si encontrará 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 dicha 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 algunos de ellos o, por alguna razón, cree que no pueden evitar que use el teléfono, puede intentar cambiar SELinux al modo "Forzar". En las ROM antiguas de CyanogenMod, esto era fácil y posible simplemente usando una opción oculta en la GUI (no es necesario rootear el teléfono o instalar ninguna aplicación específica), no sé si otras ROM ofrecieron la misma función, pero dado que usó CyanogenMod etiqueta, supongo que puede ser afortunado;).