Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Implementando SELinux

SELinux está configurado para denegar por defecto, lo que significa que cada acceso para el que tiene un gancho en el kernel debe estar explícitamente permitido por la política. Esto significa que un archivo de política se compone de una gran cantidad de información sobre reglas, tipos, clases, permisos y más. Una consideración completa de SELinux está fuera del alcance de este documento, pero la comprensión de cómo escribir reglas de políticas es ahora esencial cuando se presentan nuevos dispositivos Android. Ya hay una gran cantidad de información disponible sobre SELinux. Ver Documentación de apoyo para los recursos sugeridos.

Archivos clave

Para activar SELinux, integrar la última Android kernel y luego incorporar los archivos encontrados en el sistema / sepolicy directorio. Cuando se compilan, esos archivos forman parte de la política de seguridad del kernel de SELinux y cubren el sistema operativo Android anterior.

En general, no debe modificar los system/sepolicy archivos directamente. En su lugar, añadir o editar sus propios archivos de políticas específicas del dispositivo en el /device/ manufacturer / device-name /sepolicy directorio. En Android 8.0 y versiones posteriores, los cambios que realice en estos archivos solo deberían afectar la política en su directorio de proveedores. Para más detalles sobre la separación de sepolicy pública en Android 8.0 y superior, consulte Personalización de SEPolicy en Android 8.0 o superior . Independientemente de la versión de Android, todavía está modificando estos archivos:

Archivos de política

Los archivos que terminan con *.te son archivos de origen política de SELinux, que definen los dominios y sus etiquetas. Es posible que necesite para crear nuevos archivos de política en /device/ manufacturer / device-name /sepolicy , pero usted debe tratar de actualizar los archivos existentes cuando 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 diversos componentes del espacio de usuario. A medida que crea nuevas políticas, cree o actualice este archivo para asignar nuevas etiquetas a los archivos. Para aplicar la nueva file_contexts , reconstruir la imagen del sistema de archivos o ejecutar restorecon en el archivo para ser re-etiquetado. En mejoras, cambios en file_contexts se aplican automáticamente al sistema y particiones userdata como parte de la actualización. Los cambios también se pueden aplicar de forma automática durante la actualización a otras particiones mediante la adición de restorecon_recursive llamadas a su inicio. board archivo .rc después de la partición ha sido montado de lectura-escritura.
  • genfs_contexts asigna etiquetas a los sistemas de archivos, tales como proc o vfat que no soportan atributos extendidos. Esta configuración se carga como parte de la política del kernel, pero es posible que los cambios no surtan efecto para los inodos en el núcleo, lo que requiere reiniciar o desmontar y volver a montar el sistema de archivos para aplicar completamente el cambio. Etiquetas específicas también pueden ser asignados a los montajes específicos, como vfat utilizando el context=mount opción.
  • property_contexts asigna etiquetas a las propiedades del sistema Android para controlar qué procesos pueden establecer ellos. Esta configuración es leído por el init del proceso durante el arranque.
  • service_contexts asigna etiquetas a los servicios de encuadernación con Android para controlar qué procesos pueden agregar (registro) y encontrar (de búsqueda) una referencia aglutinante para el servicio. Esta configuración es leído por el servicemanager proceso durante el arranque.
  • seapp_contexts asigna etiquetas a los procesos y aplicaciones /data/data directorios. Esta configuración es leído por el zygote proceso en cada lanzamiento de la aplicación y por installd durante el arranque.
  • mac_permissions.xml asigna un seinfo etiqueta para aplicaciones basados en su firma y, opcionalmente, su nombre de paquete. El seinfo etiqueta a continuación, se puede utilizar como una llave en la seapp_contexts archivo para asignar una etiqueta específica a todas las aplicaciones con las que seinfo etiqueta. Esta configuración es leída por system_server durante el arranque.

BoardConfig.mk makefile

Después de editar o añadir archivos de políticas y contexto, actualizar su /device/ manufacturer / device-name /BoardConfig.mk makefile para hacer referencia al sepolicy subdirectorio y cada archivo de política nueva. Para obtener más información acerca de los BOARD_SEPOLICY variables, consulte el system/sepolicy/README archivo .

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

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

Después de la reconstrucción, su dispositivo está habilitado con SELinux. Ahora puede personalizar cualquiera de sus políticas de SELinux para adaptarse a sus propias adiciones al sistema operativo Android, como se describe en la personalización o verificar su configuración actual como cubiertos en Validación .

Cuando los nuevos archivos de políticas y las actualizaciones de BoardConfig.mk están en su lugar, la nueva configuración de políticas se integra automáticamente en el archivo final de políticas del kernel. Para obtener más información acerca de cómo sepolicy se construye en el dispositivo, consulte sepolicy edificio .

Implementación

Para comenzar con SELinux:

  1. Habilitar SELinux en el kernel: CONFIG_SECURITY_SELINUX=y
  2. Cambiar el parámetro kernel_cmdline o bootconfig de modo que:
    BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
    o
    BOARD_BOOTCONFIG := androidboot.selinux=permissive
    Esto es sólo para el desarrollo inicial de la política para el dispositivo. Una vez que tenga una política de arranque inicial, elimine este parámetro para que su dispositivo se cumpla o fallará CTS.
  3. Arranque el sistema en permisivo y vea qué denegaciones se encuentran en el arranque:
    En Ubuntu 14.04 o más reciente:
    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. Evaluar la salida de las advertencias que se asemejan a init: Warning! Service name needs a SELinux domain defined; please fix! Ver Validación de instrucciones y herramientas.
  5. Identifique dispositivos y otros archivos nuevos que necesiten etiquetado.
  6. Utilice etiquetas nuevas o existentes para sus objetos. Vistazo a los *_contexts archivos para ver cómo las cosas fueron etiquetados con anterioridad y el uso del conocimiento de los significados de etiqueta para asignar una nueva. Idealmente, esta será una etiqueta existente que se ajustará a la política, pero a veces se necesitará una nueva etiqueta y se necesitarán reglas para acceder a esa etiqueta. Agregue sus etiquetas a los archivos de contexto apropiados.
  7. Identifique dominios / procesos que deberían tener sus propios dominios de seguridad. Es probable que deba redactar una política completamente nueva para cada uno. Todos los servicios de desovados init , por ejemplo, deben tener su propia. Los siguientes comandos ayudan a revelar aquellos que permanecen en ejecución (pero TODOS los servicios necesitan tal tratamiento):
    adb shell su -c ps -Z | grep init
    
    adb shell su -c dmesg | grep 'avc: '
    
  8. Revisar init. device .rc para identificar cualquier dominio que no tienen un tipo de dominio. Darles un dominio al principio de su proceso de desarrollo para evitar la adición de reglas a init o de otro modo confuso init accesos con los que están en su propia política.
  9. Puesta en marcha BOARD_CONFIG.mk utilizar BOARD_SEPOLICY_* variables. Ver el README en el system/sepolicy para obtener más información acerca de esta configuración.
  10. Examine el archivo init. device .rc y fstab. device de archivos y asegúrese de que todos los usos de mount corresponde a un sistema de ficheros debidamente etiquetados o que un context= mount opción se especifica.
  11. Revise cada negación y cree una política de SELinux para manejar cada una de manera adecuada. Ver los ejemplos de personalización .

Debe comenzar con las políticas en el AOSP y luego desarrollarlas para sus propias personalizaciones. Para obtener más información acerca de la estrategia política y un vistazo más de cerca a algunos de estos pasos, consulte la escritura política de SELinux .

Casos de uso

A continuación, se muestran ejemplos específicos de exploits a considerar al diseñar su propio software y las políticas de SELinux asociadas:

Enlaces simbólicos - Debido a que los enlaces simbólicos aparecen como archivos, a menudo se leen como archivos, que pueden conducir a exploits. Por ejemplo, algunos componentes privilegiados, tales como init , cambian los permisos de ciertos archivos, a veces a ser excesivamente abierto.

Los atacantes pueden reemplazar esos archivos con enlaces simbólicos al código que controlan, lo que permite al atacante sobrescribir archivos arbitrarios. Pero si sabe que su aplicación nunca atravesará un enlace simbólico, puede prohibirle que lo haga con SELinux.

Los archivos del sistema - Tenga en cuenta la clase de los archivos del sistema que debe ser modificada únicamente por el servidor del sistema. Aún así, ya que netd , init , y vold ejecutarse como root, pueden acceder a los archivos del sistema. Así que si netd quedó comprometida, podría poner en peligro esos archivos y potencialmente el propio servidor del sistema.

Con SELinux, puede identificar esos archivos como archivos de datos del servidor del sistema. Por lo tanto, el único dominio que tiene acceso de lectura / escritura a ellos es el servidor del sistema. Incluso si netd quedó comprometida, no podía cambiar de dominio en el dominio del servidor del sistema y acceder a los archivos del sistema a pesar de que se ejecuta como root.

Aplicación de datos - Otro ejemplo es la clase de funciones que se deben ejecutar como root pero no debe llegar a datos de aplicaciones de acceso. Esto es increíblemente útil ya que se pueden realizar afirmaciones de amplio alcance, como que se prohíba el acceso a Internet de ciertos dominios no relacionados con los datos de la aplicación.

setattr - Para los comandos tales como chmod y chown , se podía identificar el conjunto de archivos en el que el dominio asociado puede realizar setattr . Cualquier cosa fuera de eso podría estar prohibida por estos cambios, incluso por root. Así que una aplicación puede ejecutar chmod y chown contra esos etiquetados app_data_files pero no shell_data_files o system_data_files .