Compatibilidad de políticas

En este artículo, se describe cómo Android aborda los problemas de compatibilidad de las políticas con actualizaciones inalámbricas de la plataforma, donde la nueva configuración de SELinux de la plataforma puede diferir de la del proveedor anterior Configuración de SELinux.

El diseño de la política de SELinux basado en Treble tiene en cuenta una distinción binaria. entre la política de plataforma y proveedor el esquema se convierte en puede ser más complicado si las particiones del proveedor generan dependencias, como platform < vendor < oem

En Android 8.0 y versiones posteriores, la política global de SELinux se divide en políticas componentes públicos. Los componentes públicos consisten en la política y sus infraestructura, que garantiza la disponibilidad para las versiones de la plataforma. Esta política se expondrá a los redactores de las políticas del proveedor para permitirles a los proveedores crear un archivo de políticas del proveedor, que, cuando se combina con la política proporcionada por la plataforma, se traduce en una política completamente funcional para un dispositivo.

• Para el control de versiones, la política exportada de la plataforma pública se escribirá de la siguiente manera: atributos.
• Para facilitar la escritura de políticas, los tipos exportados se transformarán en atributos con control de versiones como parte del proceso de compilación de políticas. Públicas también se pueden usar directamente en las decisiones de etiquetado proporcionadas por el proveedor contextos.

Android mantiene una asignación entre los tipos concretos exportados en la plataforma y los atributos con control de versiones correspondientes para cada plataforma versión. Esto garantiza que, cuando los objetos estén etiquetados con un tipo, no interrumpe el comportamiento garantizado por la política pública de la plataforma en una versión. Esta asignación se mantiene manteniendo un archivo de asignación actualizado para para cada versión de la plataforma, que conserva la información de membresía de los atributos de cada una. tipo exportado en la política pública.

Propiedad y etiquetado de objetos

Al personalizar la política en Android 8.0 y versiones posteriores, la propiedad debe definirse claramente. para cada objeto, a fin de mantener separados la política de la plataforma y la del proveedor. Por ejemplo, el proveedor etiqueta /dev/foo y, luego, la plataforma etiqueta /dev/foo en una OTA posterior, habrá un comportamiento indefinido. Para SELinux, esto se manifiesta como una colisión de etiquetado. El nodo del dispositivo solo puede tener un etiqueta única que se resuelve en la última etiqueta que se aplica. Resultado:

• Los procesos que necesitan acceso a la etiqueta aplicada sin éxito perderán el acceso al recurso.
• Los procesos que obtienen acceso al archivo pueden fallar porque se creó el nodo del dispositivo.

Las propiedades del sistema también pueden generar colisiones de nombres comportamiento indefinido en el sistema (así como para el etiquetado de SELinux). Accidentes entre las etiquetas de plataforma y proveedor pueden ocurrir para cualquier objeto que tenga un etiqueta, incluidas las propiedades, los servicios, los procesos, los archivos y los sockets. Para evitar estos problemas, define claramente la propiedad de estos objetos.

Además de las colisiones de etiquetas, los nombres de tipos o atributos de SELinux también pueden entrar en conflicto. Una colisión de nombre de tipo o atributo siempre dará como resultado un error del compilador de políticas.

Espacio de nombres de tipos/atributos

SELinux no permite varias declaraciones del mismo tipo o atributo. Política con declaraciones duplicadas no podrá compilarse. Para evitar el tipo y colisiones de nombres de atributos, todas las declaraciones del proveedor deben tener un espacio de nombres que comienza con vendor_.

type foo, domain; → type vendor_foo, domain;

Propiedad del sistema y propiedad del etiquetado de procesos

Evitar colisiones de etiquetas se resuelve mejor usando espacios de nombres de propiedades. Para identificar fácilmente las propiedades de la plataforma y evitar conflictos de nombres cuando se les cambia el nombre o agregar propiedades de plataforma exportadas, asegurarte de que todas las propiedades de los proveedores tengan prefijos propios:

Tipo de propiedad	Prefijos aceptables
propiedades de control	ctl.vendor. ctl.start$vendor. ctl.stop$vendor. init.svc.vendor.
admite lectura/escritura	vendor.
solo lectura	ro.vendor. ro.boot. ro.hardware.
persistente	persist.vendor.

Los proveedores pueden seguir usando ro.boot.* (que proviene del kernel cmdline) y ro.hardware.* (una propiedad obvia relacionada con el hardware).

Todos los servicios del proveedor en los archivos init rc deben tener vendor. para los servicios en archivos init rc de particiones que no sean del sistema. Hay reglas similares se aplicó a las etiquetas de SELinux para las propiedades del proveedor (vendor_ para las propiedades del proveedor).

Propiedad del archivo

Evitar las colisiones de archivos es un desafío porque la plataforma y el proveedor suelen proporcionar etiquetas para todos los sistemas de archivos. A diferencia de la denominación de tipos, el espacio de nombres de los archivos no es práctico, ya que a muchos de ellos los crea el kernel. Para evitar estas colisiones, sigue las instrucciones de asignación de nombres para sistemas de archivos en esta sección. En el caso de Android 8.0, estas son recomendaciones sin asistencia técnica de la aplicación de políticas. En el futuro, el Conjunto de pruebas de proveedores (VTS).

Sistema (/system)

Solo la imagen del sistema debe proporcionar etiquetas para los componentes de /system. a través de file_contexts, service_contexts, etc., para los componentes de /system en la política /vendor, un es posible que no se pueda realizar la actualización OTA solo del framework.

Proveedor (/proveedor)

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

/vendor ruta	Etiqueta proporcionada por la plataforma	La plataforma procesa según la etiqueta.
/vendor(/.*)?	vendor_file	Todos los clientes HAL del 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.

Por lo tanto, se deben seguir reglas específicas (aplicadas mediante neverallows) cuando etiquetes archivos adicionales en vendor partición:

• vendor_file debe ser la etiqueta predeterminada para todos los archivos en vendor. La política de la plataforma requiere esto para acceder implementaciones de HAL de transferencia.
• Se agregaron todos los exec_types nuevos en la partición vendor a través de SEPolicy del proveedor debe tener el atributo vendor_file_type. Esta se aplica mediante nuncaallows.
• Para evitar conflictos con futuras actualizaciones de la plataforma o el framework, evita el etiquetado otros archivos que no sean exec_types en una partición vendor.
• Todas las dependencias de bibliotecas para las mismas HAL de proceso identificadas por AOSP se deben etiquetado como same_process_hal_file.

Procfs (/proc)

Es posible que los archivos de /proc se etiqueten solo con el genfscon etiqueta. En Android 7.0, tanto la plataforma y proveedor política usada genfscon para etiquetar archivos en procfs.

Recomendación: Solo debes usar las etiquetas de política de plataforma /proc. Si vendor procesos necesitan acceder a archivos de /proc que están actualmente etiquetados con la etiqueta predeterminada (proc), política del proveedor no deben etiquetarlos de forma explícita, sino que deben usar Tipo proc para agregar reglas para los dominios de proveedores. Esto permite que la plataforma actualizaciones para adaptarse a futuras interfaces de kernel expuestas a través de procfs y etiquétalas de forma explícita según sea necesario.

Depuradores (/sys/kernel/debug)

Debugfs se puede etiquetar en file_contexts y genfscon En Android 7.0 a Android 10, la plataforma y la etiqueta de proveedor debugfs

En Android 11, debugfs no se puede se acceden o activan en dispositivos de producción. Los fabricantes de dispositivos deberían Quitar debugfs

Tracef (/sys/kernel/debug/tracing)

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

Recomendación: Solo la plataforma puede etiquetar tracefs.

Sysfs (/sys)

Es posible que los archivos de /sys se etiqueten con ambas etiquetas file_contexts. y genfscon. En Android 7.0, tanto la plataforma como el proveedor usan file_contexts y genfscon para etiquetar archivos en sysfs

Recomendación: La plataforma puede etiquetar sysfs que no son específicos del dispositivo. De lo contrario, solo el proveedor puede etiquetar los archivos.

tmpfs (/desarrollo)

Es posible que los archivos de /dev estén etiquetados en file_contexts. En Android 7.0, archivos de etiquetas de la plataforma y del proveedor aquí.

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

Rootfs (/)

Es posible que los archivos de / estén etiquetados en file_contexts. En Android 7.0, 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 que el etiquetado de proveedores sea externo. /data/vendor Solo la plataforma puede etiquetar otras partes de /data

Atributos de compatibilidad

La política de SELinux es una interacción entre los tipos de origen y destino para aplicaciones permisos y clases de objetos. Todos los objetos (procesos, archivos, etc.) afectados de SELinux puede tener un solo tipo, pero ese tipo puede tener varios atributos.

La política se redacta principalmente en términos de los tipos existentes:

allow source_type target_type:target_class permission(s);

Esto funciona porque la política se redactó con conocimientos de todo tipo. Sin embargo, si la política del proveedor y la política de la plataforma usan tipos específicos y la etiqueta de un cambios de objetos específicos en solo una de esas políticas, la otra puede contener que obtuvo o perdió el acceso de los que dependía anteriormente. Por ejemplo:

File_contexts:
/sys/A   u:object_r:sysfs:s0
Platform: allow p_domain sysfs:class perm;
Vendor: allow v_domain sysfs:class perm;

Podría cambiarse a:

File_contexts:
/sys/A   u:object_r:sysfs_A:s0

Si bien la política del proveedor seguiría siendo la misma, v_domain perdería acceso debido a la falta de políticas para el nuevo sysfs_A el tipo de letra.

Cuando se define una política en términos de atributos, podemos darle al objeto subyacente una que tiene un atributo correspondiente a la política para la plataforma y el código del proveedor. Esto se puede hacer para que todos los tipos creen attribute-policy donde nunca se usan tipos concretos. En la práctica, Esto es necesario solo para las partes de la política que se superponen entre la plataforma. y proveedor, que se definen y proporcionan como política pública de la plataforma que se crea como parte de la política del proveedor.

Definir la política pública como atributos con control de versiones satisface dos políticas Objetivos de compatibilidad:

• Asegúrate de que el código del proveedor siga funcionando después de la actualización de la plataforma. Se logra agregando atributos a tipos concretos de objetos que corresponden a aquellos en los que se basaba el código del proveedor, lo que preservaba el acceso.
• Capacidad para dar de baja la política. Se logra mediante claramente definiendo conjuntos de políticas en atributos que se pueden quitar en cuanto versión a la que corresponden, ya no es compatible. El desarrollo puede continúan en la plataforma, sabiendo que la política anterior sigue presente en el en la política del proveedor y se quitará automáticamente si se actualiza.

Escritura de la política

Para cumplir con el objetivo de no requerir conocimientos sobre cambios específicos de versiones para desarrollo de políticas, Android 8.0 incluye una asignación entre plataformas públicas de políticas y sus atributos. Se asignó el tipo foo al atributo foo_vN, donde N es el valor a la versión objetivo. vN corresponde al La variable de compilación PLATFORM_SEPOLICY_VERSION tiene el formato MM.NN, donde MM corresponde al número del SDK de la plataforma y NN es una versión específica de la política de plataforma.

Los atributos de la política pública no tienen control de versiones, sino que existen como una API en qué plataforma y política de proveedores pueden crear para mantener la interfaz entre ambos y particiones estables. Los redactores de políticas de la plataforma y del proveedor pueden seguir escribiendo política tal como está escrita hoy en día.

La política pública de plataforma que se exporta como allow source_foo target_bar:class perm; se incluye como parte de la política de proveedores. Durante compilación (que incluye el la versión correspondiente) se transforma en la política que se enviará parte del dispositivo con el proveedor (se muestra en la etapa Common Intermedio Idioma (CIL):

 (allow source_foo_vN target_bar_vN (class (perm)))

Como la política del proveedor nunca está a la vanguardia de la plataforma, no debe preocuparse versiones anteriores. Sin embargo, en la política de la plataforma se necesita determinar la antigüedad del proveedor política es, incluir atributos para sus tipos y establecer la política correspondiente a con control de versiones.

Diferencias de políticas

Agrega _vN al final para crear atributos automáticamente de cada tipo no hace nada sin asignar los atributos a los tipos en todas las versiones las diferencias Android mantiene una asignación entre las versiones de atributos y una la asignación de tipos a esos atributos. Esto se hace en el modelo de asignación con sentencias, como (CIL):

(typeattributeset foo_vN (foo))

Actualizaciones de la plataforma

En la siguiente sección, se detallan situaciones para las actualizaciones de plataformas.

Mismos tipos

Esta situación ocurre cuando un objeto no cambia las etiquetas de las versiones de políticas. Esto es lo mismo para los tipos de fuente y destino, y se puede observar con /dev/binder, que está etiquetado como binder_device en todos y lanzamientos de versiones. Se representa en la política transformada de la siguiente manera:

binder_device_v1 … binder_device_vN

Cuando se actualiza de v1 → v2, la política de la plataforma debe contienen:

type binder_device; -> (type binder_device) (in CIL)

En el archivo de asignación v1 (CIL):

(typeattributeset binder_device_v1 (binder_device))

En el archivo de asignación v2 (CIL):

(typeattributeset binder_device_v2 (binder_device))

En la política de proveedores v1 (CIL):

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

En la política de proveedores v2 (CIL):

(typeattribute binder_device_v2)
(allow binder_device_v2 …)

Nuevos tipos

Esto ocurre cuando la plataforma agrega un tipo nuevo, lo que puede suceder al agregar funciones nuevas o al endurecimiento de las políticas.

• Nueva función. Cuando el tipo etiqueta un objeto que se inexistente (como un nuevo proceso de servicio), el código del proveedor no interactuaron directamente con ella para que no exista la política correspondiente. La nueva herramienta atributo que corresponde al tipo no tiene un atributo en el estado por lo que no necesitaría una entrada en el archivo de asignación versión.
• Endurecimiento de las políticas. Cuando el tipo representa una política endurecimiento, el nuevo atributo type debe vincularse con una cadena de atributos correspondiente al anterior (similar al ejemplo anterior que cambia /sys/A de sysfs a sysfs_A). Proveedor se basa en una regla que habilita el acceso a sysfs y necesita incluir esa regla como un atributo del nuevo tipo.

Cuando se actualiza de v1 → v2, la política de la plataforma debe contienen:

type sysfs_A; -> (type sysfs_A) (in CIL)
type sysfs; (type sysfs) (in CIL)

En el archivo de asignación v1 (CIL):

(typeattributeset sysfs_v1 (sysfs sysfs_A))

En el archivo de asignación v2 (CIL):

(typeattributeset sysfs_v2 (sysfs))
(typeattributeset sysfs_A_v2 (sysfs_A))

En la política de proveedores v1 (CIL):

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

En la política de proveedores v2 (CIL):

(typeattribute sysfs_A_v2)
(allow … sysfs_A_v2 …)
(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

Tipos quitados

Esta situación (poco frecuente) ocurre cuando se quita un tipo, lo que puede ocurrir cuando objeto subyacente:

• Se conserva, pero recibe una etiqueta diferente.
• Se quita de la plataforma.

Durante la flexibilización de la política, se quita un tipo y el objeto se etiqueta con ese tipo. se le asigna una etiqueta diferente que ya existe. Esto representa una combinación asignaciones de atributos: el código del proveedor debe poder acceder a la base de datos objeto por el atributo que solía poseer, pero el resto del sistema ahora debe así que no puedas acceder a él con el atributo nuevo.

Si el atributo al que se cambió es nuevo, volver a etiquetarlo como en el nuevo tipo de letra, con la excepción de que, cuando se usa una etiqueta existente, suma del atributo nuevo tipo nuevo provocaría que otros objetos también con este tipo sean accesibles recientemente. Esto es básicamente lo que hace el plataforma y se considera una compensación aceptable para mantener compatibilidad.

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Ejemplo de versión 1: contracción de tipos (remoción de sysfs_A)

Cuando se actualiza de v1 → v2, la política de la plataforma debe contienen:

type sysfs; (type sysfs) (in CIL)

En el archivo de asignación v1 (CIL):

(typeattributeset sysfs_v1 (sysfs))
(type sysfs_A) # in case vendors used the sysfs_A label on objects
(typeattributeset sysfs_A_v1 (sysfs sysfs_A))

En el archivo de asignación v2 (CIL):

(typeattributeset sysfs_v2 (sysfs))

En la política de proveedores v1 (CIL):

(typeattribute sysfs_A_v1)
(allow … sysfs_A_v1 …)
(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

En la política de proveedores v2 (CIL):

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

Ejemplo de versión 2: eliminación completa (tipo foo)

Cuando se actualiza de v1 → v2, la política de la plataforma debe contienen:

# nothing - we got rid of the type

En el archivo de asignación v1 (CIL):

(type foo) #needed in case vendors used the foo label on objects
(typeattributeset foo_v1 (foo))

En el archivo de asignación v2 (CIL):

# nothing - get rid of it

En la política de proveedores v1 (CIL):

(typeattribute foo_v1)
(allow foo …)
(typeattribute sysfs_v1)
(allow sysfs_v1 …)

En la política de proveedores v2 (CIL):

(typeattribute sysfs_v2)
(allow sysfs_v2 …)

Clases o permisos nuevos

Esto ocurre cuando una actualización de la plataforma presenta nuevos componentes de políticas. que no existen en versiones anteriores. Por ejemplo, cuando Android agregó el servicemanager administrador de objetos que creó los objetos add, find y list de servicio, daemons de proveedores que desean registrarse en el servicemanager necesitaba permisos que no estaban disponibles. En Android 8.0, solo la política de la plataforma puede agregar nuevas clases y permisos.

Para permitir todos los dominios que la política del proveedor podría haber creado o extendido para usar la nueva clase sin obstrucciones, la política de la plataforma debe incluir un similar a:

allow {domain -coredomain} *:new_class perm;

Esto puede incluso requerir una política que permita el acceso a todas las interfaces (política pública) para asegurarse de que la imagen del proveedor obtenga acceso. Si esto da como resultado un política de seguridad de Google (tal como sucede con los cambios en el administrador de servicios), un proveedor la actualización podría ser forzada.

Se quitaron las clases o los permisos

Esto ocurre cuando se quita un administrador de objetos (como ZygoteConnection administrador de objetos) y no debería causar problemas. El los permisos y la clase de administrador de objetos podrían permanecer definidos en la política hasta que versión del proveedor ya no lo usa. Para ello, se agregan las definiciones al archivo de asignación correspondiente.

Personalización de proveedores para tipos nuevos o reetiquetados

Los nuevos tipos de proveedores son fundamentales para el desarrollo de políticas de proveedores, ya que son necesarios para describir nuevos procesos, objetos binarios, dispositivos, subsistemas y datos almacenados. Como por lo que es imperativo permitir la creación de tipos definidos por el proveedor.

Como la política del proveedor es siempre la más antigua del dispositivo, no es necesario convertir automáticamente todos los tipos de proveedores en atributos en la política. La plataforma no se basa en nada etiquetado en la política del proveedor porque la plataforma no tiene el conocimiento de ellos; sin embargo, la plataforma proporcionará los atributos y los atributos tipos que usa para interactuar con los objetos etiquetados con esos tipos (como domain, sysfs_type, etc.). Para que la plataforma sigan interactuando correctamente con estos objetos, los atributos y los tipos se deben aplicar correctamente y es posible que sea necesario agregar reglas específicas personalizables (como init).

Cambios en los atributos para Android 9

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

Atributos de los infractores

Android 9 incluye los siguientes atributos relacionados con el dominio:

• data_between_core_and_vendor_violators Atributo para todos los dominios que infrinjan el requisito de no compartir archivos por ruta entre vendor y coredomains. Plataforma y los procesos 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 infrinjan el requisito de no ejecutar objetos binarios del proveedor. Ejecución de los binarios del proveedor tienen una API inestable. La plataforma no debe ejecutar objetos binarios del proveedor directamente. Recomendación:
  • Esas dependencias de la plataforma en los objetos binarios del proveedor deben estar detrás de las HAL del HIDL.

    O BIEN

  • Las coredomains que necesitan acceso a los objetos binarios del proveedor deben tener se trasladará a la partición del proveedor y, por lo tanto, dejará de ser coredomain.

Atributos que no son de confianza

Las apps no confiables que alojan código arbitrario no deberían tener acceso a HwBinder servicios, salvo aquellos que se consideren lo suficientemente seguros para acceder desde esas apps (consulta los servicios seguros a continuación). Los dos motivos principales son los siguientes:

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

Servicios seguros

Entre los servicios seguros, se incluyen los siguientes:

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

Atributos que se pueden usar

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. Dispositivos que se lanzan con Android 9 NO DEBEN usar atributo untrusted.

Recomendación:

• En cambio, las aplicaciones que no sean de confianza deben comunicarse con un servicio del sistema que se comunique con el HAL del HIDL del proveedor. Por ejemplo, las apps pueden hablar con binderservicedomain y, luego, mediaserver (que es un binderservicedomain), a su vez, se comunica con el hal_graphics_allocator.

  O BIEN

• Las apps que necesitan acceso directo a las HAL de vendor deben tener 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 de ubicaciones tienen los atributos adecuados (por ejemplo, todos los archivos en sysfs tienen el atributo obligatorio sysfs_type).

Política pública de la plataforma

La política de plataforma pública es fundamental para cumplir con Android 8.0 sin tener que mantener la unión de las políticas de la plataforma de las versiones 1 y 2. Los proveedores están expuestos a un subconjunto de políticas de la plataforma que contiene tipos y atributos utilizables, y reglas sobre esos tipos y atributos que luego forma parte de la política del proveedor (es decir, vendor_sepolicy.cil).

Los tipos y las reglas se traducen automáticamente en la política generada por el proveedor en attribute_vN para que todos los tipos proporcionados por la plataforma son atributos con control de versiones (aunque los atributos no tienen control de versiones). La plataforma es de asignar los tipos concretos que proporciona atributos para garantizar que la política del proveedor siga funcionando y que las reglas proporcionadas para una versión en particular. La combinación de la política de plataforma pública y la política de proveedores satisfaga la arquitectura de Android 8.0 objetivo del modelo de permitir compilaciones de plataformas y proveedores independientes.

Cómo asignar a cadenas de atributos

Cuando se usan atributos para asignar a versiones de políticas, un tipo se asigna a un atributo o múltiples atributos, lo que garantiza que se pueda acceder a los objetos etiquetados con el tipo mediante atributos correspondientes a sus tipos anteriores.

Mantener el objetivo de ocultar la información de la versión al redactor de políticas generar automáticamente los atributos con control de versiones y asignarlos al tipos adecuados. En el caso común de los tipos estáticos, esto es claro: type_foo se asigna a type_foo_v1.

Para un cambio en la etiqueta de un objeto, como sysfs → sysfs_A o mediaserver → audioserver, la creación de esta asignación es no trivial (y se describe en los ejemplos anteriores). Encargados de mantener la política de plataforma deben determinar cómo crear la asignación en puntos de transición para los objetos, que requiere comprender la relación entre los objetos y sus asignaciones etiquetas y determinar cuándo ocurre. Para la retrocompatibilidad, este la complejidad debe administrarse en la plataforma, que es la única partición que podría aumentar los ingresos.

Aumento de ingresos de la versión

Para simplificar, la plataforma de Android lanza una versión de política cuando se crea de actualización está cortada. Como se describió anteriormente, el número de versión se encuentra en PLATFORM_SEPOLICY_VERSION y tiene el formato MM.nn, donde MM corresponde al valor del SDK y nn es un valor privado que se mantiene en /platform/system/sepolicy. por por ejemplo, 19.0 para Kitkat, 21.0 para Lollipop, 22.0 para Lollipop-MR1 23.0 para Marshmallow, 24.0 para Nougat, 25.0 para Nougat-MR1, 26.0 para Oreo, 27.0 para Oreo-MR1 y 28.0 para Android 9. Los Uprevs no siempre son números enteros. Para ejemplo, si un cambio de MR a una versión requiere un cambio incompatible en system/sepolicy/public, pero no es un cambio de prioridad de API, entonces esa política Esta versión podría ser vN.1. La versión presente en un entorno es una 10000.0 que no se debe usar en dispositivos de envío.

Es posible que Android dé de baja la versión más antigua cuando se actualice. Para saber cuándo dar de baja una versión, Android podría recopilar la cantidad de dispositivos que tengan políticas que ejecutan esa versión de Android y que siguen recibiendo actualizaciones. Si el número es inferior a un umbral determinado, esa versión obsoleto.

Impacto en el rendimiento de varios atributos

Como se describe en https://github.com/SELinuxProject/cil/issues/9, una gran cantidad de atributos asignados a un tipo provocan problemas de rendimiento en un error de caché de políticas.

Se confirmó que esto era un problema en Android, por lo que los cambios se implementaron en Android 8.0 para quitar los atributos agregados a la política por el de políticas de firewall y quitar los atributos sin usar. Estos cambios resolvieron regresiones de rendimiento.

Política pública de System_ext y de producto

A partir de Android 11, las particiones system_ext y product pueden exportar sus tipos públicos designados a la partición del proveedor. Me gusta la plataforma política pública, el proveedor utiliza tipos y reglas traducidos automáticamente en los atributos con control de versiones, p.ej., de type a type_N, donde N es la versión de la plataforma en la que se compiló la partición del proveedor.

Cuando las particiones system_ext y product se basan en la misma versión de la plataforma N, el sistema de compilación genera archivos de asignación base para system_ext/etc/selinux/mapping/N.cil y product/etc/selinux/mapping/N.cil, que contienen la identidad asignaciones de type a type_N. El proveedor puede accede a type con el atributo con versión type_N.

En caso de que solo se actualicen las particiones system_ext y product, supongamos N a N+1 (o posterior), mientras que el proveedor se queda en N, es posible que pierda acceso a la los tipos de las particiones system_ext y product. Para evitar fallas, el Las particiones system_ext y product deben proporcionar archivos de asignación de datos en atributos type_N. Cada socio es responsable de mantener los archivos de asignación, si van a admitir Proveedor de N con N+1 (o posterior) system_ext y particiones de productos.

Para ello, se espera que los socios:

1. Copia los archivos de asignación base generados desde N. system_ext y particiones de productos a su árbol de fuentes.
2. Corrige los archivos de asignación según sea necesario.
3. Instala el archivos de asignación a N+1 (o posterior) system_ext y particiones de producto.

Por ejemplo, supongamos que N system_ext tiene una configuración llamado foo_type. Luego, system_ext/etc/selinux/mapping/N.cil en la partición system_ext N se verá de la siguiente manera:

(typeattributeset foo_type_N (foo_type))
(expandtypeattribute foo_type_N true)
(typeattribute foo_type_N)

Si se agrega bar_type a N+1 system_ext, y si bar_type debe asignarse a foo_type para N proveedor, N.cil se puede actualizar desde

(typeattributeset foo_type_N (foo_type))

a

(typeattributeset foo_type_N (foo_type bar_type))

y, luego, instalarla en la partición de N+1 system_ext. N proveedor puede seguir accediendo a N+1 foo_type y bar_type de system_ext.

Etiquetado de contextos de SELinux

Para admitir la distinción entre la política de la plataforma y la del proveedor, el sistema crea los archivos de contexto 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 dejan de existir en formato binario. En cambio, sean archivos de texto de expresión regular legibles y regulares, como {property, service}_contexts (ya que eran versiones anteriores a la versión 7.0).
• file_contexts se dividen entre dos archivos:
  • plat_file_contexts
    • la plataforma de Android file_context que no tiene etiquetas específicas del dispositivo, excepto para etiquetar las partes de /vendor que deben etiquetarse con precisión para y 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 los cargará al comienzo, junto con el archivo proveedor file_context.
  • vendor_file_contexts
    • file_context específico para el dispositivo creado a partir de la combinación Se encontró file_contexts en los directorios a los que apunta BOARD_SEPOLICY_DIRS en el Boardconfig.mk.
    • Se debe instalar en /vendor/etc/selinux/vendor_file_contexts in vendor partición y la cargará init a la(s) el inicio junto con la plataforma file_context.

Contextos de la propiedad

En Android 8.0, property_contexts se divide entre dos archivos:

• plat_property_contexts
  • la plataforma de Android property_context que no tiene etiquetas específicas del dispositivo.
  • Debe residir en la partición system en /system/etc/selinux/plat_property_contexts y se cargará antes del init al comienzo, junto con el proveedor property_contexts
• vendor_property_contexts
  • property_context específico para el dispositivo creado a partir de la combinación Se encontró property_contexts en los directorios a los que apunta BOARD_SEPOLICY_DIRS en el dispositivo Boardconfig.mk.
  • Debe residir en la partición vendor en /vendor/etc/selinux/vendor_property_contexts y sé cargado por init al comienzo junto con la plataforma property_context

Contextos del servicio

En Android 8.0, service_contexts se divide entre lo siguiente: archivos:

• plat_service_contexts
  • service_context específico de la plataforma de Android para el servicemanager La service_context no tiene etiquetas específicas del dispositivo.
  • Debe residir en la partición system en /system/etc/selinux/plat_service_contexts y será cargado por servicemanager al comienzo junto con el proveedor service_contexts
• vendor_service_contexts
  • service_context específico para el dispositivo creado a partir de la combinación Se encontró service_contexts en los directorios a los que apunta BOARD_SEPOLICY_DIRS en el Boardconfig.mk.
  • Debe residir en la partición vendor en /vendor/etc/selinux/vendor_service_contexts y se cargará antes del servicemanager, al inicio junto con la plataforma service_contexts
  • Aunque servicemanager busca este archivo en el momento del inicio, para un dispositivo TREBLE que cumple con todos los requisitos, la vendor_service_contexts NO DEBE existir. Esto se debe a que toda la interacción entre vendor y system los procesos DEBEN atravesar hwservicemanager/hwbinder
• plat_hwservice_contexts
  • Plataforma de Android hwservice_context 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 será cargado por hwservicemanager al inicio, junto con vendor_hwservice_contexts
• vendor_hwservice_contexts
  • hwservice_context específico para el dispositivo creado a partir de la combinación Se encontró hwservice_contexts en los directorios a los que apunta BOARD_SEPOLICY_DIRS en el Boardconfig.mk.
  • Debe residir en la partición vendor en /vendor/etc/selinux/vendor_hwservice_contexts y sé cargado por hwservicemanager al comienzo, junto con el plat_service_contexts
• vndservice_contexts
  • service_context específico del dispositivo para el vndservicemanager creado a partir de la combinación Se encontró vndservice_contexts en los directorios a los que hace referencia. BOARD_SEPOLICY_DIRS en el dispositivo Boardconfig.mk
  • Este archivo debe estar en la partición vendor en /vendor/etc/selinux/vndservice_contexts y será cargado por vndservicemanager al inicio.

Contextos de SEapp

En Android 8.0, seapp_contexts se divide entre dos archivos:

• plat_seapp_contexts
  • La plataforma de Android seapp_context que no tiene restricciones específicas del dispositivo cambios.
  • 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 compilada combinando seapp_contexts que se encuentra en los directorios a la que hace BOARD_SEPOLICY_DIRS en la carpeta Boardconfig.mk.
  • Debe residir en la partición vendor en /vendor/etc/selinux/vendor_seapp_contexts

Permisos de MAC

En Android 8.0, mac_permissions.xml se divide entre dos archivos:

• Andén mac_permissions.xml
  • la plataforma de Android mac_permissions.xml que no tiene cambios específicos del dispositivo.
  • Debe residir en la partición system en /system/etc/selinux/.
• mac_permissions.xml que no son plataformas
  • Extensión de la plataforma específica del dispositivo mac_permissions.xml se compiló a partir de Se encontró mac_permissions.xml en los directorios a los que apunta BOARD_SEPOLICY_DIRS en el Boardconfig.mk.
  • Debe residir en la partición vendor en /vendor/etc/selinux/.