Compatibilidad de políticas

En esta página, se describe cómo Android controla los problemas de compatibilidad de políticas con las actualizaciones de la plataforma inalámbricas (OTA), en las que los nuevos parámetros de configuración de SELinux de la plataforma pueden diferir de los parámetros de configuración de SELinux del proveedor anteriores.

Propiedad y etiquetado de objetos

La propiedad debe definirse claramente para cada objeto y mantener separadas las políticas de la plataforma y del proveedor. Por ejemplo, si las etiquetas de política del proveedor son /dev/foo y las etiquetas de política de la plataforma son /dev/foo en una OTA posterior, se produce un comportamiento indefinido, como un rechazo inesperado o, lo que es más grave, una falla de arranque. En el caso de SELinux, esto se manifiesta como una colisión de etiquetado. El nodo del dispositivo solo puede tener una etiqueta que se resuelva en la etiqueta que se aplicó por última vez. Resultado:

  • Los procesos que necesitan acceso a la etiqueta que no se aplicó correctamente pierden el acceso al recurso.
  • Los procesos que obtienen acceso al archivo podrían fallar porque se creó el nodo de dispositivo incorrecto.

Pueden producirse colisiones entre las etiquetas de la plataforma y las del proveedor para cualquier objeto que tenga una etiqueta de SELinux, incluidas las propiedades, los servicios, los procesos, los archivos y los sockets. Para evitar estos problemas, define claramente la propiedad de estos objetos.

Espacio de nombres de tipo o atributo

Además de las colisiones de etiquetas, también pueden producirse colisiones de nombres de atributos y tipos de SELinux. SELinux no permite varias declaraciones de los mismos tipos y atributos. No se puede compilar una política con declaraciones duplicadas. Para evitar conflictos de nombres de tipos y atributos, se recomienda que todas las declaraciones de proveedores comiencen con el prefijo vendor_. Por ejemplo, los proveedores deben usar type vendor_foo, domain; en lugar de type foo, domain;.

Propiedad del archivo

Evitar colisiones de archivos es un desafío porque la política de la plataforma y del proveedor suelen proporcionar etiquetas para todos los sistemas de archivos. A diferencia de la asignación de nombres de tipos, la asignación de espacios de nombres de archivos no es práctica, ya que muchos de ellos son creados por el kernel. Para evitar estas colisiones, sigue las instrucciones de nomenclatura para los sistemas de archivos que se indican en esta sección. En Android 8.0, estas son recomendaciones sin aplicación técnica. En el futuro, estas recomendaciones se aplicarán con el conjunto de pruebas de proveedores (VTS).

Sistema (/system)

Solo la imagen del sistema debe proporcionar etiquetas para los componentes /system a través de file_contexts, service_contexts, etcétera. Si se agregan etiquetas para los componentes /system en la política del proveedor, es posible que no se pueda realizar una actualización inalámbrica solo del framework.

Vendor (/vendor)

La política de SELinux del AOSP ya etiqueta partes de la partición vendor con la que interactúa la plataforma, lo que permite escribir reglas de SELinux para que los procesos de la plataforma puedan comunicarse o acceder a partes de la partición vendor. Ejemplos:

/vendor path Etiqueta proporcionada por la plataforma Procesos de la plataforma según la etiqueta
/vendor(/.*)? vendor_file Todos los clientes de HAL en el framework, ueventd, etcétera
/vendor/framework(/.*)? vendor_framework_file dex2oat, appdomain, etcétera
/vendor/app(/.*)? vendor_app_file dex2oat, installd, idmap, etcétera
/vendor/overlay(/.*) vendor_overlay_file system_server, zygote, idmap, etcétera

Como resultado, se deben seguir reglas específicas (que se aplican a través de neverallows) cuando se etiquetan archivos adicionales en la partición vendor:

  • vendor_file debe ser la etiqueta predeterminada para todos los archivos de la partición vendor. La política de la plataforma requiere esto para acceder a las implementaciones de HAL de transferencia.
  • Todos los exec_types nuevos que se agreguen en la partición vendor a través de la política del proveedor deben tener el atributo vendor_file_type. Esto se aplica a través de neverallows.
  • Para evitar conflictos con futuras actualizaciones de la plataforma o el framework, no etiquetes archivos que no sean exec_types en la partición vendor.
  • Todas las dependencias de biblioteca para los HALs del mismo proceso identificados por el AOSP deben etiquetarse como same_process_hal_file..

Procfs (/proc)

Los archivos de /proc solo se pueden etiquetar con la etiqueta genfscon. En Android 7.0, tanto la política de plataforma como la de proveedor usaban genfscon para etiquetar archivos en procfs.

Recomendación: Solo etiquetas de políticas de la plataforma /proc. Si los procesos del proveedor necesitan acceso a archivos en /proc que actualmente están etiquetados con la etiqueta predeterminada (proc), la política del proveedor no debe etiquetarlos de forma explícita y, en su lugar, debe usar el tipo genérico proc para agregar reglas para los dominios del proveedor. Esto permite que las actualizaciones de la plataforma admitan futuras interfaces del kernel expuestas a través de procfs y las etiqueten explícitamente según sea necesario.

Debugfs (/sys/kernel/debug)

Debugfs se puede etiquetar en file_contexts y genfscon. En Android 7.0 a Android 10, tanto la plataforma como la etiqueta del proveedor son debugfs.

En Android 11, no se puede acceder a debugfs ni activarlo en dispositivos de producción. Los fabricantes de dispositivos deben quitar debugfs.

Tracefs (/sys/kernel/debug/tracing)

Tracefs se puede etiquetar en file_contexts y genfscon. En Android 7.0, solo las etiquetas de la plataforma tracefs.

Recomendación: Solo la plataforma puede etiquetar tracefs.

Sysfs (/sys)

Los archivos en /sys se pueden etiquetar con file_contexts y genfscon. En Android 7.0, tanto la plataforma como el proveedor usan genfscon para etiquetar archivos en sysfs.

Recomendación: Es posible que la plataforma etiquete los nodos sysfs que no son específicos para el dispositivo. De lo contrario, solo el proveedor puede etiquetar los archivos.

tmpfs (/dev)

Los archivos de /dev pueden etiquetarse en file_contexts. En Android 7.0, tanto la plataforma como los archivos de etiquetas del proveedor se encuentran aquí.

Recomendación: El proveedor puede etiquetar solo los archivos en /dev/vendor (por ejemplo, /dev/vendor/foo, /dev/vendor/socket/bar).

Rootfs (/)

Los archivos de / pueden etiquetarse en file_contexts. En Android 7.0, se encuentran aquí los archivos de etiquetas de la plataforma y del proveedor.

Recomendación: Solo el sistema puede etiquetar archivos en /.

Datos (/data)

Los datos se etiquetan a través de una combinación de file_contexts y seapp_contexts.

Recomendación: No permitas el etiquetado de proveedores fuera de /data/vendor. Solo la plataforma puede etiquetar otras partes de /data.

Versión de etiquetas de Genfs

A partir del nivel de API del proveedor 202504, las etiquetas de SELinux más recientes asignadas con genfscon en system/sepolicy/compat/plat_sepolicy_genfs_ver.cil son opcionales para las particiones vendor anteriores. Esto permite que las particiones vendor más antiguas conserven su implementación existente de SEPolicy. Esto se controla con la variable BOARD_GENFS_LABELS_VERSION de Makefile, que se almacena en /vendor/etc/selinux/genfs_labels_version.txt.

Ejemplo:

  • En el nivel de API del proveedor 202404, el nodo /sys/class/udc se etiqueta como sysfs de forma predeterminada.
  • A partir del nivel de API del proveedor 202504, /sys/class/udc se etiqueta como sysfs_udc.

Sin embargo, es posible que /sys/class/udc esté en uso por particiones de vendor que usan el nivel de API 202404, ya sea con la etiqueta sysfs predeterminada o una etiqueta específica del proveedor. Etiquetar /sys/class/udc como sysfs_udc de forma incondicional podría interrumpir la compatibilidad con estas particiones de vendor. Si marcas BOARD_GENFS_LABELS_VERSION, la plataforma seguirá usando las etiquetas y los permisos anteriores para las particiones vendor más antiguas.

BOARD_GENFS_LABELS_VERSION puede ser mayor o igual que el nivel de API del proveedor. Por ejemplo, las particiones vendor que usan el nivel de API 202404 pueden establecer BOARD_GENFS_LABELS_VERSION en 202504 para adoptar las nuevas etiquetas introducidas en 202504. Consulta la lista de etiquetas de genfs específicas para 202504.

Cuando se etiquetan los nodos genfscon, la plataforma debe tener en cuenta las particiones vendor anteriores y, cuando sea necesario, implementar mecanismos de resguardo para garantizar la compatibilidad. La plataforma puede usar bibliotecas exclusivas de la plataforma para consultar la versión de las etiquetas de genfs.

Política pública de la plataforma

La política de SELinux de la plataforma se divide en privada y pública. La política pública de la plataforma consta de tipos y atributos que siempre están disponibles para un nivel de API del proveedor y que actúan como una API entre la plataforma y el proveedor. Esta política se expone a los redactores de políticas de proveedores para permitir que estos creen archivos de políticas de proveedores que, cuando se combinan con la política privada de la plataforma, dan como resultado una política completamente funcional para un dispositivo. La política pública de la plataforma se define en system/sepolicy/public.

Por ejemplo, un tipo vendor_init, que representa el proceso de inicialización en el contexto del proveedor, se define en system/sepolicy/public/vendor_init.te: 

type vendor_init, domain;

Los proveedores pueden consultar el tipo vendor_init para escribir reglas de políticas personalizadas: 

# Allow vendor_init to set vendor_audio_prop in vendor's init scripts
set_prop(vendor_init, vendor_audio_prop)

Atributos de compatibilidad

La política de SELinux es una interacción entre los tipos de origen y de destino para clases y permisos de objetos específicos. Cada objeto (por ejemplo, procesos, archivos) afectado por la política de SELinux solo puede tener un tipo, pero ese tipo puede tener varios atributos.

La política se escribe principalmente en términos de tipos existentes. Aquí, tanto vendor_init como debugfs son tipos: 

allow vendor_init debugfs:dir { mounton };

Esto funciona porque la política se escribió con conocimiento de todos los tipos. Sin embargo, si la política del proveedor y la política de la plataforma usan tipos específicos, y la etiqueta de un objeto específico cambia en solo una de esas políticas, es posible que la otra contenga una política que haya obtenido o perdido el acceso en el pasado. Por ejemplo, supongamos que la política de la plataforma etiqueta los nodos de sysfs como sysfs: 

/sys(/.*)? u:object_r:sysfs:s0

La política de proveedores otorga acceso a /sys/usb, etiquetado como sysfs: 

allow vendor_init sysfs:chr_file rw_file_perms;

Si la política de la plataforma se cambia para etiquetar /sys/usb como sysfs_usb, la política del proveedor sigue siendo la misma, pero vendor_init pierde el acceso a /sys/usb debido a la falta de política para el nuevo tipo sysfs_usb: 

/sys/usb u:object_r:sysfs_usb:s0

Para resolver este problema, Android introduce el concepto de atributos versionados. En el tiempo de compilación, el sistema de compilación traduce automáticamente los tipos públicos de la plataforma que se usan en la política del proveedor a estos atributos con versiones. Esta traducción se habilita a través de archivos de asignación que asocian un atributo versionado con uno o más tipos públicos de la plataforma.

Por ejemplo, supongamos que /sys/usb se etiqueta como sysfs en la política de la plataforma 202504, y la política del proveedor 202504 otorga acceso de vendor_init a /sys/usb. En este caso, sería así:

  • La política del proveedor escribe una regla allow vendor_init sysfs:chr_file rw_file_perms;, ya que /sys/usb se etiqueta como sysfs en la política de la plataforma de 202504. Cuando el sistema de compilación compila la política del proveedor, traduce automáticamente la regla a allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms;. Los atributos vendor_init_202504 y sysfs_202504 corresponden a los tipos vendor_init y sysfs, que son los tipos definidos por la plataforma.
  • El sistema de compilación genera un archivo de asignación de identidad /system/etc/selinux/mapping/202504.cil. Como las particiones system y vendor usan la misma versión de 202504, el archivo de asignación contiene asignaciones de identidad de type_202504 a type. Por ejemplo, vendor_init_202504 se asigna a vendor_init y sysfs_202504 se asigna a sysfs: 
    (typeattributeset sysfs_202504 (sysfs))
(typeattributeset vendor_init_202504 (vendor_init))
...

Cuando la versión se actualiza de 202504 a 202604, se crea un nuevo archivo de asignación para las particiones de 202504 en system/sepolicy/private/compat/202504/202504.cil, que se instala en /system/etc/selinux/mapping/202504.cil para las particiones de 202604 o system más recientes.vendor Inicialmente, este archivo de asignación contiene asignaciones de identidad, como se describió anteriormente. Si se agrega una etiqueta nueva sysfs_usb para /sys/usb a la política de la plataforma 202604, se actualiza el archivo de asignación para asignar sysfs_202504 a sysfs_usb: 

(typeattributeset sysfs_202504 (sysfs sysfs_usb))
(typeattributeset vendor_init_202504 (vendor_init))
...

Esta actualización permite que la regla de política del proveedor convertida allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms; otorgue automáticamente acceso de vendor_init al nuevo tipo sysfs_usb.

Para mantener la compatibilidad con particiones vendor anteriores, cada vez que se agrega un nuevo tipo público, ese tipo debe asignarse a, al menos, uno de los atributos versionados en el archivo de asignación system/sepolicy/private/compat/ver/ver.cil, o bien debe aparecer en system/sepolicy/private/compat/ver/ver.ignore.cil para indicar que no hay ningún tipo coincidente en las versiones anteriores del proveedor.

La combinación de la política de la plataforma, la política del proveedor y el archivo de asignación permite que el sistema se actualice sin actualizar la política del proveedor. Además, la conversión a los atributos versionados se realiza automáticamente, por lo que la política del proveedor no necesita ocuparse del versionado y sigue usando los tipos públicos tal como están.

Política pública del sistema_ext y del producto

A partir de Android 11, las particiones system_ext y product pueden exportar sus tipos públicos designados a la partición vendor. Al igual que la política pública de la plataforma, la política del proveedor usa tipos y reglas que se traducen automáticamente en los atributos versionados, por ejemplo, de type a type_ver, donde ver es el nivel de la API del proveedor de la partición vendor.

Cuando las particiones system_ext y product se basan en la misma versión de la plataforma ver, el sistema de compilación genera archivos de asignación base para system_ext/etc/selinux/mapping/ver.cil y product/etc/selinux/mapping/ver.cil, que contienen asignaciones de identidad de type a type_ver. La política del proveedor puede acceder a type con el atributo con versión type_ver.

En el caso de que solo se actualicen las particiones system_ext y product, por ejemplo, de ver a ver+1 (o posterior), mientras que la partición vendor permanece en ver, es posible que la política del proveedor pierda el acceso a los tipos de las particiones system_ext y product. Para evitar interrupciones, las particiones system_ext y product deben proporcionar archivos de asignación de tipos concretos a atributos type_ver. Cada socio es responsable de mantener los archivos de asignación si admite la partición ver vendor con las particiones ver+1 (o posterior) system_ext y product.

Para instalar archivos de asignación en las particiones system_ext y product, se espera que los implementadores o proveedores de dispositivos hagan lo siguiente:

  1. Copia los archivos de asignación base generados desde las particiones ver, system_ext y product a su árbol de origen.
  2. Modifica los archivos de asignación según sea necesario.
  3. Instala los archivos de asignación en las particiones ver+1 (o posterior) system_ext y product.

Por ejemplo, supongamos que la partición 202504 system_ext tiene un tipo público llamado foo_type. Luego, system_ext/etc/selinux/mapping/202504.cil en la partición 202504 system_ext se ve de la siguiente manera: 

(typeattributeset foo_type_202504 (foo_type))
(expandtypeattribute foo_type_202504 true)
(typeattribute foo_type_202504)

Si se agrega bar_type a la partición system_ext de 202604 y bar_type se debe asignar a foo_type para la partición vendor de 202504, se puede actualizar 202504.cil de (typeattributeset foo_type_202504 (foo_type)) a (typeattributeset foo_type_202504 (foo_type bar_type)) y, luego, instalarlo en la partición system_ext de 202604. La partición 202504 de vendor puede seguir accediendo a foo_type y bar_type de system_ext de 202604.

Cambios en los atributos para Android 9

Los dispositivos que se actualizan a Android 9 pueden usar los siguientes atributos, pero los dispositivos que se lanzan con Android 9 no deben hacerlo.

Atributos del infractor

Android 9 incluye los siguientes atributos relacionados con el dominio:

  • data_between_core_and_vendor_violators. Es un atributo para todos los dominios que incumplen el requisito de no compartir archivos por ruta de acceso entre vendor y coredomains. Los procesos de la plataforma y del proveedor no deben usar archivos en el disco para comunicarse (ABI inestable). Recomendación:
    • El código del proveedor debe usar /data/vendor.
    • El sistema no debe usar /data/vendor.
  • system_executes_vendor_violators. Atributo para todos los dominios del sistema (excepto init y shell domains) que incumplen el requisito de no ejecutar archivos binarios del proveedor. La ejecución de los archivos binarios del proveedor tiene una API inestable. La plataforma no debe ejecutar archivos binarios del proveedor directamente. Recomendación:
    • Estas dependencias de la plataforma en los objetos binarios del proveedor deben estar detrás de las HAL de HIDL.

      O BIEN

    • coredomains que necesitan acceso a los archivos binarios del proveedor deben moverse a la partición vendor y, por lo tanto, dejar de ser coredomain.

Atributos no confiables

Las apps no confiables que alojan código arbitrario no deben tener acceso a los servicios de HwBinder, excepto aquellos que se consideran lo suficientemente seguros para el acceso desde dichas apps (consulta los servicios seguros a continuación). Las dos razones principales son las siguientes:

  1. Los servidores de HwBinder no realizan la autenticación del cliente porque HIDL actualmente no expone información del UID de la entidad llamadora. Incluso si HIDL expusiera esos datos, muchos servicios de HwBinder operan a un nivel inferior al de las apps (como los HAL) o no deben depender de la identidad de la app para la autorización. Por lo tanto, para mayor seguridad, la suposición predeterminada es que cada servicio de HwBinder trata a todos sus clientes como igualmente autorizados para realizar las operaciones que ofrece el servicio.
  2. Los servidores HAL (un subconjunto de servicios de HwBinder) contienen código con una mayor tasa de incidencia de problemas de seguridad que los componentes de system/core y tienen acceso a las capas inferiores de la pila (hasta el hardware), lo que aumenta las oportunidades de eludir el modelo de seguridad de Android.

Servicios seguros

Los servicios seguros incluyen lo siguiente:

  • same_process_hwservice. Estos servicios (por definición) se ejecutan en el proceso del cliente y, por lo tanto, tienen el mismo acceso que el dominio del cliente en el que se ejecuta el proceso.
  • coredomain_hwservice. Estos servicios no presentan riesgos asociados con el motivo núm. 2.
  • hal_configstore_ISurfaceFlingerConfigs. Este servicio está diseñado específicamente para que lo use cualquier dominio.
  • hal_graphics_allocator_hwservice. Estas operaciones también las ofrece el servicio de Binder surfaceflinger, al que las apps tienen permiso para acceder.
  • hal_omx_hwservice: Es una versión de HwBinder del servicio de Binder mediacodec, al que las apps pueden acceder.
  • hal_codec2_hwservice, que es una versión más reciente de hal_omx_hwservice.

Atributos utilizables

Todos los hwservices que no se consideran seguros tienen el atributo untrusted_app_visible_hwservice. Los servidores HAL correspondientes tienen el atributo untrusted_app_visible_halserver. Los dispositivos que se lancen con Android 9 NO DEBEN usar ninguno de los atributos untrusted.

Recomendación:

  • En cambio, las apps no confiables deben comunicarse con un servicio del sistema que se comunique con el HAL de HIDL del proveedor. Por ejemplo, las apps pueden hablar con binderservicedomain y, luego, mediaserver (que es un binderservicedomain) habla con hal_graphics_allocator.

    O BIEN

  • Las apps que necesitan acceso directo a los HAL de vendor deben tener su propio dominio de sepolicy definido por el proveedor.

Pruebas de atributos de archivos

Android 9 incluye pruebas de tiempo de compilación que garantizan que todos los archivos en ubicaciones específicas tengan los atributos apropiados (por ejemplo, todos los archivos en sysfs tienen el atributo sysfs_type requerido).

Etiquetado de contextos de SELinux

Para admitir la distinción entre la sepolicy de la plataforma y la del proveedor, el sistema compila los archivos de contexto de SELinux de manera diferente para mantenerlos separados.

Contextos de archivos

Android 8.0 introdujo los siguientes cambios para file_contexts:

  • Para evitar una sobrecarga de compilación adicional en el dispositivo durante el inicio, file_contexts deja de existir en formato binario. En cambio, son archivos de texto de expresión regular legibles, como {property, service}_contexts (como eran antes de la versión 7.0).
  • Los file_contexts se dividen en dos archivos:
    • plat_file_contexts
      • Plataforma de Android file_context que no tiene etiquetas específicas del dispositivo, excepto para etiquetar partes de la partición /vendor que deben etiquetarse con precisión para garantizar el funcionamiento adecuado de los archivos de sepolicy.
      • Debe residir en la partición system en /system/etc/selinux/plat_file_contexts en el dispositivo y init debe cargarlo al inicio junto con el file_context del proveedor.
    • vendor_file_contexts
      • file_context específico del dispositivo creado combinando file_contexts que se encuentra en los directorios a los que apunta BOARD_SEPOLICY_DIRS en los archivos Boardconfig.mk del dispositivo.
      • Debe instalarse en /vendor/etc/selinux/vendor_file_contexts en la partición vendor y init debe cargarlo al inicio junto con la file_context de la plataforma.

Contextos de propiedad

En Android 8.0, el archivo property_contexts se divide en dos archivos:

  • plat_property_contexts
    • property_context de la plataforma de Android que no tiene etiquetas específicas del dispositivo.
    • Debe residir en la partición system en /system/etc/selinux/plat_property_contexts y init debe cargarlo al inicio junto con property_contexts del proveedor.
  • vendor_property_contexts
    • property_context específico del dispositivo creado combinando property_contexts que se encuentra en los directorios a los que apunta BOARD_SEPOLICY_DIRS en los archivos Boardconfig.mk del dispositivo.
    • Debe residir en la partición vendor en /vendor/etc/selinux/vendor_property_contexts y init debe cargarlo al inicio junto con la plataforma property_context.

Contextos de servicio

En Android 8.0, el archivo service_contexts se divide en los siguientes archivos:

  • plat_service_contexts
    • service_context específico de la plataforma de Android para el servicemanager. El service_context no tiene etiquetas específicas del dispositivo.
    • Debe residir en la partición system en /system/etc/selinux/plat_service_contexts y servicemanager debe cargarlo al inicio junto con service_contexts del proveedor.
  • vendor_service_contexts
    • service_context específico del dispositivo creado combinando service_contexts que se encuentra en los directorios a los que apunta BOARD_SEPOLICY_DIRS en los archivos Boardconfig.mk del dispositivo.
    • Debe residir en la partición vendor en /vendor/etc/selinux/vendor_service_contexts y servicemanager debe cargarlo al inicio junto con service_contexts de la plataforma.
    • Aunque servicemanager busca este archivo durante el inicio, para un dispositivo TREBLE completamente compatible, el archivo vendor_service_contexts NO DEBE existir. Esto se debe a que todos los procesos de interacción entre vendor y system DEBEN pasar por hwservicemanager/hwbinder.
  • plat_hwservice_contexts
    • hwservice_context de la plataforma Android para hwservicemanager que no tiene etiquetas específicas del dispositivo.
    • Debe residir en la partición system en /system/etc/selinux/plat_hwservice_contexts y hwservicemanager debe cargarlo al inicio junto con vendor_hwservice_contexts.
  • vendor_hwservice_contexts
    • hwservice_context específico del dispositivo creado combinando hwservice_contexts que se encuentra en los directorios a los que apunta BOARD_SEPOLICY_DIRS en los archivos Boardconfig.mk del dispositivo.
    • Debe residir en la partición vendor en /vendor/etc/selinux/vendor_hwservice_contexts y hwservicemanager debe cargarlo al inicio junto con plat_service_contexts.
  • vndservice_contexts
    • service_context específico del dispositivo para el vndservicemanager compilado combinando vndservice_contexts que se encuentra en los directorios a los que apunta BOARD_SEPOLICY_DIRS en el Boardconfig.mk del dispositivo.
    • Este archivo debe residir en la partición vendor en /vendor/etc/selinux/vndservice_contexts y vndservicemanager debe cargarlo al inicio.

Contextos de Seapp

En Android 8.0, el archivo seapp_contexts se divide en dos archivos:

  • plat_seapp_contexts
    • seapp_context de la plataforma de Android que no tiene cambios específicos del dispositivo.
    • Debe residir en la partición system en /system/etc/selinux/plat_seapp_contexts..
  • vendor_seapp_contexts
    • Extensión específica del dispositivo para la plataforma seapp_context creada combinando seapp_contexts que se encuentra en los directorios a los que apunta BOARD_SEPOLICY_DIRS en los archivos Boardconfig.mk del dispositivo.
    • Debe residir en la partición vendor en /vendor/etc/selinux/vendor_seapp_contexts.

Permisos de MAC

En Android 8.0, el archivo mac_permissions.xml se divide en dos archivos:

  • Plataforma mac_permissions.xml
    • mac_permissions.xml de la plataforma de Android que no tiene cambios específicos del dispositivo.
    • Debe residir en la partición system en /system/etc/selinux/..
  • No es de la plataforma mac_permissions.xml
    • Extensión específica del dispositivo para la plataforma mac_permissions.xml compilada a partir de mac_permissions.xml que se encuentra en los directorios a los que apunta BOARD_SEPOLICY_DIRS en los archivos Boardconfig.mk del dispositivo.
    • Debe residir en la partición vendor en /vendor/etc/selinux/..