Zona de pruebas de aplicaciones

La plataforma de Android aprovecha la protección basada en usuarios de Linux para identificar y aislar los recursos de la app. Esto aísla las apps entre sí y protege a las apps y al sistema de las apps maliciosas. Para ello, Android asigna un un ID de usuario único (UID) para cada app para Android y la ejecuta el proceso de administración de recursos.

Android usa el UID para configurar una zona de pruebas de aplicaciones a nivel del kernel. El kernel aplica la seguridad entre las apps y el sistema a nivel del proceso a través de las funciones estándar de Linux, como los IDs de usuario y de grupo que se asignan a las apps. De forma predeterminada, las apps no pueden interactuar entre sí y tienen limitaciones acceso al SO. Si la app A intenta hacer algo malicioso, como leer los datos de la app B o marcar el teléfono sin permiso, no puede hacerlo porque no tiene los privilegios de usuario predeterminados adecuados. La zona de pruebas es simple, auditable y se basa en la separación de usuarios de procesos y permisos de archivos al estilo de UNIX, que tiene décadas de antigüedad.

Debido a que la zona de pruebas de aplicaciones está en el kernel, este modelo de seguridad se extiende al código nativo y al SO. Todo el software que está por encima de kernel, como bibliotecas del SO, framework de apps, entorno de ejecución de apps y y todas las apps se ejecutan en la zona de pruebas de aplicaciones. En algunas plataformas, los desarrolladores se ven limitados a un framework de desarrollo, un conjunto de APIs o un lenguaje específicos. En Android, no hay restricciones en cuanto a cómo se puede escritos que son necesarios para aplicar la seguridad; en este sentido, el código nativo es como zona de pruebas como código interpretado.

Protecciones

En general, para salir de la zona de pruebas de aplicaciones en una zona de pruebas se debe poner en riesgo la seguridad del kernel de Linux. Sin embargo, es similar a otras funciones de seguridad, las protecciones individuales que aplican la app de espacio aislado no son invulnerables, por lo que la defensa en profundidad es importante para evitar vulnerabilidades individuales para que no comprometan el SO ni otras apps.

Android se basa en varias protecciones para aplicar la zona de pruebas de la app. Estas aplicaciones forzosas se introdujeron con el tiempo y fortalecieron significativamente la zona de pruebas de control de acceso discrecional (DAC) basada en UID original. Las versiones anteriores de Android incluían lo siguiente: protecciones:

  • En Android 5.0, SELinux proporcionaba una separación de control de acceso obligatorio (MAC) entre el sistema y las apps. Sin embargo, todas las apps de terceros se ejecutaban en el mismo contexto de SELinux, por lo que el aislamiento entre apps se aplicaba principalmente a través de DAC de UID.
  • En Android 6.0, la zona de pruebas de SELinux se extendió para aislar apps en la límite por usuario físico. Android también establece valores predeterminados más seguros para datos de la app: Para apps con targetSdkVersion >= 24, predeterminado Los permisos del DAC del directorio principal de una app cambiaron de 751 a 700. Esto proporcionó configuración predeterminada más segura para los datos privados de las apps (aunque las apps pueden anular estas valores predeterminados).
  • En Android 8.0, todas las apps se configuraron para ejecutarse con un filtro seccomp-bpf que limitaba las llamadas al sistema que podían usar, lo que fortalecía el límite entre la app y el kernel.
  • En Android 9, todas las apps sin privilegios con targetSdkVersion >= 28 deben ejecutarse en zonas de pruebas de SELinux individuales, lo que proporciona MAC por app. Esta protección mejora la separación de la app y evita que se anulen predeterminadas y, lo más importante, evita que las apps hagan que su mundo de datos accesible.
  • En Android 10, las apps tienen una vista sin formato limitada del sistema de archivos, sin acceso directo a rutas como /sdcard/DCIM. Sin embargo, las apps mantienen el acceso completo sin procesar a sus rutas específicas de paquetes, como lo devuelve cualquier métodos aplicables, como Context.getExternalFilesDir().

Lineamientos para compartir archivos

Configurar los datos de la app como accesibles a todo el mundo es una mala práctica de seguridad. Se otorga acceso a todos y no es posible limitar el acceso solo a los destinatarios previstos. Esta práctica ha provocado filtraciones de divulgación de información y vulnerabilidades de suplentes confusas, y es un objetivo favorito del software malicioso que se orienta a apps con datos sensibles (como clientes de correo electrónico). En Android 9 y versiones posteriores, compartir esta forma no está permitida explícitamente para apps que tienen targetSdkVersion>=28

En lugar de permitir que todos puedan acceder a los datos de la app, usa los siguientes lineamientos cuando compartas archivos:

El permiso de tiempo de ejecución de Storage controla el acceso a colecciones de tipo fuerte mediante MediaStore. Para acceder a archivos con tipado débil, como los archivos PDF y la clase MediaStore.Downloads, las apps deben usar intents como el intent ACTION_OPEN_DOCUMENT.

Para habilitar el comportamiento de Android 10, usa el atributo del manifiesto requestLegacyExternalStorage y sigue las prácticas recomendadas de permisos de la app.

  • El valor predeterminado de la marca del manifiesto es true para las apps orientadas a Android 9 (y versiones anteriores).
  • El valor predeterminado es falso para las apps orientadas a Android 10. Para inhabilitar temporalmente la vista de almacenamiento filtrada en las apps orientadas a Android 10, establece el valor de la marca de manifiesto en true.
  • Con permisos restringidos, el instalador incluye en la lista de entidades permitidas las apps que se permiten para el almacenamiento sin zona de pruebas. Las aplicaciones que no están incluidas en la lista de entidades permitidas son las siguientes: en una zona de pruebas.