Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Zona de pruebas de la aplicación

La plataforma Android aprovecha la protección basada en el usuario 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, 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 hacer cumplir la seguridad; a este respecto, el código nativo está tan aislado como el código interpretado.

Protecciones

Por lo general, para salir de la zona de pruebas de la aplicación en un dispositivo configurado correctamente, se debe comprometer la seguridad del kernel de Linux. Sin embargo, al igual que con otras funciones de seguridad, las protecciones individuales que imponen 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 implementaciones se han introducido con el tiempo y han fortalecido significativamente el entorno de pruebas 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 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 definir los valores predeterminados más seguros para los datos de la aplicación: Para aplicaciones con targetSdkVersion >= 24 , permisos DAC predeterminados en dir la casa de una aplicación cambiado de 751 a 700. Esto proporcionó defecto más seguro para los datos de aplicaciones privadas (aunque las aplicaciones pueden anular estos valores predeterminados) .
  • En Android 8.0, se establecieron todas las aplicaciones para funcionar con un seccomp-bpf filtro que limita las llamadas al sistema que las aplicaciones se les permitió el uso, fortaleciendo así la aplicación / kernel límite.
  • En Android 9 todas las aplicaciones no privilegiados con targetSdkVersion >= 28 deben funcionar en entornos limitados de SELinux individuales, proporcionando MAC en función de cada aplicación. Esta protección mejora la separación de las aplicaciones, evita que se anulen 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 plena Acceso prima a sus trayectorias específicas de los paquetes devuelto por cualquiera de los métodos aplicables, tales 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 dado lugar a 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 superior, para compartir archivos de esta manera no está permitido expresamente para aplicaciones con targetSdkVersion>=28 .

En lugar de hacer que los datos de las aplicaciones sean accesibles para todo el mundo, use las siguientes pautas cuando comparta archivos:

  • Si sus necesidades de aplicaciones para compartir archivos con otra aplicación, utilice un proveedor de contenido . Los proveedores de contenido comparten datos con la granularidad adecuada y sin las desventajas de muchos accesible mundo permisos de UNIX (para más detalles, se refieren a conceptos básicos proveedor de contenidos ).
  • Si su aplicación tiene archivos que realmente debería ser accesible para el mundo (como fotografías), deben ser los medios de comunicación específicos (fotos, vídeos y archivos de audio solamente) y se almacenan utilizando la MediaStore clase. (Para más detalles sobre cómo agregar un elemento multimedia, consulte los archivos de medios de acceso de almacenamiento compartido .)

Los controles de permisos de ejecución de almacenamiento de acceso a las colecciones de tipo fuerte a través MediaStore. Para acceder a los archivos de tipos débiles, tales como archivos PDF y la MediaStore.Downloads clase, las aplicaciones deben utilizar las intenciones como el ACTION_OPEN_DOCUMENT intención.

Para habilitar el comportamiento androide 10, utilice el requestLegacyExternalStorage atributo de manifiesto, y siga los permisos de la aplicación mejores prácticas .

  • El valor predeterminado bandera manifiesto es true para aplicaciones dirigidas a Android 9 (e inferior).
  • El valor por defecto es falsa para aplicaciones dirigidas a Android 10. Para optar temporalmente fuera de la vista de almacenamiento filtrada en aplicaciones dirigidas a Android 10, establezca el valor de la bandera de manifiesto a 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.