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

Compatibilidad de políticas

Este artículo describe cómo Android maneja los problemas de compatibilidad de políticas con las plataformas OTA, donde la configuración de SELinux de la nueva plataforma puede diferir de la configuración de SELinux del proveedor anterior.

El diseño de políticas de SELinux basada en los agudos considera una distinción binaria entre la plataforma y la política de proveedores; el esquema se vuelve más complicado si las particiones de los proveedores generan dependencias, como la platform < vendor < oem .

En Android 8.0 y superior, la política global de SELinux se divide en componentes públicos y privados. Los componentes públicos consisten en la política y la infraestructura asociada, que se garantiza que estarán disponibles para una versión de plataforma. Esta política se expondrá a los redactores de políticas de los proveedores para permitirles crear un archivo de políticas de proveedores, que cuando se combina con la política proporcionada por la plataforma, da como resultado una política completamente funcional para un dispositivo.

  • Control de versiones, la política plataforma pública exportado se escribe como atributos.
  • Para facilitar la escritura de políticas, tipos exportados serán transformadas en atributos versionados como parte del proceso de construcción política. Los tipos públicos también se pueden utilizar directamente en las decisiones de etiquetado proporcionadas por los archivos de contextos del proveedor.

Android mantiene una correlación entre tipos concretos exportados en la política de la plataforma y los correspondientes atributos versionados para cada versión de la plataforma. Esto asegura que cuando los objetos se etiquetan con un tipo, no rompe el comportamiento garantizado por la política pública de plataforma en una versión anterior. Este mapeo se mantiene al mantener un archivo de asignación de hasta al día para cada versión de la plataforma , lo que mantiene información sobre los miembros de atributo para cada 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 para mantener la política de la plataforma y del proveedor por separado. Por ejemplo, si el proveedor de etiquetas /dev/foo y la plataforma entonces etiquetas /dev/foo en un subsiguiente OTA, habrá un comportamiento indefinido. Para SELinux, esto se manifiesta como una colisión de etiquetado. El nodo de dispositivo solo puede tener una etiqueta única que se resuelve en la etiqueta que se aplique en último lugar. Como resultado:

  • Los procesos que necesitan acceso a la etiqueta aplicada, sin éxito, perderán el acceso al recurso.
  • Los procesos que acceden al archivo pueden romper porque se creó el nodo de dispositivo equivocado.

Las propiedades del sistema también tienen potencial para nombrar colisiones que podrían resultar en un comportamiento indefinido en el sistema (así como para el etiquetado SELinux). Pueden ocurrir colisiones entre la plataforma y las etiquetas del proveedor para cualquier objeto que tenga una etiqueta SELinux, incluidas propiedades, servicios, procesos, archivos y sockets. Para evitar estos problemas, defina claramente la propiedad de estos objetos.

Además de las colisiones de etiquetas, los nombres de tipo / atributo de SELinux también pueden colisionar. Una colisión de nombre de tipo / atributo siempre resultará en un error del compilador de políticas.

Espacio de nombres de tipo / atributo

SELinux no permite múltiples declaraciones del mismo tipo / atributo. La política con declaraciones duplicadas no se podrá compilar. Para evitar tipo y el nombre del atributo colisiones, todas las declaraciones del vendedor deben ser espacios de nombres empezando con np_ .

type foo, domain; → type np_foo, domain;

Propiedad del sistema y propiedad del etiquetado del proceso

Evitar las colisiones de etiquetado se resuelve mejor utilizando espacios de nombres de propiedades. Para identificar fácilmente las propiedades de la plataforma y evitar conflictos de nombres al cambiar el nombre o agregar propiedades de la plataforma exportada, asegúrese de que todas las propiedades del proveedor tengan sus propios prefijos:

Tipo de propiedad Prefijos aceptables
se puede leer y escribir vendor.
solo lectura ro.vendor.
ro.boot.
ro.hardware.
persistente persist.vendor.

Los proveedores pueden seguir usando ro.boot.* (Que proviene de la línea_de_órdenes núcleo) y ro.hardware.* (Una propiedad relacionados con el hardware obvio).

Todos los servicios del proveedor de archivos rc init deben tener vendor. para servicios en archivos init rc de particiones que no son del sistema. Reglas similares se aplican a las etiquetas de SELinux para las propiedades proveedor ( vendor_ para las propiedades de proveedor).

Propiedad del archivo

La prevención de colisiones de archivos es un desafío porque la plataforma y la política del proveedor comúnmente proporcionan etiquetas para todos los sistemas de archivos. A diferencia de la nomenclatura de tipos, el espacio de nombres de los archivos no es práctico ya que muchos de ellos son creados por el kernel. Para evitar estas colisiones, siga la guía de nombres para sistemas de archivos en esta sección. Para Android 8.0, estas son recomendaciones sin aplicación técnica. En el futuro, estas recomendaciones serán impuestas por el conjunto de pruebas de proveedor (VTS).

Sistema (/ sistema)

Sólo la imagen del sistema debe proporcionar etiquetas para /system componentes a través de file_contexts , service_contexts , etc. Si las etiquetas para /system componentes se añaden en /vendor política, un marco de sólo actualización OTA puede no ser posible.

Proveedor (/ proveedor)

La política de SELinux ya AOSP etiquetas partes del vendor partición interactúa con la plataforma, lo que permite la escritura reglas de SELinux para los procesos de plataforma para ser capaz de hablar y / o partes de acceso del vendor partición. Ejemplos:

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

Como resultado de ello, las normas específicas deben ser seguido (cumplir mediante neverallows ) al etiquetar archivos adicionales en vendor partición:

  • vendor_file debe ser la etiqueta por defecto para todos los archivos de vendor partición. La política de la plataforma requiere esto para acceder a las implementaciones de HAL de paso.
  • Todas las novedades exec_types añadidas en vendor partición a través de proveedores SEPolicy deben tener vendor_file_type atributo. Esto se aplica de ninguna manera.
  • Para evitar conflictos con la plataforma de futuro / actualizaciones marco, archivos de etiquetado evitar otros que exec_types en vendor partición.
  • Todas las dependencias de bibliotecas para identificados-AOSP mismos HAL proceso deben ser etiquetados como same_process_hal_file.

Procfs (/ proc)

Los archivos en /proc pueden marcarse utilizando sólo el genfscon etiqueta. En Android 7.0, tanto la plataforma y el proveedor de la política utilizan genfscon a archivos de etiquetas en procfs .

Recomendación: las etiquetas de política plataforma Solo /proc . Si vendor procesos necesitan tener acceso a archivos en /proc que actualmente están etiquetados con la etiqueta predeterminada ( proc ), política de proveedores no debe etiquetar de forma explícita y en su lugar debe usar el genérico proc tipo de añadir reglas para los dominios de proveedores. Esto permite que las actualizaciones de la plataforma para dar cabida a las futuras interfaces del núcleo expuesto a través de procfs y etiquetarlos de forma explícita como sea necesario.

Debugfs (/ sys / kernel / debug)

Debugfs pueden marcarse en ambos file_contexts y genfscon . En Android 7.0 a Android 10, ambas plataformas y proveedores de etiquetas debugfs .

En Android 11, debugfs no se puede acceder o montados en dispositivos de producción. Los fabricantes de dispositivos deben eliminar debugfs .

Tracefs (/ sys / kernel / debug / tracing)

Tracefs pueden marcarse en ambos file_contexts y genfscon . En Android 7.0, sólo la plataforma de etiquetas tracefs .

Recomendación: Sólo plataforma puede etiquetar tracefs .

Sysfs (/ sys)

Los archivos en /sys pueden ser etiquetados con las dos file_contexts y genfscon . En Android 7.0, ambas plataformas y proveedores de uso file_contexts y genfscon a archivos de etiquetas en sysfs .

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

tmpfs (/ dev)

Los archivos en /dev podrán etiquetarse en file_contexts . En Android 7.0, tanto la plataforma como los archivos de etiqueta del proveedor aquí.

Recomendación: Vendedor puede etiqueta sólo archivos en /dev/vendor (por ejemplo, /dev/vendor/foo , /dev/vendor/socket/bar ).

Rootfs (/)

Los archivos en / podrán etiquetarse en file_contexts . En Android 7.0, tanto la plataforma como los archivos de etiqueta del proveedor aquí.

Recomendación: Sólo sistema puede etiquetar los archivos en / .

Datos (/ datos)

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

Recomendación: No permitir el etiquetado proveedor fuera /data/vendor . Sólo plataforma puede etiquetar otras partes del /data .

Atributos de compatibilidad

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

La política está escrita principalmente en términos de 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 utilizan tipos específicos, y la etiqueta de un objeto específico cambia solo en una de esas políticas, la otra puede contener una política que obtuvo o perdió el acceso en el que se confiaba 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

Aunque la política de proveedores seguiría siendo el mismo, la v_domain perdería el acceso debido a la falta de una política para el nuevo sysfs_A tipo.

Al definir una política en términos de atributos, podemos darle al objeto subyacente un tipo que tiene un atributo correspondiente a la política tanto para la plataforma como para el código del proveedor. Esto se puede hacer de todo tipo para crear efectivamente una política de atributos que los tipos concretos no se utilizan nunca. En la práctica, esto sólo se requiere para las porciones de la política que se superponen entre la plataforma y el vendedor, que se definen y se proporciona como política pública que se construye plataforma que como parte de la política de proveedores.

Definir la política pública como atributos versionados satisface dos objetivos de compatibilidad de políticas:

  • Asegurar código de proveedor sigue trabajando después de la actualización de la plataforma. Se logró agregando atributos a tipos concretos para objetos correspondientes a aquellos en los que se basaba el código del proveedor, preservando el acceso.
  • Capacidad de la política Desaprobar. Se logra al delinear claramente los conjuntos de políticas en atributos que se pueden eliminar tan pronto como la versión a la que corresponden ya no sea compatible. El desarrollo puede continuar en la plataforma, sabiendo que la política anterior todavía está presente en la política del proveedor y se eliminará automáticamente cuando se actualice.

Capacidad de escritura de la política

Para cumplir con el objetivo de no requerir conocimiento de cambios de versión específicos para el desarrollo de políticas, Android 8.0 incluye un mapeo entre los tipos de políticas públicas de plataforma y sus atributos. Tipo foo se asigna al atributo foo_v N , donde N es la versión de destino. vN corresponde a la PLATFORM_SEPOLICY_VERSION variable de acumulación y es de la forma MM.NN , donde MM se corresponde con el número de plataforma SDK y NN es una versión de la plataforma sepolicy específico.

Los atributos de la política pública no están versionados, sino que existen como una API en la que la plataforma y la política del proveedor se pueden construir para mantener estable la interfaz entre las dos particiones. Tanto los redactores de políticas de proveedores como de plataformas pueden seguir redactando políticas tal como están redactadas hoy.

Plataforma-política pública exportan como allow source_foo target_bar: class perm ; se incluye como parte de la política del proveedor. Durante la compilación (que incluye la versión correspondiente) se transforma en la política que va a ir a la parte de proveedor del dispositivo (que se muestra en la Lengua transformado intermedio común (CIL)):

 (allow source_foo_vN target_bar_vN (class (perm)))

Como la política del proveedor nunca se adelanta a la plataforma, no debería preocuparse por las versiones anteriores. Sin embargo, la política de la plataforma necesitará saber qué tan atrás está la política del proveedor, incluir atributos a sus tipos y establecer la política correspondiente a los atributos versionados.

Diferencias de política

La creación automática de atributos mediante la adición _v N al final de cada tipo no hace nada sin asignación de atributos a través de los tipos de diferenciaciones de versión. Android mantiene un mapeo entre versiones para atributos y un mapeo de tipos a esos atributos. Esto se hace en los archivos de mapeo antes mencionados con declaraciones, como (CIL):

(typeattributeset foo_vN (foo))

Actualizaciones de plataforma

La siguiente sección detalla los escenarios para las actualizaciones de la plataforma.

Mismos tipos

Este escenario ocurre cuando un objeto no cambia las etiquetas en las versiones de la política. Este es el mismo para origen y de destino tipos y se puede ver con /dev/binder , que está etiquetado binder_device a través de todas las emisiones. Se representa en la política transformada como:

binder_device_v1 … binder_device_vN

Cuando se actualiza desde v1v2 , la política de la plataforma debe contener:

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

En el archivo de mapeo v1 (CIL):

(typeattributeset binder_device_v1 (binder_device))

En el archivo de mapeo 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

Este escenario ocurre cuando la plataforma ha agregado un nuevo tipo, lo que puede suceder al agregar nuevas funciones o durante el endurecimiento de las políticas.

  • Nueva función. Cuando el tipo está etiquetando un objeto que antes no existía (como un nuevo proceso de servicio), el código del proveedor no interactuó previamente con él directamente, por lo que no existe una política correspondiente. El nuevo atributo correspondiente al tipo no tiene un atributo en la versión anterior, por lo que no necesitaría una entrada en el archivo de mapeo para esa versión.
  • Endurecimiento de la política. Cuando el tipo representa el endurecimiento de políticas, el nuevo atributo tipo debe vincular de nuevo a una cadena de atributos correspondientes a la anterior (similar al ejemplo anterior cambiantes /sys/A de sysfs a sysfs_A ). Código de proveedor se basa en una regla que permite el acceso a sysfs , y debe incluir esa norma como un atributo del nuevo tipo.

Cuando se actualiza desde v1v2 , la política de la plataforma debe contener:

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

En el archivo de mapeo v1 (CIL):

(typeattributeset sysfs_v1 (sysfs sysfs_A))

En el archivo de mapeo 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 eliminados

Este escenario (raro) ocurre cuando se elimina un tipo, lo que puede suceder cuando el objeto subyacente:

  • Permanece pero recibe una etiqueta diferente.
  • Es retirado por la plataforma.

Durante la relajación de la política, se elimina un tipo y el objeto etiquetado con ese tipo recibe una etiqueta diferente, ya existente. Esto representa una combinación de asignaciones de atributos: el código del proveedor aún debe poder acceder al objeto subyacente mediante el atributo que solía poseer, pero el resto del sistema ahora debe poder acceder a él con su nuevo atributo.

Si el atributo al que se ha cambiado es nuevo, el reetiquetado es el mismo que en el caso del nuevo tipo, excepto que cuando se usa una etiqueta existente, la adición del atributo antiguo nuevo tipo provocaría que otros objetos también etiquetados con este tipo para ser nuevamente accesible. Esto es esencialmente lo que hace la plataforma y se considera una compensación aceptable para mantener la compatibilidad.

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Versión de ejemplo 1: tipos de colapso (eliminación de sysfs_A)

Cuando se actualiza desde v1v2 , la política de la plataforma debe contener:

type sysfs; (type sysfs) (in CIL)

En el archivo de mapeo 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 mapeo 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 …)

Versión de ejemplo 2: Eliminación completa (tipo foo)

Cuando se actualiza desde v1v2 , la política de la plataforma debe contener:

# nothing - we got rid of the type

En el archivo de mapeo v1 (CIL):

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

En el archivo de mapeo 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 …)
Nueva clase / permisos

Este escenario ocurre cuando una actualización de la plataforma introduce nuevos componentes de políticas que no existen en versiones anteriores. Por ejemplo, cuando Android añadió el servicemanager administrador de objetos que ha creado el complemento, descubrimiento, y permisos de lista, demonios proveedores que deseen registrarse ante las servicemanager necesarios permisos que no estaban disponibles. En Android 8.0, solo la política de la plataforma puede agregar nuevas clases y permisos.

Para permitir que todos los dominios que podrían haber sido creados o extendidos por la política del proveedor usen la nueva clase sin obstrucciones, la política de la plataforma debe incluir una regla similar a:

allow {domain -coredomain} *:new_class perm;

Esto incluso puede requerir una política que permita el acceso a todos los tipos de interfaz (política pública), para asegurarse de que la imagen del proveedor obtenga acceso. Si esto da como resultado una política de seguridad inaceptable (como puede suceder con los cambios del administrador de servicios), una actualización del proveedor podría verse forzada.

Clase / permisos eliminados

Esta situación se produce cuando se elimina un administrador de objetos (tales como el ZygoteConnection administrador de objetos) y no debería causar problemas. La clase y los permisos del administrador de objetos podrían permanecer definidos en la política hasta que la versión del proveedor ya no los use. Esto se hace agregando las definiciones al archivo de mapeo correspondiente.

Personalización del proveedor para tipos nuevos / reetiquetados

Los nuevos tipos de proveedores son el núcleo del desarrollo de políticas de proveedores, ya que son necesarios para describir nuevos procesos, binarios, dispositivos, subsistemas y datos almacenados. Como tal, 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 de la política. La plataforma no depende de nada etiquetado en la política del proveedor porque la plataforma no tiene conocimiento de ello; Sin embargo, la plataforma proporcionará los atributos y tipos públicos que utiliza para interactuar con los objetos etiquetados con estos tipos (como domain , sysfs_type , etc.). Para la plataforma para continuar para interactuar correctamente con estos objetos, los atributos y tipos deben ser adecuadamente aplicados y pueden necesitar ser añadido a los dominios personalizables (tales como las reglas específicas init ).

Cambios de atributos para Android 9

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

Atributos del infractor

Android 9 incluye estos atributos relacionados con el dominio:

  • data_between_core_and_vendor_violators . Atributo para todos los dominios que violan el requisito de no compartir archivos mediante la ruta entre vendor y coredomains . Los procesos de plataforma y proveedor no deben usar archivos en disco para comunicarse (ABI inestable). Recomendación:
    • Código de proveedor debe usar /data/vendor .
    • El sistema no debe usar /data/vendor .
  • system_executes_vendor_violators . Atributo para todos los dominios de sistema (excepto init y shell domains ) que violan el requisito de no ejecutar binarios de proveedores. La ejecución de los binarios del proveedor tiene una API inestable. La plataforma no debería ejecutar los binarios del proveedor directamente. Recomendación:
    • Dichas dependencias de la plataforma en los binarios del proveedor deben estar detrás de HIDL HAL.

      O

    • coredomains que necesitan acceder a los archivos binarios del vendedor debe ser trasladado a la partición del vendedor y por lo tanto, dejan de ser coredomain .

Atributos que no son de confianza

Las aplicaciones que no son de confianza que alojan código arbitrario no deberían tener acceso a los servicios de HwBinder, excepto aquellas que se consideren suficientemente seguras para acceder desde dichas aplicaciones (consulte los servicios seguros a continuación). Las dos razones principales de esto son:

  1. Los servidores de HwBinder no realizan la autenticación del cliente porque HIDL actualmente no expone la información de UID de la persona que llama. Incluso si HIDL expuso dichos datos, muchos servicios de HwBinder operan a un nivel inferior al de las aplicaciones (como las HAL) o no deben depender de la identidad de la aplicación para su autorización. Por lo tanto, para estar seguro, la suposición predeterminada es que cada servicio de HwBinder trata a todos sus clientes como igualmente autorizados para realizar las operaciones ofrecidas por el servicio.
  2. Servidores de HAL (un subconjunto de servicios HwBinder) contener código con una mayor tasa de incidencia de los problemas de seguridad que system/core componentes y tener acceso a las capas inferiores de la pila (todo el camino hasta el hardware) aumentando así las oportunidades de pasar por el modelo de seguridad de Android .

Servicios seguros

Los servicios seguros incluyen:

  • 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 la razón n. ° 2.
  • hal_configstore_ISurfaceFlingerConfigs . Este servicio está diseñado específicamente para ser utilizado por cualquier dominio.
  • hal_graphics_allocator_hwservice . Estas operaciones también son ofrecidos por surfaceflinger servicio Binder, qué aplicaciones se les permite el acceso.
  • hal_omx_hwservice . Esta es una versión de la HwBinder mediacodec servicio Binder, qué aplicaciones se les permite el acceso.
  • hal_codec2_hwservice . Esta es una nueva versión de hal_omx_hwservice .

Atributos utilizables

Todos hwservices no considerados seguros tienen el atributo untrusted_app_visible_hwservice . Los servidores de HAL correspondientes tienen el atributo untrusted_app_visible_halserver . Artefactos de lanzamiento con Android 9 no debe utilizar ya sea untrusted atributo.

Recomendación:

  • Las aplicaciones que no son de confianza deberían hablar con un servicio del sistema que habla con el proveedor HIDL HAL. Por ejemplo, las aplicaciones pueden hablar con binderservicedomain , entonces mediaserver (que es un binderservicedomain ) a su vez se comunica con el hal_graphics_allocator .

    O

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

Pruebas de atributos de archivo

Android 9 incluye pruebas de tiempo de construcción que aseguran que todos los archivos en ubicaciones específicas tienen los atributos apropiados (tales como, todos los archivos sysfs tener la necesaria sysfs_type atributo).

Políticas públicas de plataforma

La política pública de plataforma es el núcleo de la conformidad con el modelo de arquitectura de Android 8.0 sin simplemente mantener la unión de políticas de plataforma de v1 y v2. Los vendedores están expuestos a un subconjunto de la política plataforma que contiene los tipos y atributos y reglas sobre los tipos y atributos que se convierte en parte de la política del proveedor (es decir utilizables vendor_sepolicy.cil ).

Tipos y reglas se traducen automáticamente en la política generada proveedor en attribute_v N tal que todos los tipos de plataforma-proporcionado son atributos versionado (sin embargo atributos se no versionadas). La plataforma es responsable de mapear los tipos concretos que proporciona en los atributos apropiados para garantizar que la política del proveedor continúe funcionando y que se incluyan las reglas proporcionadas para una versión en particular. La combinación de la política pública de plataforma y la política del proveedor satisface el objetivo del modelo de arquitectura de Android 8.0 de permitir la creación de plataformas y proveedores independientes.

Asignación a cadenas de atributos

Cuando se utilizan atributos para asignar a versiones de políticas, un tipo se asigna a un atributo o atributos múltiples, lo que garantiza que los objetos etiquetados con el tipo sean accesibles a través de los atributos correspondientes a sus tipos anteriores.

Mantener el objetivo de ocultar la información de la versión al redactor de políticas significa generar automáticamente los atributos versionados y asignarlos a los tipos apropiados. En el caso común de tipos estáticos, esto es sencillo: type_foo asigna a type_foo_v1 .

Para un cambio en la etiqueta objeto tal como sysfssysfs_A o mediaserveraudioserver , la creación de este mapeo es no trivial (y se describe en los ejemplos anteriores). Los mantenedores de políticas de la plataforma deben determinar cómo crear el mapeo en los puntos de transición para los objetos, lo que requiere comprender la relación entre los objetos y sus etiquetas asignadas y determinar cuándo ocurre esto. Para la compatibilidad con versiones anteriores, esta complejidad debe administrarse en el lado de la plataforma, que es la única partición que puede actualizar.

Versión uprevs

Para simplificar, la plataforma Android lanza una versión sepolicy cuando se corta una nueva rama de lanzamiento. Como se describió anteriormente, el número de versión está contenida en PLATFORM_SEPOLICY_VERSION y es de la forma MM.nn , donde MM corresponde al valor SDK y nn es un valor privada mantenida en /platform/system/sepolicy. Por ejemplo, 19.0 para Kitkat, 21.0 para Lollipop, 22.0 para Lollipop-MR1 23.0 para Marshmallow, 24.0 para turrón, 25.0 para Turrón-MR1, 26.0 para Oreo, 27.0 para Oreo-MR1, y 28.0 para Android 9. Uprevs no son siempre números enteros. Por ejemplo, si un bache MR a una versión requiere un cambio incompatible en el system/sepolicy/public pero no un golpe API, entonces esa versión sepolicy podría ser: vN.1 . La versión presente en una rama de desarrollo es un no-a-ser-usa-en-envío-dispositivos 10000.0 .

Es posible que Android desaproveche la versión más antigua al actualizar. Para obtener información sobre cuándo desaprobar una versión, Android puede recopilar la cantidad de dispositivos con políticas de proveedores que ejecutan esa versión de Android y aún reciben actualizaciones importantes de la plataforma. Si el número es menor que cierto umbral, esa versión está obsoleta.

Impacto en el rendimiento de múltiples atributos

Como se describe en https://github.com/SELinuxProject/cil/issues/9 , un gran número de atributos asignados a un resultado tipo de problemas de rendimiento en el caso de un fallo de caché de política.

Esto fue confirmado a ser un problema en Android, por lo que se hicieron cambios a Android 8.0 para eliminar atributos añadidos a la política por el compilador de la política, así como para eliminar atributos no utilizados. Estos cambios resolvieron las regresiones de rendimiento.

Etiquetado de contextos SELinux

Para admitir la distinción entre la política de plataforma y de proveedor, el sistema crea archivos de contexto SELinux de manera diferente para mantenerlos separados.

Contextos de archivos

Android 8.0 introdujeron los siguientes cambios para file_contexts :

  • Para evitar la sobrecarga de la compilación adicional en el dispositivo durante el arranque, file_contexts dejan de existir en forma binaria. En cambio, son de fácil lectura, archivo de texto la expresión regular, como {property, service}_contexts (ya que fueron pre-7.0).
  • Los file_contexts se dividen entre dos archivos:
    • plat_file_contexts
      • Android plataforma file_context que no tiene etiquetas de dispositivo específicos, a excepción de partes de etiquetado /vendor partición que deben ser etiquetados con precisión para garantizar el buen funcionamiento de los archivos sepolicy.
      • Debe residir en system de partición en el /system/etc/selinux/plat_file_contexts en el dispositivo y ser cargado por init en el inicio junto con el proveedor file_context .
    • vendor_file_contexts
      • -Específica dispositivo file_context construido combinando file_contexts encuentra en los directorios apuntado por BOARD_SEPOLICY_DIRS en el dispositivo de Boardconfig.mk archivos.
      • Debe instalarse en /vendor/etc/selinux/vendor_file_contexts en el vendor partición y ser cargado por init en el inicio junto con la plataforma file_context .

Contextos de propiedad

En Android 8.0, los property_contexts se divide entre dos archivos:

  • plat_property_contexts
    • Android plataforma property_context que no tiene etiquetas de dispositivo específicos.
    • Debe residir en system de partición en el /system/etc/selinux/plat_property_contexts y ser cargado por init en el inicio, junto con los proveedores property_contexts .
  • vendor_property_contexts
    • -Específica dispositivo property_context construido combinando property_contexts encuentra en los directorios apuntado por BOARD_SEPOLICY_DIRS en dispositivos de Boardconfig.mk archivos.
    • Debe residir en vendor partición en /vendor/etc/selinux/vendor_property_contexts y ser cargado por init en el inicio junto con la plataforma property_context

Contextos de servicio

En Android 8.0, los service_contexts se divide entre los siguientes archivos:

  • plat_service_contexts
    • Android plataforma específica service_context para la servicemanager . El service_context no tiene etiquetas de dispositivo específicos.
    • Debe residir en system de partición en el /system/etc/selinux/plat_service_contexts y ser cargado por servicemanager al comienzo junto con los proveedores service_contexts .
  • vendor_service_contexts
    • -Específica dispositivo service_context construido combinando service_contexts encuentra en los directorios apuntado por BOARD_SEPOLICY_DIRS en el dispositivo de Boardconfig.mk archivos.
    • Debe residir en vendor partición en /vendor/etc/selinux/vendor_service_contexts y ser cargado por servicemanager al comienzo junto con la plataforma service_contexts .
    • Aunque servicemanager busca este archivo en tiempo de arranque, para un totalmente compatible TREBLE dispositivo, los vendor_service_contexts , no deberán existir. Esto se debe a toda la interacción entre vendor y system procesos tiene que pasar por hwservicemanager / hwbinder .
  • plat_hwservice_contexts
    • Plataforma Android hwservice_context para hwservicemanager que no tiene etiquetas de dispositivo específicos.
    • Debe residir en system de partición en el /system/etc/selinux/plat_hwservice_contexts y ser cargado por hwservicemanager al comienzo junto con los vendor_hwservice_contexts .
  • vendor_hwservice_contexts
    • -Específica dispositivo hwservice_context construido combinando hwservice_contexts encuentra en los directorios apuntado por BOARD_SEPOLICY_DIRS en el dispositivo de Boardconfig.mk archivos.
    • Debe residir en vendor partición en /vendor/etc/selinux/vendor_hwservice_contexts y ser cargado por hwservicemanager al comienzo junto con los plat_service_contexts .
  • vndservice_contexts
    • -Específica dispositivo service_context para la vndservicemanager construido combinando vndservice_contexts encuentra en los directorios apuntado por BOARD_SEPOLICY_DIRS en el dispositivo de Boardconfig.mk .
    • Este archivo debe residir en el vendor partición en /vendor/etc/selinux/vndservice_contexts y ser cargado por vndservicemanager al inicio.

Contextos de seapp

En Android 8.0, los seapp_contexts se divide entre dos archivos:

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

Permisos MAC

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

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