Como parte del modelo de seguridad de Android, este sistema operativo usa Security-Enhanced Linux (SELinux) para aplicar el control de acceso obligatorio (MAC) en todos los procesos, incluso en los que se ejecutan con privilegios de raíz o superusuario (funciones de Linux). Muchas empresas y organizaciones contribuyeron a la implementación de SELinux de Android. Con SELinux, Android puede proteger y confinar mejor los servicios del sistema, controlar el acceso a los datos de la aplicación y los registros del sistema, reducir los efectos del software malicioso y proteger a los usuarios de posibles fallas en el código de los dispositivos móviles.
SELinux funciona según el principio de denegación predeterminada: Se rechaza todo lo que no se permite de forma explícita. SELinux puede funcionar en dos modos globales:
- Modo permisivo, en el que se registran los rechazos de permisos, pero no se aplican.
- Modo de aplicación, en el que se registran y aplican los rechazos de permisos.
Android incluye SELinux en modo de aplicación forzosa y una política de seguridad correspondiente que funciona de forma predeterminada en AOSP. En el modo de aplicación, se impiden las acciones no permitidas y el kernel registra todos los intentos de incumplimiento en dmesg
y logcat
. Durante el desarrollo, debes usar estos errores para definir mejor tu software y las políticas de SELinux antes de aplicarlas. Para obtener más detalles, consulta Cómo implementar SELinux.
SELinux también admite un modo permisivo por dominio en el que se pueden establecer dominios (procesos) específicos como permisivos mientras se coloca el resto del sistema en modo de aplicación forzosa global. Un dominio es simplemente una etiqueta que identifica un proceso o un conjunto de procesos en la política de seguridad, en la que la política de seguridad trata de manera idéntica todos los procesos etiquetados con el mismo dominio. El modo permisivo por dominio habilita la aplicación incremental de SELinux a una parte cada vez mayor del sistema y el desarrollo de políticas para servicios nuevos (mientras se mantiene la aplicación forzosa del resto del sistema).
Información general
El modelo de seguridad de Android se basa en parte en el concepto de zonas de pruebas de aplicaciones. Cada aplicación se ejecuta en su propia zona de pruebas. Antes de Android 4.3, estas zonas de pruebas se definían mediante la creación de un UID de Linux único para cada aplicación en el momento de la instalación. Android 4.3 y versiones posteriores usan SELinux para definir mejor los límites de la zona de pruebas de aplicaciones de Android.
En Android 5.0 y versiones posteriores, SELinux se aplica por completo, en función de la versión permisiva de Android 4.3 y la aplicación parcial de Android 4.4.
Con este cambio, Android pasó de la aplicación forzosa en un conjunto limitado de dominios cruciales (installd
, netd
, vold
y zygote
) a todo (más de 60 dominios). Más precisamente:
- Todo está en modo de aplicación forzosa en Android 5.x y versiones posteriores.
- No se debe ejecutar ningún proceso que no sea
init
en el dominioinit
. - Cualquier denegación genérica (para un
block_device
,socket_device
,default_service
) indica que el dispositivo necesita un dominio especial.
Android 6.0 endureció el sistema reduciendo la permisividad de nuestra política para incluir un mejor aislamiento entre los usuarios, filtrado de IOCTL, reducción de la amenaza de servicios expuestos, mayor restricción de los dominios de SELinux y acceso /proc
extremadamente limitado.
Android 7.0 actualizó la configuración de SELinux para bloquear aún más la zona de pruebas de la aplicación y reducir la superficie de ataque. Esta versión también dividió la pila monolítica de MediaServer en procesos más pequeños para reducir el alcance de sus permisos. Para obtener más detalles, consulta Cómo proteger Android con más defensas del kernel de Linux y Endurecimiento de la pila de medios.
Android 8.0 actualizó SELinux para que funcione con Treble, que separa el código del proveedor de nivel inferior del framework del sistema Android. Esta versión actualizó la política de SELinux para permitir que los fabricantes de dispositivos y los proveedores de SOC actualicen sus partes de la política, compilen sus imágenes (vendor.img
, boot.img
, etc.) y, luego, las actualicen independientemente de la plataforma o viceversa.
Si bien es posible tener una versión más alta o más reciente de la plataforma (framework) que se ejecuta en el dispositivo, no se admite el caso opuesto; las imágenes del proveedor (vendor.img/odm.img
) no pueden tener una versión más reciente que la plataforma (system.img
). Por lo tanto, una versión más reciente de la plataforma podría generar problemas de compatibilidad con SELinux, ya que la política de SELinux de la plataforma tiene una versión más reciente que las partes de la política de SELinux del proveedor. El modelo de Android 8.0 proporciona un método para retener la compatibilidad y evitar actualizaciones OTA simultáneas innecesarias.
Recursos adicionales
Para obtener ayuda para crear políticas de SELinux útiles, consulta los siguientes recursos.
- The SELinux Notebook, una referencia actualizada de SELinux. En este documento, se incluyen detalles adicionales sobre el lenguaje de la política, el significado de cada una de las palabras clave y cómo se calculan los contextos de seguridad.
- Tu guía práctica visual para la aplicación forzosa de políticas de SELinux
- Mejoras de seguridad para Linux
- Android con seguridad mejorada (SE): Lleva MAC flexible a Android
- Implementa SELinux como un módulo de seguridad de Linux
- Configura la política de SELinux