Caja de arena 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 las aplicaciones maliciosas. Para hacer esto, Android asigna una ID de usuario (UID) única a cada aplicación de Android y la ejecuta en su propio proceso.

Android usa el UID para configurar un Sandbox de aplicaciones a nivel de kernel. El kernel impone la seguridad entre las aplicaciones y el sistema a nivel de proceso a través de las funciones 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 podrá hacerlo porque no tiene los privilegios de usuario predeterminados adecuados. El sandbox es simple, auditable y se basa en la separación de usuarios de procesos y permisos de archivos 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 de Application Sandbox. 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 se requieren para hacer cumplir la seguridad; a este respecto, el código nativo está tan aislado como el código interpretado.

Protecciones

En general, para salir del Sandbox de la aplicación 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 hacen cumplir el espacio aislado de la aplicación no son invulnerables, por lo que es importante una defensa en profundidad para evitar que las 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. Estos cumplimientos se han introducido con el tiempo y han fortalecido significativamente el sandbox original de control de acceso discrecional (DAC) 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 ejecutaban dentro del mismo contexto de SELinux, por lo que el aislamiento entre aplicaciones se aplicaba principalmente mediante UID DAC.
• En Android 6.0, la zona de pruebas de SELinux se amplió para aislar aplicaciones en el 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ó un valor predeterminado más seguro para los datos privados de la aplicación (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 sandboxes de SELinux individuales, proporcionando MAC por 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 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 el acceso sin procesar completo a las rutas específicas de sus paquetes, tal como lo devuelve cualquier método aplicable, como Context.getExternalFilesDir() .

Pautas para compartir archivos

Establecer los datos de la aplicación 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 solo a los destinatarios previstos. Esta práctica ha dado lugar a filtraciones de divulgación de información y vulnerabilidades confusas de los agentes, y es un objetivo favorito para el malware que se dirige a aplicaciones con datos confidenciales (como clientes de correo electrónico). En Android 9 y versiones posteriores, compartir archivos de esta manera está explícitamente prohibido para aplicaciones con targetSdkVersion>=28 .

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

• Si su aplicación necesita compartir archivos con otra aplicación, use 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 detalles, consulte Conceptos básicos de proveedores de contenido ).
• Si su aplicación tiene archivos que realmente deberían ser accesibles para 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 mal escritos, 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 atributo de manifiesto requestLegacyExternalStorage y siga las mejores prácticas de permisos de aplicaciones .

• El valor predeterminado del indicador de manifiesto es true para las aplicaciones destinadas a Android 9 (y versiones anteriores).
• El valor predeterminado es falso para las aplicaciones destinadas a Android 10. Para cancelar temporalmente la vista de almacenamiento filtrado en las aplicaciones destinadas a Android 10, establezca el valor del indicador de manifiesto en true .
• Con permisos restringidos, el instalador incluye en la lista blanca las aplicaciones permitidas para el almacenamiento sin espacio aislado. Las aplicaciones que no están en la lista blanca están en un espacio aislado.