SELinux está configurado para denegar por defecto, lo que significa que la política debe permitir explícitamente cada acceso para el que tiene un gancho en el núcleo. 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 la comprensión de cómo escribir reglas de políticas ahora es esencial cuando se presentan nuevos dispositivos Android. Ya hay una gran cantidad de información disponible sobre SELinux. Consulte la documentación de apoyo para conocer los recursos sugeridos.
Archivos clave
Para habilitar SELinux, integre el kernel de Android más reciente 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 ascendente.
En general, no debe modificar los archivos system/sepolicy
directamente. En su lugar, agregue o edite sus propios archivos de política 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 y versiones posteriores. Independientemente de la versión de Android, todavía está modificando estos archivos:
Archivos de políticas
Los archivos que terminan en *.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 especifica etiquetas para sus objetos.
-
file_contexts
asigna etiquetas a los 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 nuevosfile_contexts
, reconstruya la imagen del sistema de archivos o ejecuterestorecon
en el archivo que se va a volver a etiquetar. En las actualizaciones, los cambios enfile_contexts
se aplican automáticamente al sistema y a las particiones de datos de usuario como parte de la actualización. Los cambios también se pueden aplicar automáticamente al actualizar a otras particiones agregando llamadas arestorecon_recursive
a su init. board .rc archivo después de que la partición se haya montado en lectura y escritura. -
genfs_contexts
asigna etiquetas a los sistemas de archivos, comoproc
ovfat
, que no admiten atributos extendidos. Esta configuración se carga como parte de la política del núcleo, 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 el cambio por completo. También se pueden asignar etiquetas específicas a montajes específicos, comovfat
usando la opcióncontext=mount
. -
property_contexts
asigna etiquetas a las propiedades del sistema Android para controlar qué procesos pueden establecerlas. El procesoinit
lee esta configuración durante el inicio. -
service_contexts
asigna etiquetas a los servicios de enlace de Android para controlar qué procesos pueden agregar (registrar) y encontrar (buscar) una referencia de enlace para el servicio. El proceso del administrador deservicemanager
lee esta configuración durante el inicio. -
seapp_contexts
asigna etiquetas a los procesos de la aplicación y directorios/data/data
. Esta configuración es leída por el procesozygote
en cada lanzamiento de la aplicación y porinstalld
durante el inicio. -
mac_permissions.xml
asigna una etiquetaseinfo
a las aplicaciones según su firma y, opcionalmente, el nombre de su paquete. La etiquetaseinfo
se puede usar como clave en el archivoseapp_contexts
para asignar una etiqueta específica a todas las aplicaciones con esa etiquetaseinfo
.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 son impuestos por el daemon keystore2. Keystore siempre ha proporcionado espacios de nombres basados en UID/AID. Keystore 2.0 también aplica espacios de nombres definidos por políticas. Puede encontrar una descripción detallada del formato y las convenciones de este archivo aquí .
Archivo MAKE de BoardConfig.mk
Después de editar o agregar archivos de política y contexto, actualice su /device/ manufacturer / device-name /BoardConfig.mk
makefile para hacer referencia al subdirectorio sepolicy
y 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 de 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 en su lugar, 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 genera sepolicy en el dispositivo, consulte Creación de sepolicy .
Implementación
Para comenzar con SELinux:
- Habilite SELinux en el núcleo:
CONFIG_SECURITY_SELINUX=y
- Cambie el parámetro kernel_cmdline o bootconfig para que:
BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
oBOARD_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 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 la salida en busca de advertencias que se parezcan 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 necesitan etiquetado.
- Utilice etiquetas existentes o nuevas para sus objetos. Mire los archivos
*_contexts
para ver cómo se etiquetaron las cosas previamente y use el conocimiento de los significados de las etiquetas para asignar uno nuevo. Idealmente, esta será una etiqueta existente que encajará en la política, pero a veces se necesitará una nueva etiqueta y se necesitarán reglas para acceder a esa etiqueta. Agregue sus etiquetas a los archivos de contexto apropiados. - Identificar dominios/procesos que deberían tener sus propios dominios de seguridad. Es probable que deba escribir una política completamente nueva para cada uno. Todos los servicios generados desde
init
, por ejemplo, deberían tener los suyos propios. Los siguientes comandos ayudan a revelar aquellos que siguen ejecutándose (pero TODOS los servicios necesitan tal 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. Déles un dominio al principio de su proceso de desarrollo para evitar agregar reglas ainit
o confundir los accesosinit
con los que están en su propia política. - Configure
BOARD_CONFIG.mk
para usar las variablesBOARD_SEPOLICY_*
. Consulte el LÉAME ensystem/sepolicy
para obtener detalles sobre cómo configurar esto. - Examine el inicio. device .rc y fstab. device y asegúrese de que cada uso de
mount
corresponda a un sistema de archivos correctamente etiquetado o que se especifique una opcióncontext= mount
. - Revise cada denegación y cree una política de SELinux para manejar cada una de manera adecuada. Ver los ejemplos en Personalización .
Debe comenzar con las políticas en el 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 detallada a algunos de estos pasos, consulte Escritura de políticas de SELinux .
casos de uso
Estos son ejemplos específicos de vulnerabilidades a tener en cuenta al crear su propio software y las políticas de SELinux asociadas:
Enlaces simbólicos : debido a que los enlaces simbólicos aparecen como archivos, a menudo se leen como archivos, lo que puede conducir a 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 le permite al atacante sobrescribir archivos arbitrarios. Pero si sabe que su aplicación nunca atravesará un enlace simbólico, puede prohibir que lo haga con SELinux.
Archivos del sistema: tenga en cuenta la clase de archivos del sistema que solo debe modificar el servidor del sistema. Aún así, dado que netd
, init
y vold
se ejecutan como root, pueden acceder a esos archivos del sistema. Entonces, si netd
se viera comprometido, podría comprometer esos archivos y potencialmente el propio 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 a ellos es el servidor del sistema. Incluso si netd
se viera comprometido, no podría cambiar los dominios al dominio del servidor del sistema y acceder a esos archivos del sistema aunque se ejecuta como root.
Datos de la aplicación : otro ejemplo es la clase de funciones que deben ejecutarse como root pero que no deben acceder a los datos de la aplicación. Esto es increíblemente útil ya que se pueden hacer afirmaciones de gran alcance, como que ciertos dominios no relacionados con los datos de la aplicación tienen prohibido el acceso a Internet.
setattr : para comandos como chmod
y chown
, puede identificar el conjunto de archivos donde el dominio asociado puede realizar setattr
. Cualquier cosa fuera de eso podría estar prohibida por estos cambios, incluso por root. Por lo tanto, una aplicación puede ejecutar chmod
y chown
contra aquellos etiquetados como app_data_files
pero no como shell_data_files
o system_data_files
.