SELinux está configurado como default-deny, lo que significa que cada acceso el que tiene un hook en el kernel debe estar permitido explícitamente por la política. Esta significa que un archivo de políticas está compuesto por una gran cantidad de información sobre reglas, tipos, clases, permisos y mucho más. Consideración completa de SELinux está fuera del alcance de este documento, pero una comprensión de cómo escribir reglas de políticas ahora es esencial a la hora de incorporar nuevos dispositivos Android. Hay un hay gran cantidad de información disponible sobre SELinux. Consulta Asistencia documentación para obtener los recursos sugeridos.
Archivos de claves
Para habilitar SELinux, integra el más reciente kernel de Android y, luego, incorpora los archivos del sistema/sepolítica . Cuando se compilan, esos archivos comprenden el kernel de seguridad de SELinux y abarcan el sistema operativo Android ascendente.
En general, no debes modificar los archivos system/sepolicy
directamente. En su lugar, agrega o edita tus propios archivos de políticas específicos para dispositivos en la
/device/manufacturer/device-name/sepolicy
. En Android 8.0 y versiones posteriores, los cambios que realices en estos archivos deberían
solo afectan la política del directorio de tu proveedor. Para obtener más detalles sobre la separación de
en Android 8.0 y versiones posteriores, consulta
Cómo personalizar SEPolicy en Android
8.0 o versiones posteriores. Independientemente de la versión de Android, seguirás modificando estos archivos:
Archivos de políticas
Los archivos que terminan con *.te
son archivos de origen de políticas de SELinux, que
definir dominios y sus etiquetas. Es posible que debas crear nuevos archivos de políticas en
/device/manufacturer/device-name/sepolicy
,
pero intenta actualizar los archivos existentes siempre que sea posible.
Archivos de contexto
Los archivos de contexto son el lugar donde especificas etiquetas para tus objetos.
file_contexts
asigna etiquetas a los archivos y lo usan varios del espacio del usuario. Cuando crees políticas nuevas, crea o actualiza este archivo para asignar nuevas etiquetas a los archivos. Para aplicar las nuevasfile_contexts
, sigue estos pasos: vuelve a compilar la imagen del sistema de archivos o ejecutarestorecon
en el archivo para que se puede volver a etiquetar. Durante las actualizaciones, se aplicarán los cambios afile_contexts
automáticamente al sistema y a las particiones de userdata como parte del actualización. Los cambios también se pueden aplicar automáticamente cuando se actualiza a otros particiones agregando llamadasrestorecon_recursive
al Archivo init.board.rc después de activar la partición lectura y escritura.genfs_contexts
asigna etiquetas a los sistemas de archivos, como las siguientes:proc
ovfat
que no admiten atributos. Esta configuración se carga como parte de la política de kernel es posible que los cambios no tengan efecto para los inodos del núcleo, lo que requiere desactivar y volver a activar el sistema de archivos para aplicar el cambio por completo. También se pueden asignar etiquetas específicas a activaciones específicas, comovfat
con la opcióncontext=mount
property_contexts
asigna etiquetas a las propiedades del sistema Android para lo siguiente: controlan qué procesos pueden establecerlas. El administrador lee esta configuracióninit
durante el inicio.service_contexts
asigna etiquetas a los servicios de Binder de Android para controlar qué procesos pueden agregar (registrar) y encontrar (buscar) un Binder referencia del servicio. El administrador lee esta configuraciónservicemanager
durante el inicio.seapp_contexts
asigna etiquetas a los procesos de la app y/data/data
directorios. El administrador lee esta configuración Proceso dezygote
en cada inicio de la app y antes delinstalld
durante el inicio.mac_permissions.xml
asigna una etiquetaseinfo
a las apps según su firma y, opcionalmente, el nombre de su paquete. El La etiquetaseinfo
se puede usar como clave en el archivoseapp_contexts
para asignar una etiqueta específica a todas las apps que esa etiquetaseinfo
. Esta configuración es leída porsystem_server
durante el inicio.keystore2_key_contexts
asigna etiquetas a los espacios de nombres del almacén de claves 2.0. El daemon keystore2 aplica estos espacios de nombres. El almacén de claves siempre espacios de nombres basados en UID/AID proporcionados. Keystore 2.0 aplica adicionalmente la política. los espacios de nombres definidos. Una descripción detallada de su formato y convenciones aquí.
Archivo makefile BoardConfig.mk
Después de editar o agregar archivos de políticas y contexto, actualiza tu
/device/manufacturer/device-name/BoardConfig.mk
Make para hacer referencia al subdirectorio sepolicy
y a cada archivo de política nuevo.
Para obtener más información sobre las variables BOARD_SEPOLICY
, consulta
system/sepolicy/README
.
BOARD_SEPOLICY_DIRS += \ <root>/device/manufacturer/device-name/sepolicy BOARD_SEPOLICY_UNION += \ genfs_contexts \ file_contexts \ sepolicy.te
Después de volver a compilar, el dispositivo quedará habilitado con SELinux. Ahora puedes hacer lo siguiente: personaliza tus políticas de SELinux para que admitan tus propias adiciones al sistema operativo Android, como se describe en Personalización o verifica tu configuración existente, como se aborda en Validación.
Cuando los nuevos archivos de política y las actualizaciones de BoardConfig.mk estén en su lugar, el nuevo la configuración de la política se integra automáticamente en el archivo de política del kernel final. Para obtener más información sobre cómo se crea la política en el dispositivo, consulta Compilación de la política.
Implementación
Para comenzar a usar SELinux, haz lo siguiente:
- Habilita SELinux en el kernel:
CONFIG_SECURITY_SELINUX=y
- Cambia el parámetro kernel_cmdline o bootconfig para que:
oBOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
Esto es solo para el desarrollo inicial de la política para el dispositivo. Después de si tienes una política de arranque inicial, quita este parámetro el dispositivo está aplicando de manera forzosa o fallará el CTS.BOARD_BOOTCONFIG := androidboot.selinux=permissive
- Inicia el sistema de manera permisiva y observa qué denegaciones se encuentran durante el inicio:
En Ubuntu 14.04 o versiones posteriores: En Ubuntu 12.04:adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy
adb pull /sys/fs/selinux/policy adb logcat -b all | audit2allow -p policy
- Evalúa el resultado en busca de advertencias similares a
init: Warning! Service name needs a SELinux domain defined; please fix!
. Consulta Validación de las instrucciones y herramientas de la nube. - Identifica dispositivos y otros archivos nuevos que deben etiquetar.
- Usa etiquetas existentes o nuevas para tus objetos. Consulta
*_contexts
de archivos para ver cómo se etiquetaron anteriormente y usar el conocimiento de los significados de las etiquetas para asignar una nueva. Idealmente, será una etiqueta existente que encajará en una política, pero a veces se necesitará una etiqueta nueva y se establecerán las reglas para acceder a ella según tus necesidades. Agrega tus etiquetas a los archivos de contexto correspondientes. - Identifica dominios o procesos que deben tener sus propios dominios de seguridad.
Es probable que debas escribir una política completamente nueva para cada una. Todo
servicios generados a partir de
init
, por ejemplo, deben tener su por sí solas. Los siguientes comandos ayudan a revelar aquellos que permanecen en ejecución (pero TODAS servicios necesitan ese tratamiento):
adb shell su -c ps -Z | grep init
adb shell su -c dmesg | grep 'avc: '
- Revisa
init.device.rc
para identificar los dominios que que no tienen un tipo de dominio. Asígnales un dominio anticipadamente en tu de desarrollo para evitar agregar reglas ainit
de lo contrario, se confunden los accesosinit
con los que están en su propia política. - Configura
BOARD_CONFIG.mk
para usarBOARD_SEPOLICY_*
variables. Consulta la README ensystem/sepolicy
para obtener detalles sobre la configuración. - Examina los archivos init.device.rc y fstab.device y
asegúrate de que cada uso de
mount
se corresponda con una un sistema de archivos etiquetado o que una opcióncontext= mount
sea especificada. - Revisa cada rechazo y crea una política SELinux para controlar cada uno de manera correcta. Consulta los ejemplos en Personalización.
Debes comenzar con las políticas del AOSP y, luego, basarse en ellas para tus propias personalizaciones. Para obtener más información sobre la estrategia de políticas un análisis más detallado de algunos de estos pasos, Escribe la política de SELinux.
Casos de uso
Estos son ejemplos específicos de exploits que debes tener en cuenta cuando diseñes el tuyo y las políticas de SELinux asociadas:
Vínculos simbólicos: Debido a que los symlinks aparecen como archivos, a menudo se
se pueden leer como archivos, lo que puede generar vulnerabilidades. Por ejemplo, algunos permisos
componentes, como init
, cambian los permisos de ciertos archivos,
a veces están demasiado abiertos.
Los atacantes podrían reemplazar esos archivos con symlinks a un código que controlen, lo que le permite al atacante reemplazar archivos arbitrarios. Pero si sabes aplicación jamás atravesará un symlink, puedes prohibirle que lo haga. con SELinux.
Archivos del sistema: considera la clase de archivos del sistema que
solo las puede modificar el servidor del sistema. Sin embargo, desde el netd
,
init
y vold
se ejecutan como raíz, pueden acceder
esos archivos del sistema. Por lo tanto, si netd
se vio comprometido, podría
comprometer esos archivos
y potencialmente el propio servidor del sistema.
Con SELinux, puedes 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 veía comprometido, no podría cambiar de dominio al
dominio del servidor del sistema y acceder a los archivos del sistema aunque se ejecute como raíz.
Datos de app: otro ejemplo es la clase de funciones que debe ejecutarse como raíz, pero no debería poder acceder a los datos de la app. Esto es increíblemente útiles, ya que se pueden realizar aserciones de mayor alcance, como ciertos dominios no relacionados, y a los datos de las aplicaciones que tengan prohibido acceder a Internet.
setattr: se usa en comandos como chmod
y
chown
, puedes identificar el conjunto de archivos en los que están asociados
puede realizar setattr
. Cualquier cosa fuera de eso podría
de estos cambios, incluso por la raíz. Entonces, una aplicación podría ejecutarse
chmod
y chown
en comparación con aquellos etiquetados
app_data_files
, pero no shell_data_files
o system_data_files
.