Google is committed to advancing racial equity for Black communities. See how.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Zona de pruebas de la aplicación

La plataforma Android aprovecha la protección basada en usuarios de Linux para identificar y aislar los recursos de la aplicación. Esto aísla las aplicaciones entre sí y protege las aplicaciones y el sistema de aplicaciones maliciosas. Para hacer esto, Android asigna un ID de usuario único (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 las instalaciones estándar de Linux, como los 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 puede hacerlo porque no tiene los privilegios de usuario predeterminados adecuados. La caja de arena es simple, auditable y se basa en la separación de procesos y permisos de archivos de usuarios al estilo UNIX de décadas de antigüedad.

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 del entorno de pruebas de la aplicación. En algunas plataformas, los desarrolladores están limitados a un marco de desarrollo específico, un conjunto de API o un lenguaje. En Android, no hay restricciones sobre cómo se puede escribir una aplicación que sean necesarias para hacer cumplir la seguridad; a este respecto, el código nativo está tan aislado 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 funciones de seguridad, las protecciones individuales que imponen el entorno limitado de la aplicación no son invulnerables, por lo que la defensa en profundidad es importante para evitar que las vulnerabilidades individuales provoquen el compromiso del 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 implementaciones se han introducido con el tiempo y han fortalecido significativamente el entorno de pruebas de control de acceso discrecional (DAC) original basado en UID. 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 de SELinux, por lo que UID DAC aplicó principalmente el aislamiento entre aplicaciones.
  • En Android 6.0, la zona de pruebas de SELinux se amplió para aislar las aplicaciones a través del límite por usuario físico. Además, Android también estableció valores predeterminados más seguros para los datos de la aplicación: para las aplicaciones con targetSdkVersion >= 24 , los permisos DAC predeterminados en el directorio de inicio de una aplicación cambiaron de 751 a 700. Esto proporcionó valores predeterminados más seguros 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 de la aplicación / kernel.
  • En Android 9, todas las aplicaciones sin privilegios con targetSdkVersion >= 28 deben ejecutarse en cajas de arena SELinux individuales, proporcionando MAC por aplicación. Esta protección mejora la separación de aplicaciones, evita anular los valores predeterminados seguros y (lo que es más importante) evita que las aplicaciones hagan que su mundo de datos sea accesible.
  • En Android 10, las aplicaciones tienen una vista en bruto limitada del sistema de archivos, sin acceso directo a rutas como / sdcard / DCIM. Sin embargo, las aplicaciones conservan el acceso sin formato completo a sus rutas específicas del paquete, como lo devuelve cualquier método aplicable, como Context.getExternalFilesDir () .

Directrices para compartir archivos

Establecer los datos de la aplicación como accesibles para todo el mundo es una mala práctica de seguridad. El acceso se otorga a todos y no es posible limitar el acceso solo a los destinatarios previstos. Esta práctica ha provocado filtraciones de información y vulnerabilidades adjuntas confusas, y es un objetivo favorito del malware que se dirige a aplicaciones con datos confidenciales (como clientes de correo electrónico). En Android 9 y targetSdkVersion>=28 posteriores, compartir archivos de esta manera está explícitamente prohibido para aplicaciones con targetSdkVersion>=28 .

En lugar de hacer que los datos de las aplicaciones sean accesibles para 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 que realmente deberían ser accesibles para el mundo (como fotos), deben ser específicos del medio (solo fotos, videos y archivos de audio) y almacenados usando la clase MediaStore . (Para obtener más información, consulte la guía de vista previa sobre DAC ).

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

Para habilitar el comportamiento de Android 10, use el requestLegacyExternalStorage manifiesto requestLegacyExternalStorage y siga las mejores prácticas de permisos de la aplicación .

  • El valor predeterminado de la marca de manifiesto es true para las aplicaciones destinadas a Android 9 (y versiones anteriores).
  • El valor predeterminado es falso para las aplicaciones que tienen como objetivo Android 10. Para excluirse temporalmente de la vista de almacenamiento filtrada en aplicaciones que tienen como objetivo Android 10, establezca el valor de la marca de manifiesto en true .
  • Con permisos restringidos, el instalador incluye en la lista blanca las aplicaciones permitidas para el almacenamiento no aislado. Las aplicaciones que no están incluidas en la lista blanca se encuentran en una zona de pruebas.