Implementa SELinux

SELinux está configurado para denegar de forma predeterminada, lo que significa que la política debe permitir explícitamente cada acceso para el que tiene un hook en el kernel. Esto significa que un archivo de política se compone de una gran cantidad de información sobre reglas, tipos, clases, permisos y mucho más. El análisis completo de SELinux está fuera del alcance de este documento, pero comprender cómo escribir reglas de política es esencial cuando se usan dispositivos Android nuevos. Ya hay mucha información disponible sobre SELinux. Consulta Documentación de asistencia para obtener recursos sugeridos.

Archivos clave

Para habilitar SELinux, integra el kernel de Android más reciente y, luego, incorpora los archivos que se encuentran en el directorio system/sepolicy. Cuando se compilan, esos archivos comprenden la política de seguridad del kernel de SELinux y abarcan el sistema operativo Android upstream.

En general, no debes modificar los archivos system/sepolicy directamente. En su lugar, agrega o edita tus propios archivos de política específicos del dispositivo en el /device/manufacturer/device-name/sepolicy directorio. En Android 8.0 y versiones posteriores, los cambios que realices en estos archivos solo deberían afectar la política en tu directorio de proveedores. Para obtener más detalles sobre la separación de la sepolicy pública en Android 8.0 y versiones posteriores, consulta Cómo personalizar SEPolicy en Android 8.0 y versiones posteriores. Independientemente de la versión de Android, sigues modificando estos archivos:

Archivos de política

Los archivos que terminan con *.te son archivos fuente de política de SELinux, que definen dominios y sus etiquetas. Es posible que debas crear archivos de política nuevos en /device/manufacturer/device-name/sepolicy, pero debes intentar actualizar los archivos existentes siempre que sea posible.

Archivos de contexto

Los archivos de contexto son donde especificas etiquetas para tus objetos.

  • file_contexts asigna etiquetas a los archivos y es utilizado por varios componentes del espacio de usuario. A medida que creas políticas nuevas, crea o actualiza este archivo para asignar etiquetas nuevas a los archivos. Para aplicar file_contexts, vuelve a compilar la imagen del sistema de archivos o ejecuta restorecon en el archivo que se volverá a etiquetar. En las actualizaciones, los cambios en file_contexts se aplican automáticamente a las particiones del sistema y de datos del usuario como parte de la actualización. Los cambios también se pueden aplicar automáticamente en la actualización a otras particiones agregando llamadas restorecon_recursive a tu archivo init.board.rc después de que la partición se haya activado en modo de lectura y escritura.
  • genfs_contexts asigna etiquetas a los sistemas de archivos, como proc o vfat que no admiten atributos extendidos. Esta configuración se carga como parte de la política del kernel, pero es posible que los cambios no entren en vigencia para los inodos del núcleo, lo que requiere un reinicio o la desactivación y la reactivación del sistema de archivos para aplicar el cambio por completo. También se pueden asignar etiquetas específicas a activaciones específicas, como vfat con la opción context=mount.
  • property_contexts asigna etiquetas a las propiedades del sistema Android para controlar qué procesos pueden configurarlas. El proceso init lee esta configuración durante el inicio.
  • service_contexts asigna etiquetas a los servicios de binder de Android para controlar qué procesos pueden agregar (registrar) y encontrar (buscar) una referencia de binder para el servicio. El proceso servicemanager lee esta configuración durante el inicio.
  • seapp_contexts asigna etiquetas a los procesos de la app y a los directorios /data/data. El proceso zygote lee esta configuración en cada inicio de la app y installd durante el inicio.
  • mac_permissions.xml asigna una etiqueta seinfo a las apps según su firma y, de manera opcional, su nombre de paquete. Luego, la seinfo etiqueta se puede usar como clave en el seapp_contexts archivo para asignar una etiqueta específica a todas las apps con esa seinfo etiqueta. Esta configuración es leída por system_server durante el inicio.
  • keystore2_key_contexts asigna etiquetas a los espacios de nombres de Keystore 2. Estos espacios de nombres son aplicados por el daemon keystore2. Keystore siempre proporcionó espacios de nombres basados en UID/AID. Keystore 2 también aplica espacios de nombres definidos por sepolicy. Puedes encontrar una descripción detallada del formato y las convenciones de este archivo aquí.

Makefile BoardConfig.mk

Después de editar o agregar archivos de política y contexto, actualiza tu /device/manufacturer/device-name/BoardConfig.mk makefile para hacer referencia al sepolicy subdirectorio y a cada archivo de política nuevo. Para obtener más información sobre las variables BOARD_SEPOLICY, consulta el archivo system/sepolicy/README.

BOARD_SEPOLICY_DIRS += \
        <root>/device/manufacturer/device-name/sepolicy

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

Después de la recompilación, tu dispositivo se habilita con SELinux. Ahora puedes personalizar tus políticas de SELinux para adaptarlas a tus propias adiciones al sistema operativo Android, como se describe en Personalización, o verificar tu configuración existente, como se explica en Validación.

Cuando los archivos de política nuevos y las actualizaciones de BoardConfig.mk estén en su lugar, la nueva configuración de política se incorporará automáticamente al archivo de política del kernel final. Para obtener más información sobre cómo se compila sepolicy en el dispositivo, consulta Cómo compilar sepolicy.

Implementación

Para comenzar a usar SELinux, haz lo siguiente:

  1. Habilita SELinux en el kernel: CONFIG_SECURITY_SELINUX=y
  2. Cambia el parámetro kernel_cmdline o bootconfig de modo que: 
    BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
     o 
    BOARD_BOOTCONFIG := androidboot.selinux=permissive
     Esto es solo para el desarrollo inicial de la política del dispositivo. Después de tener una política de bootstrap inicial, quita este parámetro para que tu dispositivo aplique o falle CTS.
  3. Inicia el sistema en modo permisivo y observa qué denegaciones se encuentran en el inicio:
    En Ubuntu 14.04 o versiones posteriores: 
    adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy
    En Ubuntu 12.04: 
    adb pull /sys/fs/selinux/policy
adb logcat -b all | audit2allow -p policy
  4. Evalúa el resultado para detectar advertencias que se parezcan a init: Warning! Service name needs a SELinux domain defined; please fix! Consulta Validación para obtener instrucciones y herramientas.
  5. Identifica dispositivos y otros archivos nuevos que necesiten etiquetado.
  6. Usa etiquetas existentes o nuevas para tus objetos. Consulta los *_contexts archivos para ver cómo se etiquetaron anteriormente y usa el conocimiento de los significados de las etiquetas para asignar una nueva. Lo ideal es que sea una etiqueta existente que se ajuste a la política, pero, a veces, se necesita una etiqueta nueva y se requieren reglas para acceder a esa etiqueta. Agrega tus etiquetas a los archivos de contexto adecuados.
  7. Identifica los dominios o procesos que deberían tener sus propios dominios de seguridad. Es probable que debas escribir una política completamente nueva para cada uno. Por ejemplo, todos los servicios generados a partir de init, deberían tener el suyo. Los siguientes comandos ayudan a revelar los que permanecen en ejecución (pero TODOS servicios necesitan ese tratamiento):
    adb shell su -c ps -Z | grep init

    adb shell su -c dmesg | grep 'avc: '
  8. Revisa init.device.rc para identificar los dominios que no tienen un tipo de dominio. Dales un dominio temprano en tu proceso de desarrollo para evitar agregar reglas a init o confundir los accesos init con los que están en su propia política.
  9. Configura BOARD_CONFIG.mk para usar BOARD_SEPOLICY_* variables. Consulta el archivo README en system/sepolicy para obtener detalles sobre la configuración.
  10. Examina el archivo init.device.rc y fstab.device y asegúrate de que cada uso de mount corresponda a un sistema de archivos etiquetado correctamente o que se especifique una opción context= mount.
  11. Revisa cada denegación y crea una política de SELinux para controlar cada una de forma adecuada. Consulta los ejemplos en Personalización.

Debes comenzar con las políticas en AOSP y, luego, desarrollarlas para tus propias personalizaciones. Para obtener más información sobre la estrategia de políticas y un análisis más detallado de algunos de estos pasos, consulta Cómo escribir políticas de SELinux.

Casos de uso

Estos son ejemplos específicos de vulnerabilidades que debes tener en cuenta cuando creas tu propio software y las políticas de SELinux asociadas:

Vínculos simbólicos: Debido a que los vínculos simbólicos aparecen como archivos, a menudo se leen como archivos, lo que puede generar vulnerabilidades. Por ejemplo, algunos componentes con privilegios, como init, cambian los permisos de ciertos archivos, a veces para que sean demasiado abiertos.

Luego, los atacantes pueden reemplazar esos archivos con vínculos simbólicos al código que controlan, lo que les permite sobrescribir archivos arbitrarios. Sin embargo, si sabes que tu app nunca atraviesa un vínculo simbólico, puedes prohibir que lo haga con SELinux.

Archivos del sistema: Considera la clase de archivos del sistema que solo debe modificar el servidor del sistema. Aun así, como netd, init y vold se ejecutan como raíz, pueden acceder a esos archivos del sistema. Por lo tanto, si netd se viera comprometido, podría comprometer esos archivos y, potencialmente, el servidor del sistema.

Con SELinux, puedes identificar esos archivos como archivos de datos del servidor del sistema. Por lo tanto, el único dominio que tiene acceso de lectura y escritura a ellos es el servidor del sistema. Incluso si netd se viera comprometido, no podría cambiar los dominios al dominio del servidor del sistema y acceder a esos archivos del sistema, aunque se ejecute como raíz.

Datos de la app: Otro ejemplo es la clase de funciones que deben ejecutarse como raíz, pero no deben acceder a los datos de la app. Esto es increíblemente útil, ya que se pueden hacer aserciones de gran alcance, como la prohibición de que ciertos dominios no relacionados con los datos de la app accedan a Internet.

setattr: Para comandos como chmod y chown, puedes identificar el conjunto de archivos en los que el dominio asociado puede realizar setattr. Cualquier elemento fuera de eso podría estar prohibido por estos cambios, incluso por la raíz. Por lo tanto, una app podría ejecutar chmod y chown en los archivos etiquetados como app_data_files, pero no shell_data_files ni system_data_files.