El Proyecto de código abierto de Android (AOSP) proporciona una política de base sólida para el aplicaciones y servicios comunes en todos los dispositivos Android. Los colaboradores del AOSP definen mejor esta política con regularidad. Se espera que la política principal para representar entre el 90 y el 95% de la política final personalizaciones que componen el 5% al 10% restante. Este artículo se centra en estas personalizaciones específicas del dispositivo, cómo escribir la política específica del dispositivo y algunos de los errores que se deben evitar en el camino.
Abre el dispositivo
Cuando escribas la política específica del dispositivo, sigue estos pasos.
Cómo ejecutar en modo permisivo
Cuando un dispositivo está en modo permisivo, las denegaciones se registran, pero no se aplican. El modo permisivo es importante para dos motivos:
- El modo permisivo garantiza que la introducción de la política no retrase otros para abrir el dispositivo.
- Una denegación forzosa puede enmascarar otras denegaciones. Por ejemplo, acceso a archivos suele implicar una búsqueda en un directorio, un archivo abierto y, luego, una lectura de archivos. En de aplicación forzosa, solo se produce la denegación de la búsqueda del directorio. Permisivo garantiza que se vean todas las denegaciones.
La forma más sencilla de poner un dispositivo en modo permisivo es usar el
Comando del kernel
línea. Se puede agregar al archivo BoardConfig.mk
del dispositivo:
platform/device/<vendor>/<target>/BoardConfig.mk
Después de modificar la línea de comandos, realiza make clean
y, luego,
make bootimage
, escribe la nueva imagen de arranque en la memoria flash.
Luego, confirma el modo permisivo con lo siguiente:
adb shell getenforce
Dos semanas es una cantidad de tiempo razonable para estar en el modo permisivo global. Tras abordar la mayoría de los rechazos, vuelve al modo de aplicación forzosa y abordar los errores a medida que se presentan. Los dominios siguen produciendo denegaciones o los servicios aún en un desarrollo intenso puede ponerse temporalmente en modo permisivo, pero volver al modo de aplicación lo antes posible.
Aplicar de manera anticipada
En el modo de aplicación forzosa, las denegaciones se registran y se aplican. Tiene la mejor activa el modo de aplicación forzosa en el dispositivo lo antes posible. Esperando para crear y aplicar políticas específicas del dispositivo a menudo da como resultado un producto con errores y un mala experiencia del usuario. Comience lo antes posible para participar prueba interna y garantizar una cobertura de prueba completa de funcionalidad en el mundo real. Iniciando garantice con anticipación las inquietudes de seguridad para tomar decisiones de diseño. Por el contrario, otorgar los permisos basados únicamente en las denegaciones observadas es un enfoque no seguro. Usar esta tiempo para realizar una auditoría de seguridad del dispositivo e informar errores relacionados con el comportamiento que no deberían permitirse.
Quita o borra la política existente
Hay una serie de buenas razones para crear una política específica para el dispositivo a partir de desde cero en un dispositivo nuevo, como
- Auditoría de seguridad
- Política demasiado permisiva
- Reducción del tamaño de las políticas
- Política de anuncios inactivos
Cómo abordar las denegaciones de servicios principales
Las denegaciones que generan los servicios principales suelen abordarse mediante el etiquetado de archivos. Por ejemplo:
avc: denied { open } for pid=1003 comm=”mediaserver” path="/dev/kgsl-3d0” dev="tmpfs" scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=1 avc: denied { read write } for pid=1003 name="kgsl-3d0" dev="tmpfs" scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=1
se aborda por completo etiquetando correctamente /dev/kgsl-3d0
. En
En este ejemplo, tcontext
es device
. Esto representa un
contexto predeterminado en el que todo en /dev
recibe el
“
device”, a menos que se asigne una más específica. Solo se acepta
el resultado de
audit2allow
daría como resultado una regla incorrecta y demasiado permisiva.
Para resolver este tipo de problema, ponle al archivo una etiqueta más específica, que en este caso es gpu_device No se necesitan más permisos, ya que mediaserver ya tiene los permisos necesarios en la política principal para acceder gpu_device
Otros archivos específicos del dispositivo que deben etiquetarse con tipos predefinidos en política principal:
- dispositivos de almacenamiento en bloque
- dispositivos de audio
- dispositivos de video
- sensores
- NFC
- dispositivo_gps
- archivos en /sys
- archivos en /proc
En general, no es correcto otorgar permisos a etiquetas predeterminadas. Muchos de estos permisos están permitidos por neverallow, pero aunque esto no esté permitido explícitamente, la práctica recomendada es proporcionar un etiqueta.
Etiquetar servicios y direcciones nuevos rechazos
Es necesario que los servicios iniciados se ejecuten en sus propios dominios SELinux. El El siguiente ejemplo coloca el servicio “foo” en su propio dominio SELinux y le otorga permisos.
El servicio se lanza en la versión
init.device.rc
archivo como:
service foo /system/bin/foo class core
- Crea un nuevo dominio “foo”
Crea el archivo
device/manufacturer/device-name/sepolicy/foo.te
con el siguiente contenido:# foo service type foo, domain; type foo_exec, exec_type, file_type; init_daemon_domain(foo)
Esta es la plantilla inicial para el dominio SELinux de foo, a la cual puedes agregar reglas en función de las operaciones específicas que realiza ese ejecutable.
- Etiqueta
/system/bin/foo
Agrega lo siguiente a
device/manufacturer/device-name/sepolicy/file_contexts
:/system/bin/foo u:object_r:foo_exec:s0
Esto garantiza que el ejecutable esté etiquetado correctamente para que SELinux ejecute servicio en el dominio adecuado.
- Compila e instala las imágenes de arranque y del sistema.
- Define mejor las reglas de SELinux para el dominio.
Usa denegaciones para determinar los permisos necesarios. El audit2allow brinda buenos lineamientos, pero úsala solo para informar políticas escritura. No te limites a copiar el resultado.
Volver al modo de aplicación forzosa
Es posible solucionar problemas en el modo permisivo, pero se debe volver a la aplicación forzosa lo antes posible y tratar de permanecer allí.
Errores comunes
Estas son algunas soluciones para los errores comunes que se producen al escribir políticas específicas del dispositivo.
Uso excesivo de la negación
La siguiente regla de ejemplo es como trabar la puerta principal, pero dejar la ventanas abiertas:
allow { domain -untrusted_app } scary_debug_device:chr_file rw_file_perms
La intención es clara: todas las personas, excepto las apps de terceros, pueden tener acceso a la depuración. dispositivo.
La regla tiene varios errores. La exclusión de untrusted_app
es sencillo solucionar porque todas las apps pueden, de manera opcional, ejecutar servicios en la
isolated_app
. Del mismo modo, si se agregan dominios nuevos para apps de terceros
al AOSP, también tendrán acceso a scary_debug_device
.
La regla es demasiado permisiva. La mayoría de los dominios no se beneficiarán por tener
acceso a esta herramienta de depuración. La regla se debería haber escrito de modo que solo permita
los dominios que requieren acceso.
Depuración de atributos en producción
Las funciones de depuración no deben estar presentes en las compilaciones de producción ni deben .
La alternativa más sencilla es permitir la función de depuración solo cuando SELinux esté
inhabilitado en compilaciones eng/userdebug, como adb root
y
adb shell setenforce 0
Otra alternativa segura es incluir permisos de depuración en un userdebug_or_eng.
Explosión de tamaño de políticas
Caracterización de las políticas de SEAndroid de forma habitual describe una tendencia preocupante en cuanto al crecimiento de las personalizaciones de las políticas de dispositivos. La política específica del dispositivo debe representar entre el 5% y el 10% de la política general que se ejecuta en un dispositivo. Es muy probable que las personalizaciones que estén en más del 20%contengan más de los dominios con privilegios y la política inactiva.
Política innecesariamente grande:
- Realiza doble carga en la memoria, ya que la política se encuentra en el ramdisk y también se cargan en la memoria del kernel.
- Desperdicia espacio en el disco porque requiere una imagen de arranque más grande.
- Afecta los tiempos de búsqueda de la política de tiempo de ejecución.
En el siguiente ejemplo, se muestran dos dispositivos en los que se encuentra comprendían el 50% y el 40% de la política en el dispositivo. Una reescritura de la política obtuvo mejoras de seguridad sustanciales sin pérdida de funcionalidad, ya que que se muestra a continuación. (Se incluyen los dispositivos AOSP Shamu y Flounder a modo de comparación).
En ambos casos, la política se redujo drásticamente en tamaño y cantidad
de permisos. La disminución en el tamaño de las políticas se debe casi en su totalidad a quitar
permisos innecesarios, muchos de los cuales probablemente fueron reglas generadas por
audit2allow
que se agregaron indiscriminadamente a la política. Muerto
también eran un problema para ambos dispositivos.
Otorga la función dac_override
Una negación del tipo dac_override
significa que el proceso ofensivo se
intentar acceder a un archivo con permisos de usuario/grupo/mundo de Unix incorrectos
La solución adecuada casi nunca es otorgar el permiso dac_override
.
En cambio
cambiar los permisos de Unix en el archivo o proceso Algunos dominios como
init
, vold
y installd
realmente necesitan
anular los permisos del archivo Unix para acceder a archivos de otros procesos
Consulta el blog de Dan Walsh
para obtener una explicación más detallada.