¿Cuál es realmente la característica "sin raíz" en El Capitán?

Acabo de enterarme de la función "Sin raíz" en El Capitán, y escucho cosas como "No hay usuario root", "Nada puede modificarse /System" y "El mundo terminará porque no podemos obtener root".

¿Cuál es la característica "sin raíz" de El Capitán a nivel técnico? ¿Qué significa realmente para la experiencia del usuario y la experiencia del desarrollador? Se sudo -ssigue trabajando, y si es así, ¿cómo será la experiencia de usar una concha como rootel cambio?

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 root, 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 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, que el malware no puede penetrar incluso si obtiene root. 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 lo "normal"

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

• No se puede modificar nada en /System, /bin, /sbin, o /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 normales de estilo OS X entran /Library(o ~/Library, o /Applications), y las personalizaciones de estilo Unix (por ejemplo, Homebrew) entran /usr/local(o a veces /etco /opt), esto no debería ser un gran problema. También evita las 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 algunos otros) está en /System/Library/Sandbox/rootless.conf. Por supuesto, este archivo está en un área restringida.

  Cuando actualiza a El Capitan, mueve todos los archivos "no autorizados" de áreas restringidas a /Library/SystemMigration/History/Migration-(some UUID)/QuarantineRoot/.

• No puede adjuntar a los procesos del sistema (por ejemplo, los que se ejecutan desde esas ubicaciones del sistema) para cosas como la depuración (o cambiar las bibliotecas dinámicas que cargan, o algunas otras cosas). De nuevo, 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 (especialmente el Finder). También significa que las dtraceherramientas basadas en el monitoreo del sistema (p opensnoop. Ej. ) No podrán monitorear e informar sobre muchos procesos del sistema.

• No puede cargar extensiones de kernel (kexts) a menos que estén debidamente firmadas (es decir, por Apple o un desarrollador aprobado por Apple). Tenga en cuenta que esto reemplaza el antiguo sistema para forzar la firma kext (y las viejas formas de omitirlo). Pero desde v10.10.4 Apple ha tenido una manera de habilitar el soporte de recorte para SSD de terceros , la razón # 1 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 inicio 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 ha aprobado para acceder a esa información. Esto generalmente se considera una característica separada (llamada Protección de información personal, o TCC), pero se basa en SIP y deshabilitar SIP también la deshabilita. Consulte: "¿Qué y cómo implementa macOS Mojave para restringir el acceso de las aplicaciones a los datos personales?"

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 de manera similar puede volver a habilitarlo con csrutil enable).

También puede deshabilitar selectivamente partes de SIP. Por ejemplo, csrutil enable --without kextdeshabilitará la restricción de 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 forma temporal o parcial: ¿realmente necesita deshabilitarlo o hay una forma mejor (compatible con SIP) de hacer lo que desea? ¿Realmente necesita modificar algo en /System/Libraryo /binlo que sea, o podría ir a un lugar mejor como /Libraryo /usr/local/binetc.? SIP puede "sentirse" limitante si no está acostumbrado, y hay algunas razones legítimas para deshabilitarlo, pero una gran parte de lo que hace cumplir realmente es la mejor práctica de todos modos.

Para subrayar la importancia de dejar la mayor cantidad de SIP habilitada 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, hizo que MacOS se rompiera y no se pueda iniciar. La razón más común para deshabilitar SIP fue cargar extensiones de kernel no aprobadas (/ firmadas incorrectamente) (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 , un Q&A de superusuario sobre él y un artículo de Ars Technica .

Referencias e información adicional: 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 profunda inmersión 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 está diciendo al núcleo. Cada vez que un proceso quiere abrir un archivo, escribir un archivo o abrir un puerto, etc., debe preguntarle al núcleo. En Linux, este proceso de monitoreo ocurre fuera del kernel en "userland" y, por lo tanto, los permisos son bastante específicos. Un usuario puede monitorear sus propias aplicaciones (para corregir errores, encontrar pérdidas de memoria, etc.) pero necesitaría ser root para monitorear el proceso de otro usuario.

Sin embargo, DTrace en OSX funciona a nivel del kernel, lo que lo hace mucho más eficiente y potente, sin embargo, requiere acceso de root para agregar sus sondas al kernel y así 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 que de hecho TODOS los procesos en el sistema simultáneamente. Por ejemplo, puede mirar 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 red IO, lo mismo es cierto allí. Wireshark detecta actividad de red inusual, DTrace le dice el proceso que envía los datos, incluso si está tan integrado en el sistema como el núcleo mismo.

Sin embargo, a partir de El Capitán, Apple ha evitado deliberadamente que DTrace funcione, ya que ha sido específicamente dirigido y señalado como algo que SIP restringe. ¿Por qué harían esto? Bueno, anteriormente Apple modificó su kernel y DTrace para permitir que algunos procesos opten 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). Su razón para esto fue proteger DRM en aplicaciones como iTunes, ya que teóricamente alguien podría DTrace y tomar datos no 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 núcleo para ignorar este indicador de exclusión, por lo que DTrace aún podría usarse en estos procesos. Esto fue realmente genial porque los programas que intentaban evadir la detección ahora se iluminaban con esta bandera sin DTrace. Todo lo que Apple o los malos quisieran 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 de monitorear su sistema. Una gran cantidad de herramientas de administración y monitoreo de sistemas de bajo nivel (sobre las cuales se basan las herramientas de nivel superior) ya no funcionarán. Sin embargo, el efecto indirecto será mucho mayor: los profesionales de 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 honeypot. Desactivar SIP le dice a todo el software, tanto de los malos como de Apple, que este sistema está siendo observado. 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, lo eliminaron. En última instancia, esto significa que Apple ha reemplazado la barrera de seguridad 'be all and end all' de la contraseña de root, con el mecanismo de protección SIP 'be all and end all'. O si eres bueno en ingeniería social, una contraseña de root con un reinicio ...

También hay 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 lograr esto, tiene los siguientes conceptos:

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

Protección del sistema de archivos

SIP evita que otras partes además de 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 en /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 firmado por la propia autoridad de certificación de Apple. Esto permite a Apple realizar cambios en las partes del sistema operativo con protección 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 instalador firmados por ID de desarrollador no pueden alterar 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 ubicación a continuación:

/System/Library/Sandbox/rootless.conf

donde rootless.confenumera todas las aplicaciones y el nivel superior de directorios que SIP está protegiendo.

Aplicaciones

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

Directorios

SIP también está protegiendo 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, eliminar o cambiar archivos y directorios dentro de esas ubicaciones.

Entre esas excepciones están las siguientes:

• /System/Library/User Template - donde OS X almacena los directorios de plantillas que usa al crear carpetas de inicio para nuevas cuentas.
• /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 los cambios de terceros serán reemplazados por Apple.

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

ls -O

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

Una idea 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 están vinculados 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 con SIP que apuntan a directorios almacenados dentro del directorio de nivel raíz llamado private.

Sin embargo, cuando privatese examinan los contenidos del directorio, los directorios a los que apuntan esos enlaces simbólicos no están protegidos por SIP y tanto ellos como sus contenidos pueden moverse, editarse o cambiarse mediante procesos usando privilegios de root.

Además de la lista de excepciones SIP que Apple ha establecido rootless.conf, hay una segunda lista de excepciones SIP. Esta lista incluye varios directorios y nombres de aplicaciones para productos de terceros. De manera similar rootless.conf, esta lista de exclusión corresponde a los cambios de Apple y de cualquier tercero que Apple sobrescriba.

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

Protección de tiempo de ejecución

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

• task_for_pid () / processor_set_tasks () falla con EPERM
• Los puertos especiales de Mach se reinician en exec (2)
• las variables de entorno dyld se ignoran
• Sondas DTrace no disponibles

Sin embargo, SIP no bloquea la inspección por parte del desarrollador de sus propias aplicaciones mientras se están desarrollando. Las herramientas de Xcode continuarán permitiendo que las aplicaciones sean inspeccionadas y depuradas durante el proceso de desarrollo.

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

Protección de extensión de kernel

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

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

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

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

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