App Sandbox en el desarrollo móvil — qué es, mecanismo y principio de funcionamiento

¿Qué es App Sandbox?

App Sandbox es un mecanismo de seguridad arquitectónico que aísla cada aplicación en su propio entorno de ejecución con acceso limitado a los recursos del sistema. El término proviene del concepto de arenero infantil — un espacio seguro donde un niño puede jugar sin acceder a objetos peligrosos. De manera similar, una aplicación se ejecuta en un entorno restringido sin acceso a los datos de otras aplicaciones ni a componentes críticos del sistema.

El objetivo principal de Sandbox es la implementación del principio de mínimos privilegios: cada aplicación recibe solo los derechos necesarios para realizar sus funciones declaradas. Incluso si un atacante encuentra una vulnerabilidad en una aplicación, la sandbox impide el acceso a los datos de otras aplicaciones, fotos, contactos o archivos del sistema. El daño se limita a los límites de una sola aplicación.

Los sistemas operativos móviles implementaron sandboxes antes que los de escritorio. iOS utiliza Sandbox desde el lanzamiento del primer SDK (2008), Android desde la versión 1.0 (2008), con refuerzo en Android 4.3 (2013) mediante SELinux. Los sistemas de escritorio se están poniendo al día: macOS introdujo Sandbox en 2012, Windows introdujo aplicaciones aisladas UWP en Windows 8.

¿Cómo funciona el aislamiento en la sandbox?

El aislamiento en la sandbox se logra mediante una combinación de varios mecanismos en diferentes niveles del sistema operativo. A nivel del sistema de archivos, cada aplicación recibe su propio directorio protegido al que solo ella tiene acceso completo. A nivel de procesos, se utiliza un identificador único de usuario (UID) para cada aplicación. A nivel del kernel, se aplica control de acceso obligatorio (MAC) mediante SELinux o mecanismos similares.

Aislamiento del sistema de archivos

Cada aplicación recibe su propio directorio raíz en el sistema de archivos del dispositivo. En iOS, este es el directorio /var/mobile/Containers/Data/Application/{UUID}, en Android — /data/data/{package_name}. La aplicación puede leer y escribir archivos solo dentro de este directorio. El acceso a cualquier archivo fuera de este directorio se bloquea a nivel del kernel del sistema operativo.

El sistema también proporciona directorios compartidos especiales con acceso limitado. En iOS, estos son el directorio Documents para datos de usuario, Library para configuraciones y Caches para archivos temporales. En Android — almacenamiento interno (getFilesDir) y almacenamiento externo (getExternalFilesDir), cuyo acceso no requiere permisos adicionales.

Aislamiento de procesos y UID

En Android, cada aplicación se ejecuta como un proceso Linux separado con un UID único (User ID). El UID se asigna al instalar la aplicación y permanece sin cambios durante todo su ciclo de vida. Los procesos con diferentes UID están aislados entre sí a nivel del kernel — no pueden acceder a la memoria ni a los archivos del otro. Un mecanismo similar funciona en iOS a través del kernel XNU y su sistema de protección.

Una capa adicional de protección en Android la proporciona SELinux (Security-Enhanced Linux) en modo enforcing desde Android 4.3. SELinux implementa control de acceso obligatorio (MAC): cada acción del proceso se verifica contra la política de seguridad independientemente de los permisos del propietario del archivo. Incluso si una aplicación se ejecuta con UID root, SELinux puede bloquear el acceso a ciertos recursos.

Sandbox en iOS

La sandbox de iOS se considera una de las más estrictas entre los sistemas operativos móviles. Cada aplicación está aislada a nivel de contenedor — un área protegida del sistema de archivos a la que no pueden acceder otras aplicaciones. iOS utiliza una combinación de control de acceso obligatorio a través de Sandbox Kernel Extension (Sandbox.kext) y el mecanismo de entitlements para otorgar privilegios extendidos.

Estructura del contenedor iOS

El contenedor de una aplicación iOS consta de varios directorios con diferentes niveles de acceso. Documents — para datos de usuario que se conservan durante la copia de seguridad mediante iCloud e iTunes. Library — para archivos de configuración y caché. tmp — para datos temporales que el sistema puede eliminar en cualquier momento. AppName.app — el bundle de la aplicación en sí, que es de solo lectura.

El acceso a los datos de otras aplicaciones está estrictamente prohibido. iOS no proporciona una API para leer archivos del contenedor de otra aplicación. La única forma de compartir datos es a través de mecanismos del sistema: UIActivityViewController para compartir, UIPasteboard para el portapapeles, App Groups para aplicaciones del mismo desarrollador. Cada uno de estos mecanismos opera bajo el control del sistema operativo.

Entitlements y App Sandbox en iOS

Las capacidades extendidas más allá de la sandbox estándar se proporcionan a través de Entitlements — firmas digitales que se agregan a la firma de código de la aplicación. Por ejemplo, el entitlement com.apple.security.application-groups permite que las aplicaciones de un mismo grupo tengan un contenedor compartido. Notificaciones push, iCloud, Apple Pay — todas estas funciones requieren entitlements correspondientes.

Es importante señalar que los entitlements en iOS no son lo mismo que los permisos. Los permisos se solicitan al usuario en tiempo de ejecución (por ejemplo, acceso a la cámara), mientras que los entitlements los verifica el sistema en el momento de la instalación y no pueden ser modificados por el usuario. Los entitlements los define el desarrollador y los firma Apple durante el proceso de revisión de la aplicación.

Sandbox en Android

Android utiliza un modelo de sandbox de múltiples capas basado en el kernel de Linux. Cada aplicación se ejecuta como un usuario Linux separado con un UID único, lo que proporciona un aislamiento básico a nivel de procesos y archivos. Las capas adicionales incluyen SELinux para control de acceso obligatorio y Permisos para controlar el acceso a las API del sistema.

SELinux y aislamiento de UID

SELinux en Android se ejecuta en modo enforcing, lo que significa la aplicación forzosa de las políticas de seguridad. A cada aplicación se le asigna un contexto de seguridad y todas las llamadas al sistema se verifican contra la política. SELinux en Android contiene más de 1500 reglas que cubren el sistema de archivos, la comunicación entre procesos, los sockets y las llamadas al sistema.

El aislamiento de UID evita que una aplicación acceda directamente a los archivos de otra aplicación. Por ejemplo, la aplicación A con UID 10001 no puede leer los archivos de la aplicación B con UID 10002, incluso si ambas se ejecutan bajo la misma cuenta de usuario del teléfono. Este es el principio básico de seguridad multiusuario de Linux, adaptado para dispositivos móviles.

// Acceso al directorio propio de la aplicación en Android
File appDir = context.getFilesDir();
File cacheDir = context.getCacheDir();
File externalDir = context.getExternalFilesDir(null);

// Intentar acceder al directorio de otra aplicación provocará SecurityException
// File otherApp = new File("/data/data/com.other.app/shared_prefs/");

// Uso de FileProvider para compartir archivos de forma segura
Uri contentUri = FileProvider.getUriForFile(
    context, "com.example.fileprovider", file
);

Android proporciona mecanismos adicionales para el intercambio seguro de datos entre aplicaciones. ContentProvider — un componente de Android que permite a una aplicación proporcionar acceso a sus datos a otras aplicaciones a través de un URI estrictamente definido. FileProvider — una forma segura de compartir archivos sin revelar las rutas del sistema de archivos.

Limitaciones y seguridad de la sandbox

A pesar de que App Sandbox es un potente mecanismo de seguridad, tiene limitaciones fundamentales. La sandbox protege contra el acceso horizontal (de aplicación a aplicación), pero no contra el acceso vertical (malware a nivel del kernel o acceso físico al dispositivo). Con jailbreak o acceso root, la sandbox puede ser eludida, ya que el atacante obtiene privilegios de superusuario.

La segunda limitación son los permisos maliciosos. Si un usuario concede a una aplicación acceso a contactos y micrófono, la sandbox no puede evitar la recopilación de estos datos, ya que la aplicación utiliza API legítimas del sistema. La protección en este caso pasa al nivel de concienciación del usuario y los procesos de revisión de App Store y Google Play.

La tercera limitación es la interacción entre sandboxes. Algunos servicios del sistema (NotificationListenerService, AccessibilityService) tienen acceso extendido a los datos de otras aplicaciones. Un atacante podría utilizar estos servicios para eludir la sandbox si obtiene los permisos correspondientes. Google y Apple actualizan constantemente las políticas para dichos servicios.

A pesar de las limitaciones, la sandbox es un componente crítico de seguridad de los sistemas operativos móviles. Según Android Security Report (2024), el aislamiento de sandbox previene más del 99% de los intentos de acceso entre aplicaciones. En combinación con Code Signing, App Review y permisos en tiempo de ejecución, Sandbox forma una protección multicapa del dispositivo móvil moderno.