Por qué no se puede confiar en la configuración de Privacy & Security de macOS

• Se confirmó un problema en el que la configuración de Privacy & Security de macOS no refleja el estado real de los permisos de acceso
• Incluso cuando el acceso a la carpeta Documents está bloqueado, la app Insent todavía puede leer archivos
• Si el usuario selecciona la carpeta directamente, el sistema TCC lo considera un acceso intencional y elimina las restricciones
• En la pantalla de configuración aparece como bloqueado, pero en realidad las restricciones del sandbox se levantan y el acceso sigue permitido
• Para bloquear por completo el acceso, se requiere un comando en Terminal y reiniciar, lo que puede llevar a una pérdida de control por parte del usuario

---

Problemas de confiabilidad en la configuración de Privacy & Security de macOS

• Se confirmó un caso en el que la configuración de Privacy & Security de macOS no refleja con precisión el estado real de los permisos de acceso
  • Usando una app simple llamada Insent, se observó que era posible acceder realmente a la carpeta Documents incluso cuando en la configuración aparecía como bloqueado
  • Este problema también puede reproducirse de la misma forma en macOS 13.5 o versiones posteriores

• Cómo funciona la app Insent

  • El botón Open by consent abre y muestra un archivo de texto cualquiera dentro de la carpeta Documents con el consentimiento del usuario
  • El botón Open from folder permite abrir y mostrar archivos dentro de una carpeta cuando el usuario la selecciona directamente
  • En este último caso, la intención (intent) del usuario se considera como permiso de acceso, por lo que el sistema TCC (Transparency, Consent, and Control) permite el acceso sin pedir un consentimiento adicional

• Procedimiento del experimento y resultados

  • Después de permitir el acceso a Documents, se confirmó que Insent podía leer archivos con normalidad
  • Luego, al desactivar en Privacy & Security el acceso de Insent a Documents, el acceso queda bloqueado
  • Sin embargo, si se selecciona Documents con Open from folder, el acceso vuelve a ser posible, y después Open by consent también funciona sin restricciones
  • En la pantalla de configuración sigue apareciendo que el acceso está bloqueado, pero en realidad Insent puede seguir accediendo a la carpeta Documents
  • Para bloquear completamente el acceso es necesario ejecutar el comando tccutil reset All co.eclecticlight.Insent y reiniciar la Mac

• Análisis del funcionamiento interno

  • Insent es una app notarizada común y no usa sandbox ni permisos especiales
  • Con System Integrity Protection (SIP) activado, algunas operaciones se procesan dentro del sandbox
  • sandboxd intercepta las solicitudes de acceso a archivos y envía una solicitud de aprobación a TCC; si el usuario da su consentimiento, el acceso se permite
  • Después de desactivar el acceso, TCC lo rechaza, pero si el usuario selecciona la carpeta mediante un panel Open/Save, sandboxd deja de interceptar la solicitud
  • Como resultado, TCC ya no puede controlar ese acceso y la carpeta queda accesible con las restricciones del sandbox levantadas

• Causa del problema

  • Cuando ocurre un acceso basado en la intención del usuario, se eliminan las restricciones del sandbox sobre esa carpeta
  • Ese cambio no se refleja en la UI de Privacy & Security, por lo que parece que está bloqueado aunque en realidad el acceso siga permitido
  • Otras carpetas protegidas (por ejemplo, Desktop, Downloads) funcionan correctamente, y el problema ocurre de forma independiente según la carpeta

• Conclusión

  • No se puede confiar en que la indicación de restricción de acceso en Files & Folders refleje el estado real aplicado

    • Aunque una app no aparezca en la lista o parezca bloqueada, en algunos casos en realidad puede acceder a carpetas protegidas
    • Una vez que se concede el acceso, no se revoca sin un comando de Terminal y un reinicio, lo que implica el riesgo de que el usuario pierda control sobre el acceso

• Discusión adicional (resumen de comentarios)

  • Después del experimento, se supone que a la carpeta Documents se le añade el atributo extendido com.apple.macl, que cumple la función de permitir el acceso de Insent
  • El comando tccutil reset elimina las entradas macl de la base de datos, pero el xattr (atributo extendido) puede permanecer, por lo que el acceso podría mantenerse
  • Con SIP activado, es difícil eliminar ese atributo, y solo puede borrarse en modo de recuperación con el comando xattr -d com.apple.macl path/to/Documents
  • Debido a esto, el usuario queda en una situación en la que es difícil comprobar o controlar el estado real de acceso de una app

[GN⁺]

Opiniones de Hacker News

• A mí me parece un problema simple. Si le das permiso a una app para acceder a una carpeta, es natural esperar que también pueda acceder a los archivos dentro de esa carpeta

  • Hay que leer la documentación con cuidado. La configuración de Files & Folders no refleja con precisión el estado real de los permisos. En la UI puede verse como si estuviera bloqueado, pero la app aún puede tener acceso ilimitado a la carpeta Documents
  • El punto clave es que “se otorgó el permiso, luego se desactivó en la UI y aun así sigue habiendo acceso”
  • Incluso al inicio del artículo se indica claramente que “la configuración de seguridad puede mostrar incorrectamente el estado real de acceso de una app”
  • Esperaba que macOS reconociera las carpetas ya vinculadas en la UI y las conectara también en el backend, pero parece que se maneja como una simple excepción de ruta y por eso la UI queda desactivada. Esto suena a algo que deberían reportar como feedback report. El autor suele tratar temas de Gatekeeper y TCC, así que se entiende la preocupación
  • El artículo está redactado de forma muy poco clara. No explica bien cuál es el mecanismo que hace que el acceso siga existiendo después de quitar el permiso

• Después de leer el artículo, desactivé todos los permisos de carpetas e hice una prueba, y Insent podía leer Documents aunque en la UI aparecía como “None”. Parece una falla de transparencia

  • Me hace preguntarme si las apps no tendrán acceso por defecto a la carpeta home del usuario

• Es la ironía de un OS centrado en la GUI. Para bloquear por completo el acceso a la carpeta Documents, hay que abrir la terminal y ejecutar
  tccutil reset All co.eclecticlight.Insent
  luego reiniciar

  • Jobs se revolvería en su tumba. Dicen que incluso en la época de NeXT había muchos choques entre GUI y CLI como este
  • También hay rarezas relacionadas con la GUI. Apagué el equipo con el Wi‑Fi desactivado, pero al iniciar y entrar sesión el ícono de Wi‑Fi pareció activarse por un momento antes de volver a mostrarse como desactivado. No sé si es solo un bug visual o si realmente se enciende brevemente

• Sería más preciso cambiar el título a algo como “Las apps de macOS mantienen acceso a carpetas aunque el usuario lo haya revocado”

  • Pero en realidad el usuario no revocó un acceso específico, sino solo el acceso general a carpetas. No hay forma de revocar por separado accesos más específicos

• El sistema de sandbox de Mac me recuerda al UAC de Windows. Es una estructura que solo aumenta el cansancio del usuario.
  Creo que el enfoque de contenedores opcionales de *nix es mucho mejor.
  Que un proceso en segundo plano lanzado desde Terminal mantenga los permisos incluso si el proceso padre muere es especialmente raro. Todo el esquema de permisos se siente algo ceremonial

  • Apple debería volver a ver sus anuncios viejos (enlace de YouTube)
  • Como referencia, UAC no es un límite de seguridad, así que un UAC-bypass no se trata como una vulnerabilidad de escalación de privilegios
  • El problema más grande es que muchos desarrolladores siguen atrapados en el viejo paradigma de que “todo puede acceder a todo”. La UX de macOS no es perfecta, pero dejar el acceso ilimitado como valor por defecto es todavía más riesgoso
  • Además, Apple pone excepciones para sus propias apps. Es para no dañar la experiencia de usuario
  • Esto no es el sandbox de Mac, sino el sistema TCC. Las apps que usan App Sandbox ni siquiera pueden mostrar el prompt de acceso a Documents. En cambio, pueden mantener acceso mediante algo llamado Security Scoped Bookmark (enlace de referencia)

• Además de tccutil reset, también se puede reiniciar activando y desactivando el permiso desde la configuración de seguridad
  La UI solo muestra mal el estado por un bug, pero los permisos reales funcionan correctamente.
  El color de las casillas también cambia según si tienen foco o no, lo que confunde. En la versión Sequoia sigue pasando.
  También es curioso que los juegos instalados en discos externos pidan acceso a “removable volumes” y terminen apareciendo en masa en la lista

• Es difícil saber si esto es un bug, una vulnerabilidad de seguridad o un simple descuido. Me hace pensar si convendría ejecutar el comando reset para todas las apps

  • Es simplemente una omisión en la UI. El sistema interno está funcionando bien
  • Esto se clasifica como un bug de UI de seguridad. Como impide que el usuario entienda el estado real de los permisos, incluso podría ameritar un CVE
  • Es un caso donde los procedimientos de seguridad formales de Apple chocan con la estructura real de acceso a archivos. La configuración debería mostrar claramente el estado de los permisos, dificultar volver a concederlos después de revocarlos, y ya deberían dejar atrás eso de requerir reiniciar la app para ciertos permisos

• En macOS recientes también hay una confusión similar en la UI de seguridad
  En “Full Disk Access”, algunas apps aparecen en gris y no se distingue si están activadas o desactivadas.
  No se sabe si eso es un bug o si realmente tienen permiso

  • La explicación de Apple es ambigua. La lista de “Files & Folders” solo muestra el historial de solicitudes de permisos.
    Incluso si se desactiva Full Disk Access, solo se protegen algunas carpetas sensibles, y las carpetas comunes (Desktop, Documents, etc.) siguen siendo accesibles (documentación de Apple)

• La causa del problema es el atributo extendido com.apple.macl configurado en la carpeta Documents. No se puede eliminar por SIP

  • No es un bug, sino una descoordinación de UI entre dos sistemas de seguridad. La protección real funciona, pero la UI no puede representarla correctamente

• Me pregunto si en iOS pasa lo mismo

  • En iOS las apps no pueden acceder fuera del selector de archivos o de su propia carpeta, así que el mismo problema no ocurre