En un sistema UNIX tradicional -incluyendo muchas de las principales plataformas que aún se utilizan hoy en día, como Debian- se considera que cualquier usuario o proceso con privilegios "Root" tiene el control absoluto de una máquina. Básicamente no hay nada que el sistema operativo no permita hacer a un usuario Root, ya sea reescribir archivos del sistema, añadir código a otros procesos, añadir código al kernel lo que sea. Si alguna vez te han dicho que no ejecutes programas como Root a menos que sea absolutamente necesario, esta es la razón.
MacOS, siendo a su vez un sistema operativo UNIX, también se comportó así durante muchos años. Tan recientemente como OS X 10.10 Yosemite, una vez que le dabas a una aplicación tu contraseña de Root/administrador, era libre de hacer cualquier cosa que quería, y MacOS no se interpondría en su camino.
Todo esto cambió con el lanzamiento de macOS El Capitán en 2015. Por primera vez en el Mac, Apple decidió definir un conjunto de acciones que consideraba que ningún usuario o programa -incluso con privilegios de Root- debía siempre ¡ser capaz de actuar! Entre estas restricciones se incluía la instalación de extensiones del kernel de desarrolladores no identificados (la protección "kext"), la inyección de código en procesos proyectados, como las aplicaciones hechas por Apple (la protección "debug"), y la escritura en ciertos directorios del sistema protegidos (la protección "fs").
Apple ha llamado a este nuevo conjunto de restricciones "System Integrity Protection", o SIP para abreviar, y también ha hecho posible que los usuarios avanzados lo desactiven, ejecutando un comando de Terminal desde el modo de recuperación. Al desactivar la SIP, el ordenador vuelve a tener el comportamiento tradicional de UNIX, dejando que el Root haga lo que quiera. Apple también ha hecho posible desactivar individualmente ciertas restricciones, por ejemplo, ejecutando csrutil disable && csrutil enable --without debug permitirá inyectar código en los procesos protegidos, pero dejará intactas las demás protecciones de SIP.
Basta con decir que desactivar el SIP le otorga un gran poder sobre el funcionamiento de su Mac. Recientemente he estado aprendiendo a mezclar métodos en Objective C; cuando el SIP está desactivado, se puede utilizar para reemplazar el código en las aplicaciones existentes, lo que es realmente muy divertido. Cuando una aplicación hace algo que no me gusta -ya sea que Zoom haga que todas sus ventanas floten groseramente en la parte superior, o que la aplicación Diccionario no respete la configuración del proxy de mi Mac- puedo seguir adelante y cambiarla.
El peligro, sin embargo, es que si I puedo inyectar mi propio código en cualquier otra aplicación, ¡otro software también podría hacerlo! No hace falta ser especialmente creativo para imaginar las travesuras que podría causar una aplicación malvada si pudiera modificar cada otros en su máquina. Por ejemplo, una aplicación podría inyectar sus propios anuncios en Safari, o decirle a Microsoft Word que envíe todos sus documentos a un servidor en Corea del Norte.
Por otro lado, las aplicaciones malignas con permisos Root pueden causar muchos estragos sin ¡desactivando el SIP! No tendrán ningún problema para instalar mineros de bitcoin, leer todo tu historial de navegación y pedir un rescate por muchos (aunque no todos) de los archivos de su disco duro. De hecho, muchos de estos ataques ni siquiera requieren Root para funcionar. La instalación de aplicaciones es intrínsecamente peligrosa, al igual que invitar a alguien a tu casa, a menos que provengan de la Mac App Store, donde se garantiza que están protegidas.
Sólo conozco un problema en el mundo real causado por la desactivación del SIP, aunque fue bastante grave. Hace un par de años, hubo un error en el actualizador de Google Chrome (que a veces solicita permisos de root... ugh...) que hizo que se sobrescribieran varios archivos del sistema central, haciendo que los Macs no pudieran arrancar. En los Macs con SIP activado, se impedía que Chrome borrara estos archivos, y Chrome seguía su camino. Es de suponer que Google nunca probó Chrome en un Mac sin SIP, por lo que no descubrió el problema antes del lanzamiento. En defensa de Google, arreglaron el problema rápidamente, y me imagino que Chrome ahora se prueba en Macs sin SIP. (Pero basta con decir que por esto no me gusta Google Chrome).
También debes tener en cuenta que en los Macs de silicona de Apple, Apple no permite que las aplicaciones de iOS se ejecuten mientras el SIP está desactivado, presumiblemente porque los desarrolladores esperan que el software de iOS sólo sea utilizable en un entorno bloqueado. (Esos desarrolladores también se equivocan, porque los Jailbreaks existen).
Teniendo en cuenta todo lo anterior, mi recomendación general es la siguiente:
-
Si no tienes una razón para desactivar el SIP, déjalo activado. No hará ningún daño.
-
Si tienes un motivo para desactivar el SIP, adelante, y no dejes que te quite el sueño. Tienes que ser un poco más cuidadoso con las aplicaciones que ejecutas como Root. De todos modos, tienes que hacerlo.
Otras personas pueden caer y caerán en otra parte de ese espectro. Espero que ahora tengas suficiente información para tomar tu propia decisión.
Vale, lo de "todo lo que quieras" es quizá una simplificación excesiva. Para empezar, las versiones modernas de MacOS tienen otros sistemas de protección además de SIP, como TCC y AMFI. La cuestión es que, una vez que el SIP está desactivado, en teoría no hay nada que impida a un proceso deshabilitarlos también -¿quién va a interponerse en el camino, cuando se puede literalmente reescribir la memoria del núcleo? Supongo que probablemente haya registros de la CPU protegidos y cosas así.
