# Trampas semánticas en los nombres de archivo: el diseño de seguridad de macOS desde las relaciones de equivalencia

Introducción

¿Qué es lo «mismo»?

Esta pregunta, que parece sencilla, está llena de trampas en los sistemas informáticos. En abril de 2025, Linus Torvalds envió un correo electrónico con un tono contundente a la lista de correo del kernel de Linux sobre la función de case-folding de bcachefs¹. Su argumento central se resume en una frase: los nombres de archivo deberían ser solo una cadena de bytes, y el sistema de archivos no debería intentar «entenderlos».

No es solo una cuestión de preferencia técnica. Cuando empezamos a dotar de semántica a los nombres de archivo, como hacer que el sistema entienda que «A» y «a» son lo mismo, o que «é» y «e+´» son lo mismo, abrimos una caja de Pandora.

Intentemos comprender la esencia de este problema.

La esencia de los nombres de archivo: ¿Identificador o nombre?

En una biblioteca, cada libro tiene dos formas de identificación: el título y la signatura (o número de clasificación). El título tiene semántica, te dice de qué trata el libro; la signatura es opaca, es simplemente un identificador único utilizado para localizar el libro en el estante.

Los diseñadores de Unix eligieron el modelo de la «signatura».

En la filosofía de diseño de Unix, un nombre de archivo es una secuencia de bytes opaca. La responsabilidad del kernel es simple: mapear esa secuencia de bytes a un inode (nodo de índice). Como se afirma en «Understanding the Linux Kernel» de O’Reilly: «Un archivo Unix es un contenedor de información estructurado como una secuencia de bytes; el kernel no interpreta el contenido de un archivo»². Esta filosofía de «no interpretación» se aplica igualmente a los nombres de archivo.

¿Cuál es la razón profunda de esta elección de diseño?

La simplicidad aporta predictibilidad. Cuando los nombres de archivo son solo secuencias de bytes, el comportamiento del sistema es completamente determinista: dos nombres de archivo son iguales si y solo si sus secuencias de bytes son idénticas. No hay ambigüedad, ni casos especiales, ni dependencias culturales. La capa VFS (Virtual File System) resuelve la ruta a un inode a través de la dentry cache, pero este proceso es una comparación pura de bytes³.

Sin embargo, macOS eligió un camino diferente.

Relaciones de equivalencia: Cuando lo «mismo» se vuelve complejo

En matemáticas, una relación de equivalencia es una relación que cumple tres propiedades: reflexiva (a ~ a), simétrica (si a ~ b, entonces b ~ a) y transitiva (si a ~ b y b ~ c, entonces a ~ c). Cuando decimos que algo es insensible a mayúsculas y minúsculas (case-insensitive), en realidad estamos definiendo una relación de equivalencia: A ~ a, B ~ b, y así sucesivamente.

Parece sencillo, ¿verdad?

Pero el problema es: ¿quién define esta relación de equivalencia? Diferentes sistemas pueden tener definiciones distintas.

En inglés, la mayúscula de «i» es «I», lo cual parece obvio. Pero el turco tiene cuatro formas diferentes de la letra «i»:

En turco, la mayúscula de «i» es «İ» (I mayúscula con punto), mientras que la minúscula de «I» es «ı» (i minúscula sin punto)⁴. Esto significa que si una comprobación de seguridad utiliza las reglas del inglés para convertir «FILE» a minúsculas y obtiene «file», mientras que el sistema de archivos utiliza las reglas del turco y obtiene «fıle», estas dos cadenas no coincidirán, a pesar de que «deberían» ser el mismo nombre de archivo.

Esto revela un problema profundo: la conversión de mayúsculas y minúsculas no es una operación universal e independiente de la cultura. Cuando implementamos la insensibilidad a mayúsculas en el nivel del sistema de archivos, debemos elegir una regla específica, y esa elección puede ser inconsistente con las reglas que utilizan los programas en el espacio de usuario.

Normalización Unicode: Un agujero de conejo aún más profundo

Si la insensibilidad a mayúsculas ya es complicada, la normalización Unicode lleva el problema a otra dimensión.

Empecemos con una pregunta sencilla: ¿es «é» un carácter o dos?

En Unicode, la respuesta es «ambos». «é» puede representarse con un solo punto de código U+00E9 (LATIN SMALL LETTER E WITH ACUTE), o con dos puntos de código U+0065 (LATIN SMALL LETTER E) + U+0301 (COMBINING ACUTE ACCENT). Estas dos representaciones son visualmente idénticas, pero a nivel de bytes son completamente diferentes:

1
Forma precompuesta (NFC): C3 A9           -> é
2
Forma descompuesta (NFD):  65 CC 81        -> e + ́ → é

El estándar Unicode define cuatro formas de normalización: NFC, NFD, NFKC y NFKD⁶. NFC tiende a usar caracteres precompuestos, mientras que NFD tiende a descomponer los caracteres en un carácter base más marcas de combinación.

HFS+ eligió NFD. Según la documentación técnica de Apple, HFS+ utiliza una forma de normalización «muy cercana a la Unicode Normalization Form D»⁷. Esto significa que cuando creas un archivo llamado café, el sistema descompone automáticamente la é en los dos puntos de código e + ´.

Esta decisión de diseño tiene su lógica: al forzar la normalización, HFS+ garantiza que un mismo «carácter» tenga solo una representación, evitando que los usuarios creen dos archivos que «parecen iguales pero son diferentes».

Pero aquí hay un problema crítico: las reglas de normalización de HFS+ se basan en Unicode 3.2, y estas reglas no pueden actualizarse con la evolución del estándar Unicode porque «tal evolución invalidaría los volúmenes HFS+ existentes»⁸.

En 2017, Apple lanzó APFS para reemplazar a HFS+. APFS introdujo un cambio importante: ya no fuerza la normalización Unicode, sino que es normalization-preserving but normalization-insensitive⁹. Esto significa que APFS conservará la secuencia de bytes original que introduzcas, pero seguirá considerando la equivalencia de normalización al comparar nombres de archivo.

Este cambio resolvió algunos problemas, pero trajo otros nuevos. Al migrar de HFS+ a APFS, los nombres de archivo que ya estaban normalizados mantienen su forma NFD, mientras que los archivos nuevos pueden usar la forma NFC. En ciertos casos límite, esto puede provocar que nombres de archivo que «parecen iguales pero son diferentes» coexistan en el mismo directorio.

La esencia de las vulnerabilidades de seguridad: Inconsistencia en las relaciones de equivalencia

Ahora podemos entender la esencia de las vulnerabilidades de seguridad.

Cuando un programa de comprobación de seguridad y el sistema de archivos utilizan diferentes relaciones de equivalencia, se crea una «brecha». Un atacante puede construir un nombre de archivo que parezca seguro para el programa de comprobación, pero que para el sistema de archivos sea equivalente a un nombre de archivo peligroso.

Torvalds describió este problema con precisión en su correo:

Problemas de seguridad como «el espacio de usuario comprobó que el nombre de archivo no coincidía con algún patrón sensible para la seguridad». Y luego el estúpido sistema de archivos termina coincidiendo con ese patrón de todos modos…

Veamos un ejemplo concreto.

En marzo de 2021, el proyecto Git reveló una vulnerabilidad grave, CVE-2021-21300¹⁰. Este fallo afectaba especialmente a los usuarios de Windows y macOS que utilizaban sistemas de archivos insensibles a mayúsculas.

El principio de la vulnerabilidad involucra el mecanismo de caché lstat de Git. Cuando Git descarga (checkout) archivos, mantiene una caché para reducir las llamadas al sistema. Un atacante podía construir un repositorio malicioso que contuviera dos archivos: A y a. En un sistema de archivos sensible a mayúsculas, estos son dos archivos distintos; pero en uno insensible, colisionan.

La clave del ataque reside en la inconsistencia entre la lógica interna de Git (basada en la suposición de sensibilidad a mayúsculas) y el comportamiento del sistema de archivos (insensible). El atacante aprovecha esta inconsistencia para lograr que Git ejecute código arbitrario durante el proceso de checkout.

Los problemas de seguridad derivados de la normalización Unicode son aún más sutiles. Según el artículo de investigación de Black Hat USA 2019 «Host/Split: Exploitable Antipatterns in Unicode Normalization», cuando las decisiones de seguridad se basan en cadenas Unicode y el procesamiento posterior utiliza una forma de normalización diferente, se generan vulnerabilidades explotables¹¹.

Consideremos este escenario: un software de seguridad comprueba si un nombre de archivo coincide con la ruta sensible /etc/passwd.

Un atacante crea un archivo cuyo nombre contiene caracteres invisibles o variantes de Unicode. El software de seguridad comprueba la cadena, ve que no es igual a /etc/passwd y permite el acceso.

Sin embargo, el sistema de archivos, al procesarlo internamente, podría normalizar esas variantes de Unicode a una forma equivalente a /etc/passwd, eludiendo así la comprobación de seguridad.

El CERT/CC registró un problema similar en VU#999008: los compiladores permiten que caracteres de control Unicode y homóglifos aparezcan en el código fuente, lo que podría usarse para ocultar código malicioso durante las revisiones de código¹².

TOCTOU: El problema de la equivalencia en la dimensión temporal

Existe otra clase de vulnerabilidad aún más sutil: TOCTOU (Time-of-Check to Time-of-Use).

La esencia de una vulnerabilidad TOCTOU es que existe una ventana de tiempo entre la comprobación y el uso, durante la cual un atacante puede cambiar el estado del sistema, invalidando el resultado de la comprobación¹³.

En el contexto de los sistemas de archivos, este problema está estrechamente relacionado con la interpretación semántica de los nombres de archivo. Pensemos en el proceso de acceso a un archivo:

1. El programa solicita acceso a un archivo usando su nombre.
2. El kernel resuelve el nombre de archivo a un inode.
3. El kernel comprueba los permisos.
4. El kernel devuelve un descriptor de archivo.

El problema es que, entre el paso 1 y el paso 2, el mapeo del nombre de archivo al inode puede cambiar. Un atacante podría, en esa ventana, redirigir el nombre de archivo a otro archivo.

La insensibilidad a mayúsculas y la normalización Unicode de macOS complican el problema TOCTOU. Cuando una comprobación de seguridad utiliza una representación del nombre de archivo y la operación real utiliza otra representación equivalente pero diferente, la ventana TOCTOU se amplía.

El artículo de USENIX FAST’23 «Unsafe at Any Copy: Name Collisions from Mixing Case Sensitivity» estudió este problema de forma sistemática¹⁵. La investigación descubrió que existen diferencias en las reglas de case-folding y las técnicas de normalización entre distintos sistemas de archivos. Por ejemplo, temp_200K (donde K es el signo Kelvin, U+212A) y temp_200k se consideran iguales en NTFS y APFS, pero diferentes en ZFS.

Esta inconsistencia es un caldo de cultivo para vulnerabilidades de seguridad.

Defensa en profundidad: Cuando el nombre de archivo no es de confianza

Ante la realidad de que los nombres de archivo no son de confianza, Apple ha optado por una estrategia de defensa en profundidad (Defense in Depth).

La idea central de esta estrategia es: dado que no podemos hacer que los nombres de archivo sean confiables, no dependamos de ellos para establecer la confianza. En su lugar, establecemos barreras de seguridad independientes en múltiples niveles, cada una con su propia base de confianza.

Veamos cómo Apple implementa esta estrategia.

Merkle Trees y el Volumen de Sistema Firmado

macOS Big Sur (11.0) introdujo el mecanismo de Volumen de Sistema Firmado (SSV, Signed System Volume)¹⁶. La idea central de SSV es utilizar hashes criptográficos para verificar la integridad del sistema, en lugar de depender de los nombres de archivo.

La implementación técnica de SSV se basa en árboles de Merkle. Un árbol de Merkle es una estructura de datos elegante que nos permite verificar la integridad de un conjunto de datos de cualquier tamaño mediante un «hash raíz» de tamaño fijo¹⁷.

El funcionamiento de un árbol de Merkle es el siguiente:

1. Los datos se dividen en bloques y se calcula el hash de cada bloque (nodos hoja).
2. Los hashes adyacentes se emparejan y se calcula su hash combinado (nodos internos).
3. Se repite el paso 2 hasta que solo queda un hash (nodo raíz).

Esta estructura tiene una propiedad clave: cualquier modificación en un bloque de datos provocará cambios en todos los hashes de la ruta desde esa hoja hasta la raíz. Por lo tanto, si el hash raíz es de confianza, podemos verificar la integridad de todo el conjunto de datos.

En la implementación de SSV, cada archivo del volumen del sistema tiene un hash SHA-256 almacenado en los metadatos del sistema de archivos. El hash del nodo raíz se denomina seal (sello) y cubre cada byte del SSV.

Este seal es verificado por el cargador de arranque cada vez que se inicia el Mac. Si la verificación falla, el arranque se detiene y se pide al usuario que reinstale el sistema operativo¹⁸.

¿Qué significa esto? No importa qué confusión de mayúsculas, variantes de Unicode o incluso si el atacante obtiene privilegios de Root; si intenta modificar cualquier contenido del volumen del sistema, los hashes no coincidirán y el sistema se negará a arrancar. El problema de la interpretación semántica de los nombres de archivo se vuelve irrelevante aquí, porque la integridad de todo el volumen se garantiza mediante hashes criptográficos, no mediante nombres de archivo.

Marcado de metadatos y SIP

Antes de SSV, macOS ya contaba con SIP (System Integrity Protection), también conocido como rootless¹⁹. La idea central de SIP es proteger archivos críticos mediante marcas en los metadatos, en lugar de depender de los nombres de archivo.

SIP introdujo un nuevo indicador de archivo llamado restricted. Los archivos marcados como restricted no pueden ser modificados, incluso por el usuario root²⁰.

La clave es que la comprobación de SIP se basa en la marca de metadatos del inode, no en el nombre del archivo. Cuando cualquier proceso intenta escribir en un directorio protegido, el kernel comprueba si ese inode está marcado como «protegido por SIP». Incluso si un atacante engaña a las comprobaciones de nivel superior mediante variantes de Unicode o confusión de mayúsculas, cuando la solicitud llega al kernel, este examina el indicador restricted del inode y rechaza la operación.

Este es un principio de diseño importante: trasladar la base de confianza del nombre de archivo a los metadatos del inode. El nombre de archivo puede ser confuso, pero los metadatos del inode son gestionados directamente por el kernel y no se ven afectados por la interpretación semántica del nombre.

Descriptores de archivo: Evitando el nombre de archivo

Apple fomenta en su documentación para desarrolladores el uso de NSURL (objetos) y File Descriptors (descriptores de archivo) en lugar de usar directamente cadenas de rutas de archivos²¹.

Esta elección de diseño tiene profundas consideraciones de seguridad.

Bajo el mecanismo de Sandbox, cuando un usuario autoriza a una aplicación a acceder a un archivo, el sistema le otorga un Token en lugar de una ruta. La aplicación puede usar este Token para solicitar acceso al archivo al kernel, y el kernel localiza el archivo a través del inode.

Este diseño evita los complejos problemas de resolución de rutas, coincidencia de mayúsculas y normalización Unicode. Más importante aún, elimina fundamentalmente la posibilidad de vulnerabilidades TOCTOU, ya que el descriptor de archivo apunta directamente al inode en lugar de referenciarlo indirectamente a través de un nombre de archivo.

TCC: Control de acceso basado en la identidad del proceso

TCC (Transparency, Consent, and Control) es el marco que utiliza macOS para gestionar el acceso de las aplicaciones a datos sensibles²². El núcleo de TCC es una base de datos SQLite almacenada en /Library/Application Support/com.apple.TCC/TCC.db.

La característica de seguridad clave de TCC es que intercepta el acceso basándose en la identidad del proceso (no en el nombre del archivo). Cuando un atacante intenta leer un directorio de privacidad del usuario, TCC comprueba la identidad y los permisos del proceso solicitante, en lugar de simplemente comprobar la cadena de la ruta del archivo.

La propia base de datos de TCC está protegida por SIP y no puede modificarse directamente²³. Para interferir con estas bases de datos, un atacante tendría que desactivar SIP o ganar acceso a un proceso del sistema de confianza.

Reflexión sobre la filosofía de diseño

Volviendo a la crítica de Linus Torvalds, podemos ver que no es solo un problema técnico, sino de filosofía de diseño.

La filosofía de diseño de Unix enfatiza la simplicidad y la ortogonalidad. Los nombres de archivo son secuencias de bytes; el kernel no interpreta su significado. La ventaja de este diseño es la predictibilidad y la seguridad: no hay conversiones semánticas ocultas ni relaciones de equivalencia inesperadas.

macOS eligió un camino diferente, intentando ofrecer una experiencia más amigable al usuario. La insensibilidad a mayúsculas evita que el usuario tenga que preocuparse por la diferencia entre Documento.txt y documento.txt. La normalización Unicode evita que el usuario tenga que entender la diferencia entre NFD y NFC.

Pero esta amabilidad tiene un precio. Cuando el sistema de archivos empieza a «entender» los nombres de archivo, asume la responsabilidad de definir qué es «lo mismo». Y la definición de lo mismo es compleja, depende de la cultura y está en constante evolución.

El problema más profundo es que, cuando usamos diferentes definiciones de «lo mismo» en distintos niveles del sistema, se generan vulnerabilidades de seguridad. Un programa de comprobación de seguridad puede usar una relación de equivalencia, el sistema de archivos otra, y los atacantes aprovechan precisamente esa inconsistencia para eludir las comprobaciones.

La estrategia de defensa en profundidad de Apple es un compromiso pragmático. Dado que no se pueden cambiar decisiones históricas (la insensibilidad a mayúsculas ya es el comportamiento por defecto de macOS), se establecen barreras de seguridad independientes en niveles superiores e inferiores:

• SSV protege la integridad del sistema mediante hashes criptográficos.
• SIP protege archivos críticos mediante marcas en los metadatos.
• Los descriptores de archivo evitan el nombre de archivo y usan directamente el inode.
• TCC protege los datos del usuario mediante la verificación de la identidad del proceso.

La característica común de estos mecanismos es que no confían en el nombre del archivo. Utilizan hashes criptográficos, marcas de metadatos, identidad de procesos e inodes para establecer la confianza, en lugar de depender de cadenas de texto que pueden ser confusas.

Conclusión

La crítica de Torvalds nos recuerda un principio fundamental: los sistemas de seguridad no deberían depender de interpretaciones semánticas complejas.

Un modelo simple, aunque sea imperfecto, suele ser más fiable y predecible que uno complejo. El principio de Unix de que «el nombre de archivo es una secuencia de bytes» es precisamente ese modelo simple: renuncia a la capacidad de «entender» el nombre del archivo, pero a cambio gana predictibilidad y seguridad.

La historia de macOS demuestra el coste de la complejidad. Desde la normalización Unicode de HFS+ hasta la insensibilidad a la normalización de APFS, pasando por las vulnerabilidades de Git y los ataques TOCTOU, la interpretación semántica de los nombres de archivo ha sido un foco constante de problemas de seguridad.

Sin embargo, la estrategia de respuesta de Apple también muestra sabiduría de ingeniería: cuando no podemos eliminar la complejidad, podemos limitar su impacto mediante la defensa en profundidad. SSV, SIP, descriptores de archivo, TCC… ninguno de estos mecanismos depende de la interpretación semántica de los nombres de archivo; establecen una base de confianza independiente en niveles más bajos.

Para los desarrolladores, la lección de esta historia es clara:

• Nunca asumas que un nombre de archivo es único o inmutable.
• Utiliza descriptores de archivo en lugar de cadenas de rutas para las operaciones con archivos.
• Al realizar comprobaciones de seguridad, considera el impacto de las mayúsculas y la normalización Unicode.
• Al desarrollar para múltiples plataformas, prueba en entornos tanto sensibles como insensibles a mayúsculas.

Como dijo Torvalds, los nombres de archivo deberían ser solo una cadena de bytes. Cuando empezamos a dotarlos de significados mágicos, abrimos la caja de Pandora.

Referencias