Google se compromete a promover la equidad racial para las comunidades negras. Ver cómo.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Proveedor Init

El proceso de inicio tiene permisos casi ilimitados y utiliza secuencias de comandos de entrada tanto del sistema como de las particiones del proveedor para inicializar el sistema durante el proceso de arranque. Este acceso causa un gran agujero en la división del sistema / proveedor de agudos, ya que las secuencias de comandos del proveedor pueden indicar a init que acceda a archivos, propiedades, etc. que no forman parte de la interfaz binaria (ABI) estable de la aplicación del proveedor del sistema.

Vendor init está diseñado para cerrar este agujero mediante el uso de un dominio de Linux (SELinux) con seguridad mejorada vendor_init para ejecutar comandos encontrados en /vendor con permisos específicos del proveedor.

Mecanismo

El proveedor init bifurca un subproceso de init al principio del proceso de arranque con el contexto SELinux u:r:vendor_init:s0 . Este contexto de SELinux tiene considerablemente menos permisos que el contexto de inicio predeterminado y su acceso se limita a archivos, propiedades, etc. que son específicos del proveedor o parte de la ABI estable del proveedor del sistema.

Init verifica cada script que carga para ver si su ruta comienza con /vendor y, de ser así, lo etiqueta con una indicación de que sus comandos deben ejecutarse en el contexto init del proveedor. Cada init incorporado está anotado con un valor booleano que especifica si el comando debe ejecutarse o no en el subproceso init del proveedor:

  • La mayoría de los comandos que acceden al sistema de archivos están anotados para ejecutarse en el subproceso init del proveedor y, por lo tanto, están sujetos a la SEPolicy init del proveedor.
  • La mayoría de los comandos que afectan el estado de inicio interno (p. Ej., Iniciar y detener servicios) se ejecutan dentro del proceso de inicio normal. Estos comandos se dan cuenta de que una secuencia de comandos del proveedor los llama a hacer su propio manejo de permisos que no son de SELinux.

El ciclo de procesamiento principal de init contiene una comprobación de que si un comando se anota para ejecutarse en el subproceso del proveedor y se origina en un script del proveedor, ese comando se envía a través de la comunicación entre procesos (IPC) al subproceso de inicio del proveedor, que ejecuta el comando y envía el resultado de nuevo a init.

Usando el proveedor Init

El proveedor init está habilitado de forma predeterminada y sus restricciones se aplican a todos los scripts de inicio presentes en la partición /vendor . El init del proveedor debe ser transparente para los proveedores cuyos scripts ya no acceden a los archivos, propiedades, etc. del sistema.

Sin embargo, si los comandos en un script de proveedor dado violan las restricciones de inicio del proveedor, los comandos fallarán. Los comandos que fallan tienen una línea en el registro del núcleo (visible con dmesg) desde init que indica un error. Una auditoría de SELinux acompaña a cualquier comando fallido que haya fallado debido a la política de SELinux. Ejemplo de una falla que incluye una auditoría SELinux:

type=1400 audit(1511821362.996:9): avc: denied { search } for pid=540 comm="init" name="nfc" dev="sda45" ino=1310721 scontext=u:r:vendor_init:s0 tcontext=u:object_r:nfc_data_file:s0 tclass=dir permissive=0
init: Command 'write /data/nfc/bad_file_access 1234' action=boot (/vendor/etc/init/hw/init.walleye.rc:422) took 2ms and failed: Unable to write to file '/data/nfc/bad_file_access': open() failed: Permission denied

Si un comando falla, hay dos opciones:

  • Si el comando falla debido a una restricción prevista (como si el comando está accediendo a un archivo o propiedad del sistema), el comando debe volver a implementarse de manera amigable con los agudos, pasando solo por interfaces estables. Las reglas de Neverallow evitan agregar permisos para acceder a los archivos del sistema que no forman parte de la ABI estable del proveedor del sistema.
  • Si la etiqueta SELinux es nueva y aún no tiene permisos en el sistema vendor_init.te ni permisos excluidos a través de las reglas neverallow, la nueva etiqueta puede recibir permisos en el vendor_init.te específico del vendor_init.te .

Para dispositivos que se inician antes de Android 9, se pueden omitir las siguientes reglas agregando el data_between_core_and_vendor_violators data_between_core_and_vendor_violators al archivo vendor_init.te específico del dispositivo.

Ubicaciones de código

La mayor parte de la lógica para el proveedor init IPC está en system / core / init / subcontext.cpp .

La tabla de comandos está en la clase BuiltinFunctionMap en system / core / init / builtins.cpp e incluye anotaciones que indican si el comando debe ejecutarse en el subproceso init del proveedor.

SEPolicy para el proveedor init se divide en los directorios privados ( system / sepolicy / private / vendor_init.te ) y public ( system / sepolicy / public / vendor_init.te ) en system / sepolicy.