¿Cuál es realmente la función "sin raíces" en El Capitán?

Primero: el nombre "sin raíz" es engañoso, ya que todavía hay una cuenta raíz y aún puede acceder a ella (el nombre oficial, "Protección de integridad del sistema", es más preciso). Lo que realmente hace es limitar el poder de la cuenta raíz, de modo que incluso si se convierte en raíz, no tiene control total sobre el sistema. Esencialmente, la idea es que es demasiado fácil para el malware obtener acceso a la raíz (por ejemplo, presentando un cuadro de diálogo de autenticación al usuario, lo que hará que el usuario ingrese reflexivamente la contraseña de administrador). SIP agrega otra capa de protección, en la que el malware no puede penetrar incluso si se rootea. La parte mala de esto, por supuesto, es que también debe aplicarse a las cosas que estás haciendo intencionalmente. Pero las restricciones que impone a la raíz no son tan malas; no impiden la mayoría de los "normales"

Esto es lo que restringe, incluso desde la raíz:

• No puede modificar nada en /System, /bin, /sbino /usr(excepto /usr/local); o cualquiera de las aplicaciones y utilidades integradas. Solo el instalador y la actualización de software pueden modificar estas áreas, e incluso solo lo hacen al instalar paquetes firmados por Apple. Pero dado que las personalizaciones de estilo OS X normales entran /Library(o ~/Library, o /Applications), y las personalizaciones de estilo Unix (por ejemplo, Homebrew) entran /usr/local(oa veces /etco /opt), esto no debería ser un gran problema. También evita escrituras a nivel de bloque en el disco de inicio, por lo que no puede omitirlo de esa manera.

  La lista completa de directorios restringidos (y excepciones como /usr/localy algunas otras) se encuentra en /System/Library/Sandbox/rootless.conf. Por supuesto, este archivo se encuentra en un área restringida.

  Cuando actualiza a El Capitan, mueve cualquier archivo "no autorizado" de áreas restringidas a /Library/SystemMigration/History/Migration-(some UUID)/QuarantineRoot/.

• No puede conectarse a los procesos del sistema (por ejemplo, aquellos que se ejecutan desde esas ubicaciones del sistema) para cosas como la depuración (o cambiar las bibliotecas dinámicas que cargan, u otras cosas). Una vez más, no es un gran problema; los desarrolladores aún pueden depurar sus propios programas.

  Esto bloquea algunas cosas importantes, como inyectar código en las aplicaciones integradas de Apple (en particular, el Finder). También significa que dtracelas herramientas basadas en software para el monitoreo del sistema (p. ej opensnoop., ) no podrán monitorear e informar sobre muchos procesos del sistema.

• No puede cargar extensiones de kernel (kexts) a menos que estén correctamente firmadas (es decir, por Apple o un desarrollador aprobado por Apple). Tenga en cuenta que esto reemplaza el antiguo sistema para hacer cumplir la firma kext (y las antiguas formas de omitirlo). Pero desde la versión 10.10.4, Apple ha tenido una forma de habilitar la compatibilidad con recortes para SSD de terceros , la razón principal para usar kexts sin firmar ha desaparecido.

• A partir de Sierra (10.12), algunos ajustes de configuración de launchd no se pueden cambiar (por ejemplo, algunos demonios de lanzamiento no se pueden descargar).

• A partir de Mojave (10.14), el acceso a la información personal de los usuarios (correo electrónico, contactos, etc.) está restringido a las aplicaciones que el usuario haya aprobado para acceder a esa información. Esto generalmente se considera una función separada (llamada Protección de información personal o TCC), pero se basa en SIP y al deshabilitar SIP también se deshabilita. Consulte: "¿Qué y cómo implementa macOS Mojave para restringir el acceso de las aplicaciones a los datos personales?"

• A partir de Catalina (10.15), la protección de la mayoría de los archivos del sistema se fortalece almacenándolos en un volumen separado de solo lectura. Esto no es estrictamente parte de SIP y no se deshabilita al deshabilitar SIP. Consulte: presentación de la WWDC sobre "Novedades en los sistemas de archivos de Apple [Catalina]" y "¿Qué es /System/Volumes/Data?" .

• A partir de Big Sur (11.x), el volumen del sistema de solo lectura ahora es un "Volumen del sistema sellado" (una instantánea montada en lugar de un volumen normal), por lo que realizar cambios en él es aún más complicado. Consulte: el artículo de Eclectic Light Company "Disposición del volumen de arranque de Big Sur" .

Si no desea estas restricciones, ya sea porque desea modificar su sistema más allá de lo que esto permite, o porque está desarrollando y depurando algo como kexts que no son prácticos bajo estas restricciones, puede desactivar SIP. Actualmente, esto requiere reiniciar en modo de recuperación y ejecutar el comando csrutil disable(y puede volver a habilitarlo de manera similar con csrutil enable).

La modificación del volumen del sistema en Catalina requiere deshabilitar SIP, luego montar el volumen con acceso de escritura (y luego se recomienda reiniciar y volver a encender SIP). En Big Sur, se requieren pasos adicionales para deshabilitar la autenticación del volumen del sistema antes de los cambios y luego crear una nueva instantánea .

También puede deshabilitar selectivamente partes de SIP. Por ejemplo, csrutil enable --without kextdeshabilitará la restricción de la extensión del kernel de SIP, pero dejará sus otras protecciones en su lugar.

Pero deténgase y piense antes de deshabilitar SIP, incluso de manera temporal o parcial: ¿realmente necesita deshabilitarlo o hay una mejor manera (compatible con SIP) de hacer lo que desea? ¿Realmente necesita modificar algo en /System/Libraryo /bino lo que sea, o podría ir en un lugar mejor como /Libraryo /usr/local/binetc? SIP puede "sentirse" restrictivo si no está acostumbrado, y hay algunas razones legítimas para deshabilitarlo, pero mucho de lo que impone es realmente una buena práctica de todos modos.

Para subrayar la importancia de dejar la mayor parte de SIP habilitado la mayor parte del tiempo posible, considere los eventos del 23 de septiembre de 2019. Google lanzó una actualización de Chrome que intentó reemplazar el enlace simbólico de /vara /private/var. En la mayoría de los sistemas, SIP bloqueó esto y no hubo efectos negativos. En los sistemas con SIP deshabilitado, macOS se rompió y no se pudo iniciar. La razón más común para deshabilitar SIP fue cargar extensiones de kernel no aprobadas (/incorrectamente firmadas) (específicamente controladores de video); si solo hubieran deshabilitado la restricción kext, no se habrían visto afectados. Consulte el hilo de soporte oficial de Google , una sesión de preguntas y respuestas para superusuarios y un artículo de Ars Technica .

Referencias y más información: presentación de WWDC sobre "Seguridad y sus aplicaciones" , una buena explicación de Eldad Eilam en quora.com , la revisión de Ars Technica de El Capitan , y un artículo de soporte de Apple sobre SIP , y una inmersión profunda de Rich Trouton ( quien también publicó una respuesta a esta pregunta ).

Para mí, significa que DTrace ya no funciona.

DTrace es similar a ptrace/strace en Linux, ya que le permite ver lo que un proceso le dice al kernel. Cada vez que un proceso quiere abrir un archivo, escribir un archivo o abrir un puerto, etc., necesita preguntarle al kernel. En Linux, este proceso de monitoreo ocurre fuera del kernel en "userland" y, por lo tanto, los permisos son bastante detallados. Un usuario puede monitorear sus propias aplicaciones (para corregir errores, encontrar fugas de memoria, etc.), pero necesitaría ser root para monitorear el proceso de otro usuario.

Sin embargo, DTrace en OSX funciona a nivel de kernel, lo que lo hace mucho más eficaz y potente; sin embargo, requiere acceso de root para agregar sus sondas en el kernel y, por lo tanto, hacer cualquier cosa. Un usuario no puede rastrear sus propios procesos sin ser root, pero como root no solo puede ver sus propios procesos, sino TODOS los procesos en el sistema simultáneamente. Por ejemplo, puede ver un archivo (con iosnoop) y ver qué proceso lo lee. Esta es una de las características más útiles para detectar malware. Debido a que el núcleo también se ocupa de la E/S de la red, lo mismo es cierto allí. Wireshark detecta actividad de red inusual, DTrace le informa el proceso de envío de datos, incluso si está integrado en el sistema como el kernel mismo.

Sin embargo, a partir de El Capitan, Apple ha impedido deliberadamente que DTrace funcione, ya que ha sido específicamente apuntado y señalado como algo restringido por SIP. ¿Por qué harían esto? Bueno, anteriormente Apple modificó su kernel y DTrace para permitir que algunos procesos optaran por no ser monitoreados a través de DTrace (lo que molestó a muchos investigadores de seguridad en ese momento, ya que algunos procesos ahora estaban fuera de los límites, incluso como root, incluido el malware). La razón de esto fue proteger DRM en aplicaciones como iTunes, ya que, en teoría, alguien podría DTrace y obtener datos sin DRM de la memoria de los procesos.

Sin embargo, hubo una solución importante que permitió a los investigadores seguir haciendo su trabajo y fue modificar el kernel para ignorar este indicador de exclusión voluntaria, de modo que DTrace aún se pudiera usar en estos procesos. Esto fue realmente genial porque los programas que intentaban evadir la detección ahora se iluminaron con esta bandera sin DTrace. Todo lo que Apple o los malos querían ocultar ahora estaba a la vista...

Pero no funciona ahora, entonces, ¿cómo te afecta esto? Bueno, te afectará tanto directa como indirectamente. Directamente, limitará su capacidad para monitorear su sistema. Una gran cantidad de herramientas de supervisión y administración de sistemas de bajo nivel (sobre las que se basan las herramientas de nivel superior) ya no funcionarán. Sin embargo, el efecto indirecto será mucho mayor: los profesionales de la seguridad confían en el acceso profundo al sistema para detectar los peores tipos de amenazas. Simplemente no podemos hacer eso más. Al analizar el malware, es fundamental que no sepa que se está ejecutando en un depurador o en un señuelo. Deshabilitar SIP le dice a todo el software, tanto de los malos como de Apple, que este sistema está siendo vigilado. No más mirar a los observadores. Si SIP se tratara de seguridad, podrían haber educado a los usuarios sobre la raíz; en cambio, la eliminaron. En última instancia, esto significa que Apple ha reemplazado la barrera de seguridad de "ser todo y acabar con todo" de la contraseña raíz, con el mecanismo de protección SIP "ser todo y acabar con todo". O si eres bueno en ingeniería social, una contraseña de root con un reinicio...

También está esto:

La Protección de integridad del sistema (SIP) es una política de seguridad general con el objetivo de evitar que terceros modifiquen los archivos y procesos del sistema. Para lograrlo, cuenta con los siguientes conceptos:

• Protección del sistema de archivos
• Protección de extensión de kernel
• Protección en tiempo de ejecución

Protección del sistema de archivos

SIP evita que otras partes que no sean Apple agreguen, eliminen o modifiquen directorios y archivos almacenados en ciertos directorios:

/bin
/sbin
/usr
/System

Apple ha indicado que los siguientes directorios están disponibles para que los desarrolladores accedan:

/usr/local
/Applications
/Library
~/Library

Todos los directorios /usrexcepto /usr/localestán protegidos por SIP.

Es posible agregar, eliminar o cambiar archivos y directorios protegidos por SIP a través de un paquete de instalación que está firmado por la propia autoridad de certificación de Apple. Esto permite a Apple realizar cambios en las partes del sistema operativo protegidas por SIP sin necesidad de cambiar las protecciones SIP existentes.

La autoridad de certificación en cuestión está reservada por Apple para su propio uso; Los paquetes de instalación firmados por ID de desarrollador no pueden modificar los archivos o directorios protegidos por SIP.

Para definir qué directorios están protegidos, Apple ha definido actualmente dos archivos de configuración en el sistema de archivos. El principal se encuentra en la siguiente ubicación:

/System/Library/Sandbox/rootless.conf

donde rootless.confenumera todas las aplicaciones y el nivel superior de directorios que protege SIP.

Aplicaciones

SIP protege las aplicaciones principales que OS X instala en Aplicaciones y Utilidades de aplicaciones. Esto significa que ya no será posible eliminar las aplicaciones que instala OS X, incluso desde la línea de comandos cuando se usan privilegios de root.

directorios

SIP también protege una serie de directorios y enlaces simbólicos fuera de /Applicationsy el nivel superior de esos directorios también se enumeran en rootless.conf.

Además de las protecciones, Apple también ha definido algunas excepciones a la protección de SIP en el archivo rootless.conf, y esas excepciones están marcadas con asteriscos. Estas exenciones de la protección de SIP significan que es posible agregar, quitar o cambiar archivos y directorios dentro de esas ubicaciones.

Entre esas excepciones se encuentran las siguientes:

• /System/Library/User Template- donde OS X almacena los directorios de plantillas que usa al crear carpetas de inicio para cuentas nuevas.
• /usr/libexec/cups- donde OS X almacena la información de configuración de la impresora

Apple considera que este archivo es suyo y que Apple sobrescribirá cualquier cambio realizado por terceros.

Para ver qué archivos han sido protegidos por SIP, use el lscomando con guión O mayúscula en la Terminal:

ls -O

Los archivos protegidos por SIP se etiquetarán como restringidos .

Una cosa importante que debe saber es que incluso si un enlace simbólico está protegido por SIP, eso no significa necesariamente que el directorio al que se vincula esté protegido por SIP. En el nivel raíz de una unidad de arranque de OS X El Capitan, hay varios enlaces simbólicos protegidos por SIP que apuntan a directorios almacenados dentro del directorio de nivel raíz llamado private.

Sin embargo, cuando privatese examina el contenido del directorio, los directorios a los que apuntan esos enlaces simbólicos no están protegidos por SIP y tanto ellos como su contenido pueden moverse, editarse o cambiarse mediante procesos que utilizan privilegios de raíz.

Además de la lista de excepciones SIP que Apple ha establecido en rootless.conf, existe una segunda lista de excepciones SIP. Esta lista incluye varios directorios y nombres de aplicaciones para productos de terceros. Al igual que rootless.conf, esta lista de exclusión es de Apple y Apple sobrescribirá cualquier cambio que realicen terceros.

/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths

Protección en tiempo de ejecución

Las protecciones de SIP no se limitan a proteger el sistema de cambios en el sistema de archivos. También hay llamadas al sistema que ahora están restringidas en su funcionalidad.

• task_for_pid()/processor_set_tasks() fallan con EPERM
• Los puertos especiales de Mach se restablecen en exec (2)
• las variables de entorno dyld se ignoran
• Las sondas DTrace no están disponibles

Sin embargo, SIP no bloquea la inspección por parte del desarrollador de sus propias aplicaciones mientras se desarrollan. Las herramientas de Xcode seguirán permitiendo que las aplicaciones se inspeccionen y depuren durante el proceso de desarrollo.

Para obtener más detalles sobre esto, recomiendo echar un vistazo a la documentación para desarrolladores de Apple para SIP .

Protección de extensión de kernel

SIP bloquea la instalación de extensiones de kernel no firmadas. Para instalar una extensión de kernel en OS X El Capitan con SIP habilitado, una extensión de kernel debe:

1. Estar firmado con una ID de desarrollador para firmar el certificado de Kexts
2. Instalar en /Biblioteca/Extensiones

Si instala una extensión de kernel sin firmar, primero deberá deshabilitar SIP.

Para obtener más información sobre la gestión de SIP, consulte el siguiente enlace:

Protección de integridad del sistema: agregando otra capa al modelo de seguridad de Apple