Qué es SIP en Mac: así protege la integridad del sistema macOS

Le das a sudo rm sobre un archivo del sistema, la contraseña es correcta y macOS te suelta un seco Operation not permitted. No es un bug: es SIP haciendo su trabajo. Si te preguntas qué es SIP en Mac y qué tiene que ver con la integridad del sistema, la respuesta corta es esta: SIP (System Integrity Protection) es un conjunto de políticas de seguridad aplicadas a nivel de kernel que protege los componentes críticos de macOS frente a modificaciones, incluso por parte del usuario root. Está activo por defecto desde OS X El Capitan (10.11, 2015) y, a fecha de 2026, sigue siendo una pieza central de la seguridad de macOS Tahoe.

Qué es SIP y por qué existe

Antes de SIP, la cuenta root lo podía todo: cualquier proceso con privilegios de administrador podía reescribir archivos del sistema, inyectar código en procesos de Apple o instalar extensiones de kernel sin que nadie se opusiera. El problema es obvio: si un malware conseguía elevar privilegios (y los elevaba, con exploits o ingeniería social), tenía barra libre sobre todo el sistema operativo.

Apple lo resolvió con lo que la documentación de Apple Platform Security describe como controles de acceso obligatorios: políticas de seguridad creadas por el sistema que no se pueden anular con permisos de usuario, ni siquiera con los de administrador. SIP aplica esa política a cada proceso que se ejecuta en el Mac, da igual que corra en una zona protegida o con privilegios. Al concepto también se le conoce como rootless, porque en la práctica recorta los poderes del propio root.

Qué protege exactamente la integridad del sistema

SIP no es un único interruptor, sino varias protecciones concretas trabajando juntas:

• Ubicaciones críticas del sistema de archivos en solo lectura: rutas como /System, /usr (salvo /usr/local), /bin, /sbin y las apps preinstaladas de macOS. Solo los procesos firmados por Apple con los derechos adecuados (el instalador del sistema, básicamente) pueden escribir ahí.
• Protección de procesos del sistema: impide adjuntar un depurador o inyectar código en procesos firmados por Apple. Herramientas como dtrace o lldb no pueden inspeccionar procesos del sistema con SIP activo.
• Restricciones sobre extensiones de kernel: los kext deben estar firmados y cumplir requisitos; nada de cargar código arbitrario en el kernel.
• Protección de variables NVRAM y otras configuraciones de arranque sensibles.

La consecuencia práctica es que, aunque un atacante ejecute código como root, no puede tocar el núcleo del sistema. Puede molestar en tu carpeta de usuario, pero no convertir macOS en su casa.

Cómo comprobar el estado de SIP en tu Mac

Abre Terminal y ejecuta:

csrutil status

La respuesta normal, y la que quieres ver, es System Integrity Protection status: enabled.. También puedes mirarlo en Información del Sistema (menú Apple → Acerca de este Mac → Informe del sistema), en el apartado «Software», donde figura como «Protección de integridad del sistema». Si aparece desactivado en un Mac de uso diario, alguien lo desactivó a propósito: no se apaga solo ni por accidente.

Por qué no conviene desactivar SIP

Busca en Google cualquier problema exótico de macOS y encontrarás foros que recomiendan desactivar SIP como primer paso, como quien receta antibióticos para un resfriado. Es un mal consejo casi siempre, por tres motivos:

1. Es permanente y global. En un Mac con chip Intel, desactivar SIP elimina la protección de todas las particiones del disco, no solo de la que te interesa. Y se queda desactivado hasta que lo reactives manualmente.
2. Elimina la barrera que frena al malware con privilegios. La mayoría de técnicas de persistencia y rootkits para macOS asumen SIP activo; sin él, el trabajo del atacante es mucho más barato.
3. El problema que intentabas resolver suele tener otra solución. Una app que «necesita SIP desactivado» en 2026 es, en el mejor de los casos, software abandonado que usa kext obsoletos o que escribe donde no debe. En el peor, es una excusa para pedirte que bajes la guardia.

Además, tocar SIP exige arrancar en el modo de recuperación de macOS y ejecutar csrutil disable desde allí: no es algo que se haga por descuido, así que desconfía de cualquier tutorial que lo presente como un trámite rutinario.

El caso excepcional: desarrollo

Hay un escenario legítimo para bajar partes de SIP: el desarrollo de bajo nivel. Si escribes extensiones de kernel, depuras procesos del sistema o trabajas con herramientas de instrumentación, SIP te estorba de verdad. Apple lo contempla en su documentación para desarrolladores (Disabling and Enabling System Integrity Protection), con matices importantes:

• Se hace desde la partición de recuperación con csrutil disable, y se revierte con csrutil enable.
• Se pueden desactivar protecciones individuales en lugar de todo el sistema, por ejemplo csrutil enable --without debug o --without kext, para tocar solo lo necesario.
• Apple recomienda hacerlo en una máquina o volumen dedicado a desarrollo, no en tu Mac de trabajo diario, y reactivar SIP en cuanto termines.

Si tu caso es «quiero instalar tal herramienta y pide desactivar SIP», antes prueba las vías modernas: la mayoría de utilidades que antaño requerían kext (monitores de sistema, VPN, captura de pantalla) usan hoy System Extensions y DriverKit, que funcionan con SIP activo.

SIP y el volumen de sistema sellado

SIP no actúa solo: desde macOS Catalina (10.15), el sistema vive en un volumen separado y montado en solo lectura, aparte del volumen de datos del usuario. Y desde macOS Big Sur (11), ese volumen de sistema es un snapshot firmado criptográficamente (SSV, Signed System Volume): cada archivo forma parte de un árbol de hashes que se verifica en cada arranque. Si un solo byte del sistema difiere de lo que Apple firmó, el Mac se niega a arrancar.

La relación con SIP es de capas complementarias: el sello garantiza que el sistema no ha cambiado desde que Apple lo firmó, y SIP garantiza que, mientras corre, nadie puede cambiarlo ni inyectarse en sus procesos. Por eso las actualizaciones de macOS son el único camino legítimo para modificar /System: el instalador crea un snapshot nuevo, lo firma y arranca sobre él. El comando csrutil authenticated-root, documentado en la página de manual de csrutil, controla precisamente si el Mac puede arrancar desde snapshots no sellados, una puerta que solo interesa abrir a quien desarrolla sobre el propio sistema.

Preguntas frecuentes

¿SIP ralentiza el Mac? No. Es un conjunto de políticas que el kernel evalúa en operaciones que de todos modos comprueba; su impacto en rendimiento es despreciable y ningún benchmark serio ha medido diferencias apreciables con SIP activo o inactivo.

¿Puedo desactivar SIP solo para una carpeta? No. SIP es global para la máquina (y en Intel, para todas las particiones). Lo que sí puedes es desactivar protecciones individuales con csrutil enable --without <flag> desde recuperación, pensado para desarrollo.

¿SIP sustituye a un antivirus? No, son capas distintas. SIP protege el sistema operativo de modificaciones; la detección de malware corre a cargo de Gatekeeper, la notarización y XProtect. Se complementan, no se solapan.

¿Por qué una app legítima me pide desactivar SIP? Porque usa técnicas antiguas (kext no firmados, inyección en procesos, escritura en rutas protegidas). A fecha de 2026, eso indica software sin mantenimiento o mal diseñado; busca una alternativa moderna antes de tocar nada.

En resumen: SIP es la razón por la que macOS puede garantizar que el sistema que arranca cada mañana es el mismo que Apple firmó. Déjalo activado, comprueba su estado con csrutil status si tienes dudas, y trata cualquier petición de desactivarlo como lo que es: una señal de alarma sobre el software que la hace.