⏱️ Lectura: 16 min
Un usuario de GrapheneOS en un Pixel 8 llevaba un año con el sistema cuando notó algo raro: Osmand, su app de mapas, corría notablemente más lento que en cualquier otro Android. No era un bug de la app: era una de las capas del sandboxing de GrapheneOS revisando cada asignación de memoria antes de entregarla.
📑 En este artículo
- TL;DR
- ¿Qué es el sandboxing de GrapheneOS?
- Por qué importa
- Cómo funciona la arquitectura de permisos de GrapheneOS
- Ejemplos prácticos: cuando el sandboxing de GrapheneOS se nota
- Casos de uso reales
- Errores comunes y buenas prácticas
- Comparativa con alternativas
- Profundizando: qué hace hardened_malloc por dentro
- Preguntas frecuentes
- ¿El permiso de Internet de GrapheneOS bloquea wifi y datos móviles por igual?
- ¿Cómo sé si el hardened memory allocator está haciendo más lenta una app puntual?
- ¿Sandboxed Google Play necesita privilegios de sistema en GrapheneOS?
- ¿Puedo desactivar hardened_malloc para una sola app en GrapheneOS?
- ¿Storage Scopes reemplaza los permisos de almacenamiento de Android?
- ¿GrapheneOS funciona en cualquier teléfono?
- Referencias
Esa anécdota puntual es solo la punta del ovillo. GrapheneOS envuelve cada app en capas de aislamiento (memoria, almacenamiento, red y Google Play) y cada capa cobra un costo en rendimiento. Entender ese modelo, no el caso de una app lenta, es lo que permite decidir cuándo vale la pena pagarlo.
TL;DR
- El sandboxing de GrapheneOS suma hardened malloc, Storage Scopes y permiso de Internet, con costo en rendimiento.
- Osmand corre más lento en GrapheneOS porque hardened malloc revisa cada asignación de memoria del mapa.
- Storage Scopes limita qué carpetas ve cada app sin otorgar el permiso completo de almacenamiento.
- Sandboxed Google Play corre sin privilegios de sistema y traduce llamadas vía una capa de compatibilidad.
- Desactivar la protección de memoria por app recupera velocidad a cambio de menos hardening.
¿Qué es el sandboxing de GrapheneOS?
El sandboxing de GrapheneOS es el conjunto de mecanismos de aislamiento que este sistema operativo basado en Android añade sobre el sandbox estándar de cada app: un asignador de memoria endurecido, permisos granulares de almacenamiento e Internet, y una versión sin privilegios de Google Play Services.
Su objetivo es reducir la superficie de ataque de cada aplicación instalada, sin depender de que el desarrollador haya escrito código perfecto. Cada capa funciona de forma independiente: podés desactivar una sin tocar las demás, y eso es clave para el resto de este artículo.
Por qué importa
La mayoría de los sistemas operativos móviles confían en que las apps se comporten bien. Android estándar ya sandboxea cada app con su propio UID de Linux, pero GrapheneOS agrega capas adicionales pensadas para el peor escenario: una app maliciosa, comprometida o simplemente con un bug explotable.
Eso importa porque el modelo de amenazas de un teléfono cambió. Ya no alcanza con revisar permisos al instalar una app: un exploit de día cero en una librería de imágenes o de mapas puede ejecutar código arbitrario sin que el usuario haga nada. Las protecciones de memoria de GrapheneOS, como hardened_malloc, existen para que ese exploit falle antes de lograr control sobre el proceso.
El costo de eso es real y es el tema central de este artículo: cada verificación extra consume ciclos de CPU. En apps con patrones de uso de memoria intensivos, como un renderizador de mapas que carga y descarta miles de tiles por minuto, ese costo se nota. La decisión de fondo no es seguridad sí o no, sino cuánta seguridad necesita cada app puntual.
Cómo funciona la arquitectura de permisos de GrapheneOS
El aislamiento no es una sola función: son cuatro mecanismos separados que cualquier usuario puede activar o desactivar por app, desde la pantalla de información de cada aplicación.
Storage Scopes: menos que el permiso de almacenamiento completo
Android normal ofrece dos opciones para el almacenamiento: acceso completo o nada. Storage Scopes agrega un punto intermedio: cuando una app pide acceso a archivos, GrapheneOS puede mostrarle solo una carpeta específica en lugar de toda la memoria del teléfono. La app funciona como si esa carpeta fuera el único almacenamiento que existe.
Esto reduce el daño si una app maliciosa intenta leer fotos, documentos o backups de otras apps: aunque tenga el permiso concedido, solo ve lo que el scope le permite ver.
Permiso de Internet por app: cortar la red sin desinstalar
GrapheneOS agrega un permiso adicional de Internet que no existe como tal en Android estándar. Al desactivarlo para una app, el sistema le corta el acceso a sockets de red a nivel del kernel: la app sigue instalada y funciona con datos locales, pero no puede conectarse a internet ni siquiera si su código lo intenta.
Es útil para apps que no necesitan estar en línea (una calculadora, un editor de fotos local) y que, si están comprometidas, no deberían poder exfiltrar nada.
Sandboxed Google Play: los servicios de Google sin privilegios de sistema
En Android estándar, Google Play Services corre con privilegios elevados: puede acceder a datos y permisos que ninguna otra app tiene. GrapheneOS instala Google Play como una app normal, sandboxeada igual que cualquier otra, y agrega una capa de compatibilidad que traduce las llamadas que las apps hacen esperando encontrar el Play Services privilegiado del sistema.
El resultado es que la mayoría de las apps que dependen de Google Play (notificaciones push, mapas, inicio de sesión) funcionan igual, pero Google Play ya no tiene una posición privilegiada para vigilar el resto del teléfono.
Hardened malloc: la capa que más se nota en rendimiento
La cuarta capa es la que generó la anécdota que abre este artículo. GrapheneOS reemplaza el asignador de memoria estándar de Android por hardened_malloc, un allocator diseñado para detectar corrupciones de memoria (use-after-free, overflows de heap) antes de que un atacante pueda explotarlas.
Por defecto corre en todas las apps del sistema. Pero GrapheneOS permite, por app, sumar una capa extra de protección de memoria todavía más estricta, en Ajustes de la app > Exploit protection. Esa capa extra es exactamente la que un usuario reportó que ralentizaba Osmand en su Pixel 8.
| Capa | Qué controla | Costo en rendimiento | Se ajusta por app |
|---|---|---|---|
| hardened_malloc (modo estricto) | Cada asignación y liberación de memoria | Notable en apps con muchas asignaciones (mapas, juegos) | Sí, en Exploit protection |
| Storage Scopes | Qué carpetas ve una app con permiso de almacenamiento | Mínimo | Sí, se define el scope por app |
| Permiso de Internet | Si el proceso puede abrir sockets a internet | Ninguno si está permitido | Sí, permiso Internet en info de la app |
| Sandboxed Google Play | Privilegios del framework de Google Play | Latencia extra en llamadas traducidas por la capa de compatibilidad | No de forma individual |
flowchart TD
A["App instalada en GrapheneOS"] --> B["Sandbox de Android: proceso con UID propio"]
B --> C["Storage Scopes: ve solo una carpeta, no todo el almacenamiento"]
B --> D["Permiso de Internet: puede bloquear sockets a internet"]
B --> E["Sandboxed Google Play: sin privilegios de sistema"]
B --> F["hardened_malloc: valida cada asignación de memoria"]
Ejemplos prácticos: cuando el sandboxing de GrapheneOS se nota
El caso documentado en el blog WirelessMoves es el ejemplo más claro. Osmand, la app de mapas basada en OpenStreetMap, dibuja el mapa cargando y descartando constantemente datos de tiles a medida que el usuario hace scroll o zoom. Cada uno de esos tiles pasa por una asignación de memoria, y con la protección activada, cada asignación pasa por las verificaciones extra de hardened_malloc.
sequenceDiagram
participant App as Osmand
participant Mem as hardened_malloc
App->>Mem: pide memoria para un tile del mapa
Mem->>Mem: agrega guard pages y verifica el tamaño
Mem-->>App: entrega el bloque de memoria validado
Note over App,Mem: el ciclo se repite miles de veces al hacer scrollEl usuario que reportó el caso resolvió el problema desde Ajustes: mantuvo presionado el ícono de Osmand, entró a Info de la app, bajó hasta Exploit protection y desactivó específicamente el hardened memory allocator, dejando las demás protecciones activas. Después de reiniciar Osmand, la app volvió a sentirse tan rápida como en cualquier otro Android.
Un comentario en el mismo blog agrega otro caso: Waze consumiendo batería de forma notable en un Pixel 10a con GrapheneOS mientras corría en Android Auto, con el teléfono calentándose. Es el mismo patrón: una app con uso intensivo de CPU y memoria que se topa con capas de verificación adicionales, esta vez con impacto en consumo energético en vez de en fluidez visual.
⚠️ Ojo: desactivar el hardened memory allocator para una app específica reduce su protección contra explotación de bugs de memoria en esa app puntual. No afecta al resto del sistema, pero sí a esa app.
Casos de uso reales
No todos los perfiles de usuario necesitan la misma configuración. Un periodista o activista que maneja información sensible en países con vigilancia estatal se beneficia de dejar todas las protecciones activas, incluso si eso significa que el navegador o el cliente de mensajería corren un poco más lento: el costo en velocidad es bajo comparado con el riesgo de un exploit exitoso.
Un usuario que solo quiere privacidad razonable frente al tracking publicitario, pero usa apps con mapas, edición de fotos o juegos con motores gráficos pesados, gana más ajustando caso por caso: deja Storage Scopes y el permiso de Internet activos siempre (tienen costo casi nulo), y reserva la desactivación del hardened memory allocator para las dos o tres apps que de verdad lo necesitan.
Para desarrolladores que prueban sus propias apps en GrapheneOS antes de publicarlas, el aislamiento sirve como banco de pruebas: si una app se rompe con Storage Scopes activado, probablemente esté asumiendo acceso total al almacenamiento en lugar de pedir archivos puntuales, algo que Android también empezó a restringir con Scoped Storage desde Android 11.
Errores comunes y buenas prácticas
- Desactivar todas las protecciones de golpe: apagar el hardened memory allocator para todas las apps en lugar de solo la app lenta anula gran parte del valor de instalar GrapheneOS en primer lugar.
- Confundir el permiso de Internet con un firewall completo: bloquea sockets salientes de la app, pero no reemplaza un firewall a nivel de sistema ni filtra por dominio o dirección IP.
- Asumir que Sandboxed Google Play es igual a no tener Google Play: sigue siendo el mismo código de Google corriendo en el teléfono, solo que sin privilegios de sistema. Si te preocupa el tracking de Google en sí, la alternativa es no instalar Play en absoluto.
- No revisar qué scope le diste a cada app: con el tiempo se acumulan apps con acceso a carpetas que ya no necesitan; conviene revisar Storage Scopes periódicamente igual que revisarías permisos de cámara o micrófono.
- Diagnosticar mal una app lenta: antes de asumir que es un bug de la app, probá desactivar puntualmente el hardened memory allocator para esa app y compará. Si el problema desaparece, ya sabés la causa.
Comparativa con alternativas
GrapheneOS no es la única opción para quien busca más control que un Android de fábrica. La diferencia está en cuánta profundidad de aislamiento agrega cada proyecto y qué tan lejos llega con Google Play.
| Sistema | Sandboxing de apps | Google Play | Cuándo conviene |
|---|---|---|---|
| Android de fábrica (Pixel, Samsung) | Sandbox estándar de AOSP, sin capas extra | Con privilegios de sistema | Priorizás compatibilidad total sobre hardening adicional |
| GrapheneOS | hardened_malloc, Storage Scopes, permiso de Internet, Play sandboxeado | Opcional, corre como app normal | Priorizás resistencia a exploits y control granular por app |
| LineageOS | Sandbox estándar de AOSP más controles de privacidad propios de LineageOS | Vía microG o Play sin sandboxear | Buscás libertad de ROM sin migrar el hardening completo de GrapheneOS |
| CalyxOS | Toma como base parte del trabajo de hardened_malloc de GrapheneOS | MicroG por defecto, Play opcional | Querés privacidad similar con una configuración inicial más guiada |
La disyuntiva real no es si usar GrapheneOS o no, sino cuánto aislamiento granular necesitás controlar vos mismo. LineageOS y CalyxOS toman decisiones más automáticas y menos configurables; GrapheneOS te da el dial de cada capa, con la contrapartida de que también sos vos quien tiene que ajustarlo cuando una app se pone lenta.
Profundizando: qué hace hardened_malloc por dentro
El allocator de memoria estándar de la mayoría de los sistemas (basado en variantes de dlmalloc o jemalloc) prioriza velocidad: reutiliza bloques de memoria liberados lo antes posible y no verifica mucho más allá de que el puntero exista. Eso deja abierta una familia entera de bugs explotables: use-after-free, double-free y overflows de heap que escriben más allá del bloque asignado.
hardened_malloc, el proyecto que GrapheneOS mantiene, ataca esos bugs con varias técnicas combinadas: separa las asignaciones por tamaño en regiones distintas para evitar que un overflow pequeño corrompa metadata de otra asignación, agrega guard pages alrededor de asignaciones grandes que hacen que un desborde provoque un crash inmediato en lugar de una corrupción silenciosa, y pone en cuarentena la memoria liberada durante un tiempo antes de reutilizarla, para que un use-after-free tenga más chances de fallar de forma visible en vez de ejecutar código atacante.
En los Pixel 8 y modelos posteriores, GrapheneOS además puede apoyarse en Memory Tagging Extension (MTE), una función del hardware ARM que etiqueta cada bloque de memoria con un tag de unos pocos bits y verifica en cada acceso que el puntero use el tag correcto. Es la misma familia de protección que hardened_malloc implementa en software, pero resuelta en silicio, con menos costo en CPU que la versión puramente por software.
flowchart TD
A["App pide memoria"] --> B["hardened_malloc separa por tamaño de asignación"]
B --> C["Agrega guard pages alrededor del bloque"]
C --> D["Si hay MTE en el chip, etiqueta el bloque con un tag de hardware"]
D --> E["Cada acceso verifica el tag antes de leer o escribir"]
E --> F{"¿El tag no coincide?"}
F -->|"Sí"| G["El proceso crashea de forma controlada"]
F -->|"No"| H["El acceso continúa con normalidad"]Esa es la razón técnica de por qué el impacto en rendimiento no es uniforme: un teléfono con MTE paga menos costo por esta protección que uno sin ese hardware, y una app que hace pocas asignaciones grandes (un lector de PDF) lo nota mucho menos que una que hace miles de asignaciones pequeñas por segundo (un renderizador de mapas o un motor de juego).
No hay una forma directa de medir desde afuera cuánto overhead agrega hardened_malloc a una app puntual sin herramientas de profiling nativas de Android; la forma práctica de comprobarlo es la que usó el reportante original: desactivar la protección extra para esa app y comparar la fluidez antes y después.
📖 Resumen en Telegram: Ver resumen
Tu próximo paso: entrá a Ajustes > Apps, elegí la app que sospechás más lenta, abrí Exploit protection y desactivá solo el hardened memory allocator para compararla contra su comportamiento actual.
Preguntas frecuentes
¿El permiso de Internet de GrapheneOS bloquea wifi y datos móviles por igual?
Sí. El permiso de Internet de GrapheneOS corta el acceso a sockets a nivel de sistema, sin importar si la conexión es wifi, datos móviles o VPN. Si la app no tiene el permiso, no puede abrir ninguna conexión saliente por ningún medio.
¿Cómo sé si el hardened memory allocator está haciendo más lenta una app puntual?
Desactivalo temporalmente para esa app en Ajustes de la app > Exploit protection y compará. Si la fluidez mejora de forma notoria, como en el caso de Osmand documentado por WirelessMoves, ya identificaste la causa.
¿Sandboxed Google Play necesita privilegios de sistema en GrapheneOS?
No. A diferencia de Android de fábrica, GrapheneOS instala Google Play Services como una app sandboxeada más, sin acceso privilegiado al resto del sistema, y usa una capa de compatibilidad para responder a las llamadas que las apps esperan de un Play Services con privilegios.
¿Puedo desactivar hardened_malloc para una sola app en GrapheneOS?
Podés desactivar la capa extra de protección de memoria, el hardened memory allocator, por app desde Exploit protection. El nivel base de hardened_malloc sigue activo en todo el sistema; lo que se apaga es el modo más estricto para esa app puntual.
¿Storage Scopes reemplaza los permisos de almacenamiento de Android?
Los complementa. Storage Scopes se activa cuando una app ya tiene permiso de almacenamiento concedido, y restringe ese permiso a una carpeta específica en lugar de dejarlo abierto a todo el dispositivo.
¿GrapheneOS funciona en cualquier teléfono?
No: solo es compatible oficialmente con teléfonos Google Pixel, porque depende de funciones de seguridad del hardware de esa línea, como el verified boot y, en los modelos recientes, Memory Tagging Extension, que otros fabricantes no exponen de la misma forma.
Referencias
- WirelessMoves: el post original que documenta el caso de Osmand corriendo lento en GrapheneOS y cómo desactivar el hardened memory allocator lo soluciona.
- GrapheneOS Features: documentación oficial de Storage Scopes, el permiso de Internet por app y Sandboxed Google Play.
- GrapheneOS/hardened_malloc en GitHub: código fuente y documentación técnica del asignador de memoria endurecido.
- Android Developers: Scoped Storage: documentación oficial de Google sobre las restricciones de almacenamiento que Android introdujo desde la versión 11.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de Kedibone Isaac Makhumisane en Unsplash
¿Te sirvió? ¿Te dio otro error? Contalo abajo: las preguntas se responden y le sirven al siguiente que llegue.
Dejar un comentario
0 Comentarios