Caja de arena de la aplicación

La plataforma Android aprovecha la protección basada en el usuario de Linux para identificar y aislar los recursos de las aplicaciones. Esto aísla las aplicaciones entre sí y las protege y el sistema de aplicaciones maliciosas. Para hacer esto, Android asigna una ID de usuario única (UID) a cada aplicación de Android y la ejecuta en su propio proceso.

Android usa el UID para configurar una zona de pruebas de aplicaciones a nivel de kernel. El kernel refuerza la seguridad entre las aplicaciones y el sistema a nivel de proceso a través de funciones estándar de Linux, como ID de usuario y grupo que se asignan a las aplicaciones. De forma predeterminada, las aplicaciones no pueden interactuar entre sí y tienen acceso limitado al sistema operativo. Si la aplicación A intenta hacer algo malicioso, como leer los datos de la aplicación B o marcar el teléfono sin permiso, no podrá hacerlo porque no tiene los privilegios de usuario predeterminados adecuados. El sandbox es simple, auditable y se basa en la separación de procesos y permisos de archivos de usuarios al estilo UNIX, que existe desde hace décadas.

Debido a que Application Sandbox está en el kernel, este modelo de seguridad se extiende tanto al código nativo como a las aplicaciones del sistema operativo. Todo el software por encima del kernel, como las bibliotecas del sistema operativo, el marco de la aplicación, el tiempo de ejecución de la aplicación y todas las aplicaciones, se ejecutan dentro de Application Sandbox. En algunas plataformas, los desarrolladores están limitados a un marco de desarrollo, un conjunto de API o un lenguaje específicos. En Android, no existen restricciones sobre cómo se puede escribir una aplicación que sean necesarias para reforzar la seguridad; En este sentido, el código nativo está tan protegido como el código interpretado.

Protecciones

Generalmente, para salir del entorno de pruebas de aplicaciones en un dispositivo configurado correctamente, se debe comprometer la seguridad del kernel de Linux. Sin embargo, al igual que otras características de seguridad, las protecciones individuales que aplican la zona de pruebas de la aplicación no son invulnerables, por lo que la defensa en profundidad es importante para evitar que vulnerabilidades individuales comprometan el sistema operativo u otras aplicaciones.

Android se basa en una serie de protecciones para hacer cumplir la zona de pruebas de la aplicación. Estas medidas se han introducido con el tiempo y han fortalecido significativamente el entorno limitado de control de acceso discrecional (DAC) basado en UID original. Las versiones anteriores de Android incluían las siguientes protecciones:

  • En Android 5.0, SELinux proporcionó una separación de control de acceso obligatorio (MAC) entre el sistema y las aplicaciones. Sin embargo, todas las aplicaciones de terceros se ejecutaron dentro del mismo contexto SELinux, por lo que UID DAC impuso principalmente el aislamiento entre aplicaciones.
  • En Android 6.0, el entorno limitado de SELinux se amplió para aislar aplicaciones a través del límite por usuario físico. Además, Android también establece valores predeterminados más seguros para los datos de las aplicaciones: para aplicaciones con targetSdkVersion >= 24 , los permisos DAC predeterminados en el directorio de inicio de una aplicación cambiaron de 751 a 700. Esto proporcionó un valor predeterminado más seguro para los datos de aplicaciones privadas (aunque las aplicaciones pueden anular estos valores predeterminados) .
  • En Android 8.0, todas las aplicaciones estaban configuradas para ejecutarse con un filtro seccomp-bpf que limitaba las llamadas al sistema que las aplicaciones podían usar, fortaleciendo así el límite entre la aplicación y el kernel.
  • En Android 9, todas las aplicaciones sin privilegios con targetSdkVersion >= 28 deben ejecutarse en entornos aislados de SELinux individuales, proporcionando MAC por aplicación. Esta protección mejora la separación de aplicaciones, evita la anulación de valores predeterminados seguros y (lo más importante) evita que las aplicaciones hagan accesible su mundo de datos.
  • En Android 10, las aplicaciones tienen una vista sin formato limitada del sistema de archivos, sin acceso directo a rutas como /sdcard/DCIM. Sin embargo, las aplicaciones conservan acceso completo y sin formato a las rutas específicas de su paquete, según lo devuelto por cualquier método aplicable, como Context.getExternalFilesDir() .

Directrices para compartir archivos

Configurar los datos de las aplicaciones como accesibles en todo el mundo es una mala práctica de seguridad. El acceso se otorga a todos y no es posible limitar el acceso únicamente a los destinatarios previstos. Esta práctica ha dado lugar a filtraciones de divulgación de información y vulnerabilidades secundarias confusas, y es un objetivo favorito para el malware que apunta a aplicaciones con datos confidenciales (como clientes de correo electrónico). En Android 9 y versiones posteriores, compartir archivos de esta manera no está permitido explícitamente para aplicaciones con targetSdkVersion>=28 .

En lugar de hacer que los datos de las aplicaciones sean accesibles en todo el mundo, utilice las siguientes pautas al compartir archivos:

  • Si su aplicación necesita compartir archivos con otra aplicación, utilice un proveedor de contenido . Los proveedores de contenido comparten datos con la granularidad adecuada y sin las muchas desventajas de los permisos UNIX accesibles en todo el mundo (para obtener más detalles, consulte Conceptos básicos del proveedor de contenido ).
  • Si su aplicación tiene archivos a los que realmente debería poder acceder todo el mundo (como fotos), deben ser específicos de los medios (solo fotos, videos y archivos de audio) y almacenarse mediante la clase MediaStore . (Para obtener más detalles sobre cómo agregar un elemento multimedia, consulte Acceder a archivos multimedia desde el almacenamiento compartido ).

El permiso de tiempo de ejecución de almacenamiento controla el acceso a colecciones fuertemente tipadas a través de MediaStore . Para acceder a archivos con tipos débiles, como archivos PDF y la clase MediaStore.Downloads , las aplicaciones deben usar intents como el intent ACTION_OPEN_DOCUMENT .

Para habilitar el comportamiento de Android 10, use el atributo de manifiesto requestLegacyExternalStorage y siga las mejores prácticas de permisos de aplicaciones .

  • El valor predeterminado del indicador de manifiesto es true para aplicaciones orientadas a Android 9 (y versiones anteriores).
  • El valor predeterminado es falso para las aplicaciones orientadas a Android 10. Para excluirse temporalmente de la vista de almacenamiento filtrado en aplicaciones orientadas a Android 10, establezca el valor del indicador de manifiesto en true .
  • Al utilizar permisos restringidos, el instalador incluye en la lista blanca las aplicaciones permitidas para el almacenamiento fuera de la zona de pruebas. Las aplicaciones que no están en la lista blanca están protegidas.