Control de acceso discrecional (DAC)

Los objetos y servicios del sistema de archivos agregados a la compilación con frecuencia necesitan ID únicos e independientes, conocidos como ID de Android (AID). Actualmente, muchos recursos, como archivos y servicios, usan AID centrales (definidos por Android) innecesariamente; en muchos casos, puede usar AID OEM (definidos por OEM) en su lugar.

Las versiones anteriores de Android (Android 7.x y anteriores) ampliaron el mecanismo de AID utilizando un archivo android_filesystem_config.h específico del dispositivo para especificar las capacidades del sistema de archivos y/o AID de OEM personalizados. Sin embargo, este sistema no era intuitivo ya que no admitía el uso de nombres agradables para los AID de OEM, lo que requería que usted especificara el número sin procesar para los campos de usuario y grupo sin una forma de asociar un nombre descriptivo con el AID numérico.

Las versiones más recientes de Android (Android 8.0 y superior) admiten un nuevo método para ampliar las capacidades del sistema de archivos. Este nuevo método tiene soporte para lo siguiente:

• Múltiples ubicaciones de origen para archivos de configuración (habilita configuraciones de compilación extensibles).
• Comprobación de cordura en tiempo de construcción de los valores OEM AID.
• Generación de un encabezado OEM AID personalizado que se puede usar en archivos fuente según sea necesario.
• Asociación de un nombre descriptivo con el valor real de OEM AID. Admite argumentos de cadena no numéricos para usuarios y grupos, es decir, "foo" en lugar de "2901".

Las mejoras adicionales incluyen la eliminación de la matriz android_ids[] de system/core/libcutils/include/private/android_filesystem_config.h . Esta matriz ahora existe en Bionic como una matriz generada totalmente privada, con accesos a través getpwnam() y getgrnam() . (Esto tiene el efecto secundario de producir binarios estables a medida que se modifican los AID principales). Para obtener herramientas y un archivo LÉAME con más detalles, consulte build/make/tools/fs_config .

Adición de ID de Android (AID)

Android 8.0 eliminó la matriz android_ids[] del Proyecto de código abierto de Android (AOSP). En cambio, todos los nombres compatibles con AID se generan a partir del archivo de encabezado system/core/libcutils/include/private/android_filesystem_config.h cuando se genera la matriz Bionic android_ids[] . Cualquier define que coincida con AID_* es recogida por la herramienta y * se convierte en el nombre en minúsculas.

Por ejemplo, en private/android_filesystem_config.h :

#define AID_SYSTEM 1000

se convierte en:

• Nombre descriptivo: sistema
• uido: 1000
• gid: 1000

Para agregar un nuevo AID principal de AOSP, simplemente agregue #define al archivo de encabezado android_filesystem_config.h . El AID se generará en la compilación y estará disponible para las interfaces que usan argumentos de usuario y grupo. El utillaje valida que el nuevo AID no esté dentro de los rangos de APP u OEM; también respeta los cambios en esos rangos y debe reconfigurarse automáticamente en cambios o nuevos rangos reservados por OEM.

Configuración de AID

Para habilitar el nuevo mecanismo de AID, establezca TARGET_FS_CONFIG_GEN en el archivo BoardConfig.mk . Esta variable contiene una lista de archivos de configuración, lo que le permite agregar archivos según sea necesario.

Por convención, los archivos de configuración usan el nombre config.fs , pero en la práctica puede usar cualquier nombre. Los archivos config.fs están en el formato ini de Python ConfigParser e incluyen una sección de mayúsculas (para configurar las capacidades del sistema de archivos) y una sección de AID (para configurar las AID de OEM).

Configuración de la sección de mayúsculas

La sección de mayúsculas admite la configuración de las capacidades del sistema de archivos en los objetos del sistema de archivos dentro de la compilación (el propio sistema de archivos también debe admitir esta funcionalidad).

Debido a que la ejecución de un servicio estable como raíz en Android provoca una falla de la suite de pruebas de compatibilidad (CTS) , los requisitos anteriores para retener una capacidad mientras se ejecuta un proceso o servicio implicaban configurar capacidades y luego usar setuid / setgid para ejecutar un AID adecuado. Con mayúsculas, puede omitir estos requisitos y hacer que el kernel lo haga por usted. Cuando el control se entrega a main() , su proceso ya tiene las capacidades que necesita para que su servicio pueda usar un usuario y un grupo que no sea root (esta es la forma preferida de iniciar servicios privilegiados).

La sección de mayúsculas utiliza la siguiente sintaxis:

Para ver un ejemplo de uso, consulte Uso de capacidades del sistema de archivos .

Configuración de la sección AID

La sección AID contiene OEM AID y utiliza la siguiente sintaxis:

Para ver ejemplos de uso, consulte Definición de nombres de OEM AID y Uso de OEM AID .

Ejemplos de uso

Los siguientes ejemplos detallan cómo definir y usar un OEM AID y cómo habilitar las capacidades del sistema de archivos. Los nombres OEM AID ( [AID_ nombre ] ) deben comenzar con un nombre de partición como " vendedor_ " para garantizar que no entren en conflicto con futuros nombres AOSP u otras particiones.

Definición de nombres de OEM AID

Para definir un OEM AID, cree un archivo config.fs y establezca el valor AID. Por ejemplo, en device/x/y/config.fs , configure lo siguiente:

[AID_VENDOR_FOO]
value: 2900

Después de crear el archivo, configure la variable TARGET_FS_CONFIG_GEN y apúntela en BoardConfig.mk . Por ejemplo, en device/x/y/BoardConfig.mk , configure lo siguiente:

TARGET_FS_CONFIG_GEN += device/x/y/config.fs

Su AID personalizado ahora puede ser consumido por el sistema en general en una nueva compilación.

Uso de OEM AID

Para usar un OEM AID, en su código C, incluya oemaids_headers en su Makefile asociado y agregue #include "generated_oem_aid.h" , luego comience a usar los identificadores declarados. Por ejemplo, en my_file.c , agregue lo siguiente:

#include "generated_oem_aid.h"
…

If (ipc->uid == AID_VENDOR_FOO) {
  // Do something
...

En su archivo Android.bp asociado, agregue lo siguiente:

header_libs: ["oemaids_headers"],

Si está utilizando un archivo Android.mk , agregue lo siguiente:

LOCAL_HEADER_LIBRARIES := oemaids_headers

Uso de nombres amistosos

En Android 9, puede usar el nombre descriptivo para cualquier interfaz que admita nombres AID. Por ejemplo:

• En un comando chown en some/init.rc :

  chown vendor_foo /vendor/some/vendor_foo/file
  

• En un service en some/init.rc :

  service vendor_foo /vendor/bin/foo_service
      user vendor_foo
      group vendor_foo
  

Debido a que la asignación interna del nombre descriptivo al uid la realiza /vendor/etc/passwd y /vendor/etc/group , se debe montar la partición del proveedor.

Asociación de nombres descriptivos

Android 9 incluye compatibilidad para asociar un nombre descriptivo con el valor real de OEM AID. Puede utilizar argumentos de cadena no numéricos para el usuario y el grupo, es decir, " vendedor_ foo" en lugar de "2901".

Conversión de AID a nombres descriptivos

Para OEM AID , Android 8.x requería el uso de oem_#### con getpwnam y funciones similares, así como en lugares que manejan búsquedas a través getpwnam (como scripts de init ). En Android 9, puede usar los amigos getpwnam y getgrnam en Bionic para convertir ID de Android (AID) en nombres descriptivos y viceversa.

Uso de las capacidades del sistema de archivos

Para habilitar las capacidades del sistema de archivos, cree una sección de mayúsculas en el archivo config.fs . Por ejemplo, en device/x/y/config.fs , agregue la siguiente sección:

[system/bin/foo_service]
mode: 0555
user: AID_VENDOR_FOO
group: AID_SYSTEM
caps: SYS_ADMIN | SYS_NICE

Después de crear el archivo, configure TARGET_FS_CONFIG_GEN para que apunte a ese archivo en BoardConfig.mk . Por ejemplo, en device/x/y/BoardConfig.mk , configure lo siguiente:

TARGET_FS_CONFIG_GEN += device/x/y/config.fs

Cuando se ejecuta el servicio vendor_ foo , comienza con las capacidades CAP_SYS_ADMIN y CAP_SYS_NICE sin llamadas setuid y setgid . Además, la política vendor_ foo del servicio del proveedor_foo ya no necesita la capacidad setuid y setgid y se puede eliminar.

Configuración de anulaciones (Android 6.x-7.x)

Android 6.0 reubicó fs_config y las definiciones de estructura asociadas ( system/core/include/private/android_filesystem_config.h ) a system/core/libcutils/fs_config.c donde podrían actualizarse o anularse mediante archivos binarios instalados en /system/etc/fs_config_dirs y /system/etc/fs_config_files . El uso de reglas de comparación y análisis separadas para directorios y archivos (que podrían usar expresiones globales adicionales) permitió que Android manejara directorios y archivos en dos tablas diferentes. Las definiciones de estructura en system/core/libcutils/fs_config.c no solo permitían la lectura de directorios y archivos en tiempo de ejecución, sino que el host podía usar los mismos archivos durante el tiempo de compilación para construir imágenes del sistema de archivos como ${OUT}/system/etc/fs_config_dirs y ${OUT}/system/etc/fs_config_files .

Si bien el método de anulación para extender el sistema de archivos fue reemplazado por el sistema de configuración modular introducido en Android 8.0, aún puede usar el método anterior si lo desea. Las siguientes secciones detallan cómo generar e incluir archivos de anulación y configurar el sistema de archivos.

Generación de archivos de anulación

Puede generar los archivos binarios alineados /system/etc/fs_config_dirs y /system/etc/fs_config_files usando la herramienta fs_config_generate en build/tools/fs_config . La herramienta utiliza una función de biblioteca libcutils ( fs_config_generate() ) para administrar los requisitos de DAC en un búfer y define reglas para un archivo de inclusión para institucionalizar las reglas de DAC.

Para usarlo, cree un archivo de inclusión en device/ vendor / device /android_filesystem_config.h que actúe como anulación. El archivo debe usar el formato de structure fs_path_config definido en system/core/include/private/android_filesystem_config.h con las siguientes inicializaciones de estructura para símbolos de directorio y archivo:

• Para directorios, use android _device _dirs[] .
• Para archivos, use android _device _files[] .

Cuando no utilice android_device_dirs[] y android_device_files[] , puede definir NO_ANDROID_FILESYSTEM_CONFIG_DEVICE_DIRS y NO_ANDROID_FILESYSTEM_CONFIG_DEVICE_FILES (vea el ejemplo a continuación). También puede especificar el archivo de anulación mediante TARGET_ANDROID_FILESYSTEM_CONFIG_H en la configuración de la placa, con un nombre base obligatorio de android_filesystem_config.h .

Incluyendo archivos de anulación

Para incluir archivos, asegúrese de que PRODUCT_PACKAGES incluya fs_config_dirs y/o fs_config_files para que pueda instalarlos en /system/etc/fs_config_dirs y /system/etc/fs_config_files , respectivamente. El sistema de compilación busca android_filesystem_config.h personalizado en $(TARGET_DEVICE_DIR) , donde existe BoardConfig.mk . Si este archivo existe en otro lugar, configure la variable de configuración de la placa TARGET_ANDROID_FILESYSTEM_CONFIG_H para que apunte a esa ubicación.

Configurando el sistema de archivos

Para configurar el sistema de archivos en Android 6.0 y superior:

1. Cree el archivo $(TARGET_DEVICE_DIR)/android_filesystem_config.h .
2. Agregue fs_config_dirs y/o fs_config_files a PRODUCT_PACKAGES en el archivo de configuración de la placa (por ejemplo, $(TARGET_DEVICE_DIR)/device.mk ).

Ejemplo de anulación

Este ejemplo muestra un parche para anular el daemon system/bin/glgps para agregar compatibilidad con wake lock en el directorio device/ vendor / device . Tenga en cuenta lo siguiente:

• Cada entrada de estructura es el modo, uid, gid, capacidades y el nombre. system/core/include/private/android_filesystem_config.h se incluye automáticamente para proporcionar el manifiesto #defines ( AID_ROOT , AID_SHELL , CAP_BLOCK_SUSPEND ).
• La sección android_device_files[] incluye una acción para suprimir el acceso a system/etc/fs_config_dirs cuando no se especifica, lo que sirve como una protección DAC adicional por falta de contenido para anulaciones de directorio. Sin embargo, esta es una protección débil; si alguien tiene control sobre /system , normalmente puede hacer lo que quiera.

diff --git a/android_filesystem_config.h b/android_filesystem_config.h
new file mode 100644
index 0000000..874195f
--- /dev/null
+++ b/android_filesystem_config.h
@@ -0,0 +1,36 @@
+/*
+ * Copyright (C) 2015 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *      http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+ * implied. See the License for the specific language governing
+ * permissions and limitations under the License.
+ */
+
+/* This file is used to define the properties of the filesystem
+** images generated by build tools (eg: mkbootfs) and
+** by the device side of adb.
+*/
+
+#define NO_ANDROID_FILESYSTEM_CONFIG_DEVICE_DIRS
+/* static const struct fs_path_config android_device_dirs[] = { }; */
+
+/* Rules for files.
+** These rules are applied based on "first match", so they
+** should start with the most specific path and work their
+** way up to the root. Prefixes ending in * denotes wildcard
+** and will allow partial matches.
+*/
+static const struct fs_path_config android_device_files[] = {
+  { 00755, AID_ROOT, AID_SHELL, (1ULL << CAP_BLOCK_SUSPEND),
"system/bin/glgps" },
+#ifdef NO_ANDROID_FILESYSTEM_CONFIG_DEVICE_DIRS
+  { 00000, AID_ROOT, AID_ROOT, 0, "system/etc/fs_config_dirs" },
+#endif
+};


diff --git a/device.mk b/device.mk
index 0c71d21..235c1a7 100644
--- a/device.mk
+++ b/device.mk
@@ -18,7 +18,8 @@ PRODUCT_PACKAGES := \
     libwpa_client \
     hostapd \
     wpa_supplicant \
-    wpa_supplicant.conf
+    wpa_supplicant.conf \
+    fs_config_files

 ifeq ($(TARGET_PREBUILT_KERNEL),)
 ifeq ($(USE_SVELTE_KERNEL), true)

Migración de sistemas de archivos de versiones anteriores

Al migrar sistemas de archivos de Android 5.x y versiones anteriores, tenga en cuenta que Android 6.x

• Elimina algunas inclusiones, estructuras y definiciones en línea.
• Requiere una referencia a libcutils en lugar de ejecutarse directamente desde system/core/include/private/android_filesystem_config.h . Los ejecutables privados del fabricante del dispositivo que dependen de system/code/include/private_filesystem_config.h para las estructuras de archivos o directorios o fs_config deben agregar dependencias de la biblioteca libcutils .
• Requiere copias de la rama privada del fabricante del dispositivo de system/core/include/private/android_filesystem_config.h con contenido adicional en los objetivos existentes para mover a device/ vendor / device /android_filesystem_config.h .
• se reserva el derecho de aplicar los controles de acceso obligatorio (MAC) de SELinux a los archivos de configuración en el sistema de destino, las implementaciones que incluyen ejecutables de destino personalizados mediante fs_config() deben garantizar el acceso.