Android 4.3 y SELinux

Hace apenas algunas semanas Google publicó una nueva revisión de su abanderado sistema operativo móvil, Android 4.3. Aunque algunos dicen que esta vez las actualizaciones escasearon bastante, desde la perspectiva de la seguridad cibernética se han visto innegables mejoras, como es el caso de la vulnerabilidad “MasterKey”, que finalmente se reparó. Una de las mejoras más significativas es SELinux. Muchos saludaron este paso tan esperado, mientras que otros lo criticaron. En mi opinión, el impacto no es fácil de evaluar, especialmente en lo que se refiere a los beneficios para los usuarios. Para aclarar un poco el panorama analizaremos un poco más SELinux y su modelo de amenaza.

Android JellyBean 4.3 logo

Comencemos por lo básico: la seguridad de los sistemas Linux descansa en el concepto del control de acceso discrecional (DAC, por sus siglas en inglés), lo que significa que cada usuario decide a cuáles de sus propios archivos pueden acceder otros usuarios (lectura, escritura, o ejecución). El sistema está protegido contra alteraciones ya que todos los archivos del sistema pertenecen al usuario administrador conocido como ‘raíz’ (root).

Androide se fundamenta en los mismos conceptos, con una pequeña pero persuasiva adición: a cada aplicación se le asigna una ID de usuario diferente (aunque pueden darse algunas excepciones), por lo que los datos de la aplicación quedan aislados y protegidos de cualquier otra aplicación. Es por esta razón que en dispositivos que no tienen un usuario raíz resulta difícil, sino imposible, que una aplicación legítima robe los datos confidenciales utilizados por otra aplicación (salvo, obviamente, que la configuración de esos datos permita su acceso público para lectura).

SELinux se basa en eso (y en 15 años de investigación en seguridad del sistema operativo de NSA) e introduce otra capa de seguridad llamada Control de acceso obligatorio (MAC, por sus siglas en inglés). Esta capa, configurada por las amplias políticas del sistema, regula también la manera en que los usuarios (y por ende las aplicaciones en los dispositivos Android) acceden a sus datos y a los del sistema, siempre de forma transparente. En términos más técnicos, es posible diseñar políticas que sean capaces de especificar los tipos de interacciones que puede realizar o no un proceso configurado para ser parte de un contexto de seguridad. Un ejemplo sencillo pero eficaz es el caso de un system log daemon que se ejecuta con privilegios de raíz. Con SELinux podemos configurar todo el sistema de manera que el proceso no pueda acceder a nada salvo al archivo de registro: sólo hay que asignar una etiqueta específica al archivo de registro y escribir una política que permita al log daemon acceder sólo a aquellos archivos con dicha etiqueta (como siempre, tengamos en cuenta de que hay cosas un poco más complejas que esta 🙂 ). Observemos las dos ventajas que se desprenden de este esquema: (1) la política es algo que puede aplicarse a todo el sistema (incluyendo la raíz); (2) los permisos son mucho más específicos que los aplicados por el DAC.

La habilidad de limitar lo que el superusuario puede hacer (cualesquiera que sean sus privilegios), es esencial para proteger el sistema contra los ataques que se dan por falta de privilegios. En realidad es en esto en lo que sobresale SELinux. Tomemos el caso de Gingerbreak, un conocido exploit para obtener privilegios en los sistemas con Gingerbread. El exploit envía al volumen daemon (vold) un mensaje netlink cuidadosamente elaborado que se ejecuta como raíz. Gracias a la falta de algunas verificaciones de límites, el mensaje puede dar lugar a la inyección de códigos y su ejecución. Puesto que el proceso se ejecuta como raíz, es innecesario generar una consola con raíz setuid para controlar el dispositivo. SELinux detendría este exploit negando el mensaje mismo: la política por defecto (al menos en el paquete de parches original) niega la apertura de ese tipo de socket, por lo que el problema queda resuelto. Por si eso no fuese suficiente, otra política de SELinux también puede negar la ejecución de sistemas no binarios en ese proceso daemon.

¿No es asombroso? Por desgracia, la realidad es otra muy distinta. A la implementación de SELinux que actualmente se ejecuta en el stock de imágenes de Android 4.3 le faltan varias características importantes. En primer lugar, SELinux está configurado sólo en modo Permisivo, lo que significa que las políticas no se aplican, y las violaciones sólo quedan registradas (solo sirve para pruebas). En segundo lugar, como se mostró arriba, la actualización OTA no etiqueta correctamente la partición del sistema (mi dispositivo de pruebas me dejó muy confundido por un buen rato hasta que averigüé que el investigador Pau Oliva había publicado exactamente el mismo hallazgo en DEF CON 21), lo que significa que un desarrollador está obligado a restaurar el stock si quiere someterlo a pruebas. Finalmente, además del hecho de que las políticas provistas no son nada restrictivas, no existe un MAC para el middleware Android (una característica parte del paquete de parches de NSA).

¿Qué significa esto para el usuario final? Por desgracia, no mucho por el momento. A SELinux, tal como se ejecuta en Android 4.3, sólo se puede someter a prueba y desarrollar políticas para él. Tampoco existe una forma segura de aplicarlo. Ahora les toca intervenir a los fabricantes de dispositivos. Google alienta decididamente el desarrollo de implementaciones para SELinux (¿alguien que “traiga su propio dispositivo?”) que se basen en las funcionalidades del stock en lugar de en las mal ensambladas extensiones (revisa la charla en DEFCON 21 sobre lo que significan las "cuestiones de implementación”). Asimismo, se urge a los desarrolladores a familiarizarse con el paquete de políticas por defecto y a comprobar sus aplicaciones en busca de grietas. ¿Lograremos alguna vez ver una publicación de Android con el paquete SELinux con el modo aplicar? Esperemos que así sea 🙂