Apple ha introducido Protección de la Integridad del Sistema, también conocida como "rootless", con OS X 10.11, El Capitán. Entiendo que este es un paso para la protección general contra malware pero como desarrollador necesito acceso de escritura a algunos de los archivos que bloquea.
¿Cómo puedo desactivar esta protección?
Como lo explica Apple en la documentación para desarrolladores sobre SIP:
Advertencia
Desactiva SIP solo temporalmente para realizar tareas necesarias y vuélvelo a habilitar lo antes posible. No reactivar SIP cuando hayas terminado de probar dejará tu computadora vulnerable a código malicioso.
Si simplemente estás intentando configurar herramientas de desarrollo de sistema como vim, python2, ruby y demás, seguramente quieres instalar versiones mantenidas por la comunidad desde Homebrew y configurar esas en su lugar. Las herramientas proporcionadas por el sistema pueden ser convenientes para el inicio, pero si requieres excepciones de SIP para tu flujo de trabajo diario, seguramente estás haciendo las cosas de una manera que se romperá en una versión futura del sistema operativo, y puede romper aplicaciones y otra funcionalidad del sistema mientras tanto.
Las razones válidas para desactivar SIP podrían ser:
Además de las implicaciones de seguridad, también es importante el hecho de que todo lo que hagas en una Mac con SIP deshabilitado no funcionará en la Mac de cualquier otra persona a menos que también lo desactiven primero. Si estás desarrollando aplicaciones para Mac, entonces tu sistema se vuelve menos útil como plataforma de pruebas porque no sabes si tu código funciona solo porque modificaste tu sistema. Si estás desarrollando para otra plataforma como despliegue en un servidor web, entonces no puedes compartir tu configuración de entorno de desarrollo con otros desarrolladores de tu equipo sin comprometer su seguridad también.
La documentación de Apple cubre la desactivación de SIP, Sobre la Protección de Integridad del Sistema en tu Mac y Configurando la Protección de Integridad del Sistema.
Un artículo en lifehacker.com enumera estos pasos:
- Reinicia tu Mac en Modo de Recuperación reiniciando tu computadora y manteniendo presionadas las teclas Command+R hasta que aparezca el logo de Apple en tu pantalla.
- Haz clic en Utilidades > Terminal.
- En la ventana del Terminal, escribe
csrutil disabley presiona Enter.- Reinicia tu Mac.
Puedes verificar si un archivo o carpeta está restringido emitiendo este comando ls utilizando la letra O mayúscula (y no el cero 0) para modificar la bandera de listado largo:
ls -lO /System /usr Busca el texto restringido para indicar dónde se aplica SIP.
Por defecto (=SIP habilitado), las siguientes carpetas están restringidas (ver página de Soporte de Apple):
/System
/usr
/bin
/sbin
Aplicaciones preinstaladas con OS X... y las siguientes carpetas no lo están:
/Applications
/Library
/usr/local
Veo que al ejecutar ls -lO /usr/local no está marcado como restringido. También he cambiado propietario a /usr/local/ de forma recursiva. Pero sigo viendo que root se hace cargo de /usr/local/bin y /usr/local/share lo cual afecta a homebrew. ¿Es esto también obra de SIP?
@SaxDaddy Siempre que /usr/local no esté restringido, puedes solucionar fácilmente cualquier permiso "debajo" de este directorio. En realidad, Homebrew recomienda ejecutar sudo chown -R $(whoami) /usr/local (siendo un usuario administrador) para solucionar problemas de permisos.
@patrix Gracias. Todavía tengo curiosidad porque /usr/local no está restringido ni es propiedad de mí diariamente. Todavía cada día veo esas mismas 2 carpetas propiedad de root. Revisaré la consola y actualizaré si encuentro al culpable.
Es posible deshabilitar SIP arrancando en Recovery HD y ejecutando el siguiente comando:
csrutil disable
También es posible habilitar las protecciones de SIP y deshabilitar selectivamente aspectos de la misma, agregando una o más banderas al comando csrutil enable. Todos requieren arrancar desde Recovery para establecerlos:
Habilitar SIP y permitir la instalación de extensiones de kernel no firmadas
csrutil enable --without kext
Habilitar SIP y deshabilitar protecciones del sistema de archivos
csrutil enable --without fs
Habilitar SIP y deshabilitar restricciones de depuración
csrutil enable --without debug
Habilitar SIP y deshabilitar restricciones de DTrace
csrutil enable --without dtrace
Habilitar SIP y deshabilitar restricciones para escribir en NVRAM
csrutil enable --without nvram
También tengo una publicación disponible con más información sobre SIP:
Protección de la Integridad del Sistema - Agregando otra capa al modelo de seguridad de Apple
Recibo un error: csrutil: no se pudo modificar la configuración de integridad del sistema. Esta herramienta debe ejecutarse desde el sistema de recuperación.
Si el objetivo es realmente solo deshabilitar la Protección de la Integridad del Sistema, entonces arrancar en la partición de Recuperación HD como se recomendó anteriormente en las otras respuestas aquí a través de Command+r en el arranque no es la forma más rápida de hacerlo.
Puedes combinar el arranque en modo de usuario único con el arranque en Recuperación HD en una combinación de teclas de inicio no documentada:
Esto te lleva directamente al entorno mínimo necesario para hacer esto directamente.
Sería más seguro modificar /etc/paths para que /usr/local/bin esté simplemente antes de usr/bin. De esta manera puedes realizar tu trabajo de desarrollo dentro de /usr/local/bin sin tener que desactivar SIP.
Las instalaciones limpias del sistema operativo han ordenado /etc/paths de esta manera desde El Capitan, pero si estabas actualizando el sistema desde Yosemite o antes, tendrías que modificar manualmente el orden de la ruta.
Antes de El Capitan, una convención común era instalar programas en usr/bin. Dado que SIP lo impide ahora, los programas deberían instalarse en usr/local/bin, que no está restringido por SIP. Al poner usr/local/bin primero, los usuarios pueden ejecutar programas sin tener que escribir la ruta absoluta del programa. ¿Tiene sentido? ¿Estás confundido acerca de algo más?
Siempre he entendido que es una práctica muy mala poner algo en /usr/bin ... pero supongo que lo que debería haber preguntado es "¿cómo responde esto a la pregunta del OP?" Originalmente asumí que sí lo hacía de alguna manera, y que simplemente no estaba haciendo la conexión. Pero ahora tengo muchas dudas de que tenga alguna conexión.
Si todo lo que necesitas es acceder a /usr/local, echa un vistazo a esta página: http://web.archive.org/web/20160117204214/https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/El_Capitan_and_Homebrew.md
La idea es temporalmente desactivar SIP usando csrutil disable, agregar /usr/local, usar chflags para establecer ese directorio como no restringido
sudo mkdir /usr/local && sudo chflags norestricted /usr/local && sudo chown -R $(whoami):admin /usr/localy luego volver a habilitar SIP usando csrutil enable.
Si /usr/local ya existe en el momento de la actualización, entonces ni siquiera es necesario lo anterior. Simplemente puedes ejecutar
sudo chown -R $(whoami):admin /usr/local AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.
2 votos
Aunque puedes solucionar todos los aspectos de SIP, hay muchas entradas para esto - recuerda que al comprometer el sistema, estás construyendo cosas que pueden no funcionar en la máquina de tu cliente, donde SIP está activado, y los usuarios no aceptarán desactivarlo
5 votos
@Motti Shneor - Sin embargo, en algunos casos esto debe desactivarse simplemente para tener acceso de escritura e instalar algunos SDK para propósitos de desarrollo. Esto no requeriría que el cliente haga lo mismo.
0 votos
Vengo de un fondo de Unix, tratando de entender la lógica de rootless: ¿es porque la computadora probablemente sea una máquina de usuario único, todo se instalará en el directorio de inicio del usuario, de modo que no sea necesario meterse con el directorio del sistema como /usr/share/vim/.
0 votos
La premisa de esta pregunta es incorrecta. Como desarrollador, no necesitas enfatizar escribir en los archivos que bloquea.