Esta página se ha traducido con Cloud Translation API.

Implementando SELinux

SELinux está configurado para denegar de forma predeterminada, lo que significa que cada acceso para el que tiene un enlace en el kernel debe estar permitido explícitamente por política. Esto significa que un archivo de política se compone de una gran cantidad de información sobre reglas, tipos, clases, permisos y más. Una consideración completa de SELinux está fuera del alcance de este documento, pero ahora es esencial comprender cómo escribir reglas de políticas al presentar nuevos dispositivos Android. Ya hay una gran cantidad de información disponible sobre SELinux. Consulte la documentación de respaldo para ver los recursos sugeridos.

Archivos clave

Para habilitar SELinux, integre el último kernel de Android y luego incorpore los archivos que se encuentran en el directorio system/sepolicy . Cuando se compilan, esos archivos comprenden la política de seguridad del kernel de SELinux y cubren el sistema operativo Android.

En general, no debe modificar los archivos del system/sepolicy directamente. En su lugar, agregue o edite sus propios archivos de políticas específicos del dispositivo en el directorio /device/ manufacturer / device-name /sepolicy . En Android 8.0 y versiones posteriores, los cambios que realice en estos archivos solo deberían afectar la política en su directorio de proveedores. Para obtener más detalles sobre la separación de la política pública en Android 8.0 y versiones posteriores, consulte Personalización de SEPolicy en Android 8.0+ . Independientemente de la versión de Android, todavía estás modificando estos archivos:

Archivos de políticas

Los archivos que terminan con *.te son archivos fuente de políticas de SELinux, que definen dominios y sus etiquetas. Es posible que deba crear nuevos archivos de políticas en /device/ manufacturer / device-name /sepolicy , pero debe intentar actualizar los archivos existentes siempre que sea posible.

Archivos de contexto

Los archivos de contexto son donde usted especifica etiquetas para sus objetos.

file_contexts asigna etiquetas a archivos y es utilizado por varios componentes del espacio de usuario. A medida que crea nuevas políticas, cree o actualice este archivo para asignar nuevas etiquetas a los archivos. Para aplicar nuevos file_contexts , reconstruya la imagen del sistema de archivos o ejecute restorecon en el archivo que se va a volver a etiquetar. En las actualizaciones, los cambios en file_contexts se aplican automáticamente al sistema y a las particiones de datos del usuario como parte de la actualización. Los cambios también se pueden aplicar automáticamente al actualizar a otras particiones agregando llamadas restorecon_recursive a su init. board el archivo .rc después de que la partición se haya montado en lectura y escritura.
genfs_contexts asigna etiquetas a sistemas de archivos, como proc o vfat , que no admiten atributos extendidos. Esta configuración se carga como parte de la política del kernel, pero es posible que los cambios no surtan efecto para los inodos internos, lo que requiere reiniciar o desmontar y volver a montar el sistema de archivos para aplicar completamente el cambio. También se pueden asignar etiquetas específicas a montajes específicos, como vfat usando la opción context=mount .
property_contexts asigna etiquetas a las propiedades del sistema Android para controlar qué procesos pueden establecerlas. Esta configuración es leída por el proceso init durante el inicio.
service_contexts asigna etiquetas a los servicios de carpeta de Android para controlar qué procesos pueden agregar (registrar) y encontrar (buscar) una referencia de carpeta para el servicio. El proceso del servicemanager lee esta configuración durante el inicio.
seapp_contexts asigna etiquetas a los procesos de la aplicación y a los directorios /data/data . El proceso zygote lee esta configuración en cada inicio de la aplicación y la installd durante el inicio.
mac_permissions.xml asigna una etiqueta seinfo a las aplicaciones según su firma y, opcionalmente, el nombre de su paquete. Luego, la etiqueta seinfo se puede usar como clave en el archivo seapp_contexts para asignar una etiqueta específica a todas las aplicaciones con esa etiqueta seinfo . system_server lee esta configuración durante el inicio.
keystore2_key_contexts asigna etiquetas a los espacios de nombres de Keystore 2.0. Estos espacios de nombres los aplica el demonio keystore2. Keystore siempre ha proporcionado espacios de nombres basados en UID/AID. Keystore 2.0 además aplica espacios de nombres definidos por política. Puede encontrar una descripción detallada del formato y las convenciones de este archivo aquí .

Archivo MAKE BoardConfig.mk

Después de editar o agregar archivos de política y contexto, actualice su archivo make /device/ manufacturer / device-name /BoardConfig.mk para hacer referencia al subdirectorio sepolicy y a cada nuevo archivo de política. Para obtener más información sobre las variables BOARD_SEPOLICY , consulte el archivo system/sepolicy/README .

BOARD_SEPOLICY_DIRS += \
        <root>/device/manufacturer/device-name/sepolicy

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

Después de la reconstrucción, su dispositivo está habilitado con SELinux. Ahora puede personalizar sus políticas SELinux para acomodar sus propias adiciones al sistema operativo Android como se describe en Personalización o verificar su configuración existente como se describe en Validación .

Cuando los nuevos archivos de política y las actualizaciones de BoardConfig.mk están implementados, la nueva configuración de política se integra automáticamente en el archivo de política final del kernel. Para obtener más información sobre cómo se crea sepolicy en el dispositivo, consulte Creación de sepolicy .

Implementación

Para comenzar con SELinux:

Habilite SELinux en el kernel: CONFIG_SECURITY_SELINUX=y
Cambie el parámetro kernel_cmdline o bootconfig de modo que:
```
BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
```
o
```
BOARD_BOOTCONFIG := androidboot.selinux=permissive
```
Esto es solo para el desarrollo inicial de la política para el dispositivo. Después de tener una política de arranque inicial, elimine este parámetro para que su dispositivo aplique o fallará CTS.

Inicie el sistema en modo permisivo y vea qué denegaciones se encuentran en el arranque:
En Ubuntu 14.04 o posterior:

adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy

En Ubuntu 12.04:

adb pull /sys/fs/selinux/policy
adb logcat -b all | audit2allow -p policy

Evalúe el resultado en busca de advertencias similares a init: Warning! Service name needs a SELinux domain defined; please fix! Consulte Validación para obtener instrucciones y herramientas.
Identifique dispositivos y otros archivos nuevos que necesiten etiquetarse.
Utilice etiquetas nuevas o existentes para sus objetos. Mire los archivos *_contexts para ver cómo se etiquetaron las cosas anteriormente y utilice el conocimiento de los significados de las etiquetas para asignar una nueva. Idealmente, será una etiqueta existente que se ajuste a la política, pero a veces será necesaria una nueva etiqueta y se necesitarán reglas para el acceso a esa etiqueta. Agregue sus etiquetas a los archivos de contexto apropiados.
Identifique dominios/procesos que deberían tener sus propios dominios de seguridad. Probablemente necesitará redactar una política completamente nueva para cada uno. Todos los servicios generados a partir de init , por ejemplo, deberían tener los suyos propios. Los siguientes comandos ayudan a revelar aquellos que permanecen ejecutándose (pero TODOS los servicios necesitan ese tratamiento):
```
adb shell su -c ps -Z | grep init
```
```
adb shell su -c dmesg | grep 'avc: '
```
Revisar init. device .rc para identificar cualquier dominio que no tenga un tipo de dominio. Bríndeles un dominio al principio de su proceso de desarrollo para evitar agregar reglas a init o confundir los accesos init con los que están en su propia política.
Configure BOARD_CONFIG.mk para usar variables BOARD_SEPOLICY_* . Consulte el archivo README en system/sepolicy para obtener detalles sobre cómo configurar esto.
Examina el inicio. device .rc y fstab. archivo device y asegúrese de que cada uso de mount corresponda a un sistema de archivos correctamente etiquetado o que se especifique una opción context= mount .
Revise cada denegación y cree una política SELinux para manejar cada una adecuadamente. Vea los ejemplos en Personalización .

Debe comenzar con las políticas del AOSP y luego desarrollarlas para sus propias personalizaciones. Para obtener más información sobre la estrategia de políticas y una mirada más cercana a algunos de estos pasos, consulte Redacción de políticas SELinux .

Casos de uso

A continuación se muestran ejemplos específicos de exploits a considerar al crear su propio software y políticas SELinux asociadas:

Enlaces simbólicos : debido a que los enlaces simbólicos aparecen como archivos, a menudo se leen como archivos, lo que puede generar vulnerabilidades. Por ejemplo, algunos componentes privilegiados, como init , cambian los permisos de ciertos archivos, a veces para que sean excesivamente abiertos.

Luego, los atacantes podrían reemplazar esos archivos con enlaces simbólicos al código que controlan, lo que les permitiría sobrescribir archivos arbitrarios. Pero si sabe que su aplicación nunca atravesará un enlace simbólico, puede prohibirle que lo haga con SELinux.

Archivos del sistema : considere la clase de archivos del sistema que solo el servidor del sistema debe modificar. Aún así, dado que netd , init y vold se ejecutan como root, pueden acceder a esos archivos del sistema. Entonces, si netd se ve comprometido, podría comprometer esos archivos y potencialmente el servidor del sistema.

Con SELinux, puede identificar esos archivos como archivos de datos del servidor del sistema. Por lo tanto, el único dominio que tiene acceso de lectura/escritura es el servidor del sistema. Incluso si netd se viera comprometido, no podría cambiar de dominio al dominio del servidor del sistema y acceder a esos archivos del sistema aunque se ejecute como root.

Datos de la aplicación : otro ejemplo es la clase de funciones que deben ejecutarse como root pero no deben acceder a los datos de la aplicación. Esto es increíblemente útil ya que se pueden hacer afirmaciones de amplio alcance, como que a ciertos dominios no relacionados con los datos de la aplicación se les prohíba el acceso a Internet.

setattr : para comandos como chmod y chown , puede identificar el conjunto de archivos donde el dominio asociado puede ejecutar setattr . Cualquier cosa fuera de eso podría quedar prohibida en estos cambios, incluso por root. Por lo tanto, una aplicación podría ejecutar chmod y chown contra los app_data_files etiquetados pero no contra shell_data_files o system_data_files .